-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an action that runs on form start/initialization, before active_loop
is set yet
#10913
Comments
FormValidationAction
that runs on form start, before active_loop
is set yetFormValidationAction
that runs on form start, before active_loop
is set yet
FormValidationAction
that runs on form start, before active_loop
is set yetactive_loop
is set yet
Exalate commented: venushong667 commented: Exalate commented: venushong667 commented: I will give an upvote to this request as I'm facing the same issue, form initialization functions are not working anymore in Rasa 3.0 broke all of our applications. For my opinion, changing I tried to implement alternative way using slot extraction to do the same job but turns out we are unable to get active_loop of form on the activation unless something is pre-filled into it. This issue is quite critical for us, please consider this enhancement. |
Exalate commented: melindaloubser1 commented: Exalate commented: melindaloubser1 commented: @venushong667 For any other users looking for this, can you explain how you tried to use slot extraction to achieve this? It may be that for some use cases your workaround would suffice. |
Exalate commented: venushong667 commented: Exalate commented: venushong667 commented:
@melindaloubser1 In my previous use case, I implemented Using slot extraction, I had tried to create a slot active_loop: type: rasa.shared.core.slots.AnySlot initial_value: null influence_conversation: false mappings:
actions.py class ValidatePredefinedSlots(ValidationAction):async def extract_active_loop( self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict ) -> Dict[Text, Any]: active_loop = tracker.active_loop_name return {'active_loop': active_loop} def validate_active_loop( self, slot_value: Any, dispatcher: CollectingDispatcher, tracker: Tracker, domain: DomainDict, ) -> Dict[Text, Any]: required_slots = domain.get('forms', {}).get(slot_value, {}).get('required_slots', []) if 'AA_continue_form' not in required_slots: return {} return {'AA_continue_form': True, 'zz_confirm_form': True} form general_form: ignored_intents: [] required_slots:
The However, the |
Exalate commented: melindaloubser1 commented: Exalate commented: melindaloubser1 commented: This is the workaround I've come up with. Please let me know if it covers your use case too - you can clone the Your input -> /intro I am the extra run logic and I should run at the beginning of a form! what is your name? Your input -> melinda submitted melinda Add a slot
|
Exalate commented: venushong667 commented: Exalate commented: venushong667 commented:
{"form_initialized": False}
{"form_initialized": True}
{"form_initialized": True}
version: "3.0" > > intents: > - greet > - intro > > responses: > utter_submit_intro_form: > - text: "submitted > {name} "
Sorry for the late reply. Yes, your solution did the job very well as the form_initialized slot is being extracted in every turn of conversation, it is able to trigger the |
active_loop
is set yetactive_loop
is set yet
The change leading to this feature request was reverted in #11326; as such it is now obsolete. |
h3. What problem are you trying to solve?
I want to add form-entry logic that should only run once when a form is activated. In 2.x this was possible by modifying the
run
method of aFormValidationAction
to run certain logic only whenrequested_slot
wasNone
, a heuristic for the form beginning. In 3.x [this was cleaned up| https://github.com//pull/10295/files#r807244104] so that the validation action doesn't run unless the loop is active, which makes sense, but has the side effect of not allowing form initial logic.h3. What's your suggested solution?
Add a new default action type,
FormInitializationAction
that can be subclassed asFormValidationAction
is and called by name rule the same way e.g.initialize_<form_name>
. Other options that came up: * Add a method toFormValidationAction
that runs only in the case that the form action has just been predicted but the loop is not active yet i.e. in the same place as the validation action used to run in 2.x. e.g.run_on_entry()
. Problem with this: This would require changes in Rasa SDK as well, since the action server only offers a way to call therun
method of an action, not any other method. The principle has been to keep form running logic (i.e. when what happens) entirely in Rasa Open Source to avoid any dependency of Rasa SDK for those who run action servers not using Rasa SDK. h3. Examples (if relevant) This used to work in 2.8.x, in 3.x the entry logic will never run: class CustomFormValidationAction(FormValidationAction, ABC): def name(self): return async def run( self, dispatcher: "CollectingDispatcher", tracker: "Tracker", domain: "DomainDict", ) -> List[EventType]: events = await super().run(dispatcher, tracker, domain) if tracker.get_slot("requested_slot") is None: # CONDITION NEVER MET IN 3.x dispatcher.utter_message(text="I am the form entry logic!") return events h3. Is anything blocking this from being implemented? (if relevant) No response h3. Definition of Done * [ ] default action added/called from Rasa OSS * [ ] default action template added in Rasa SDK * [ ] documentation updated</form_name>
The text was updated successfully, but these errors were encountered: