Below story is mentioned in rasa core docs -
happy path
request_restaurant
restaurant_form
form{"name": "restaurant_form"}
form{"name": null}
My interpretation is if a reponse is passed to rasa core with intent "request_restaurant" then it will call "restaurant_form" action which is basically a form-action and form policy jumps in to handle coming requests.
But I am unable to understand what is use of below two lines.
form{"name": "restaurant_form"}
form{"name": null}
The first one
form{"name": "restaurant_form"} is activating the form and the second one form{"name": null} is deactivating the form again.
This makes more sense when looking at the unhappy path:
## chitchat
* request_restaurant
- restaurant_form
- form{"name": "restaurant_form"}
* chitchat
- utter_chitchat
- restaurant_form
- form{"name": null}
Here the form stays active while performing actions outside the form and is only deactivated after filling all requested slots from the form.
Related
I added the story,
story: interactive_story_1
steps:
intent: call
entities:
person: son
slot_was_set:
person: son
action: action_call
and when i am running this on rasa interactive, it identifies the intent correctly, sets the slot properly but it predicts action_default_fallback with 0.3 probability and asks to run that instead of action_call which is clearly mentioned in the story!
Ok, I solved it, there was a problem with my rasa core configuration, it was not trained properly so all the action predictions by the dialogue management model was faulty.
I'm trying to manipulate mainly the TCA array (a domain model its "showitem"-value) mainly because those tabs which can be defined (--div--;locallang) can't have a displayCond - so I've added a normal condition which gets the value of a select-tag by the$_POST parameters and trying to change this "showitem"-value in the necessary part of the $GLOBALS["TCA"]-array.
The problem is now: The TCA gets cached in the cache_core-directory of the typo3temp folder - and disabling entire cache ain't a solution at all.
So what am I supposed to do, since I want to have generally this displayCond on those tabs in my TCA (NOTE: using domain model).
Used TYPO3 Version: 8.7.29
I hope there's a solution to that.
Greets.
Was sitting on that problem for hours and tried using signal slots/hooks and inside the TCA file itself - all results the same: TCA cached.
I expect the signal slot/hook gets always called, so I don't know how to fix that.
After 2 years (and some more experience using TYPO3) there are 2 known solutions;
Adding a displayCond to all fields for each tab since TYPO3 will automatically hide a tab if there are no fields to be displayed.
In TYPO3 10.4.20 there's the AfterTcaCompilationEvent (https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Hooks/Events/Core/Configuration/AfterTcaCompilationEvent.html) which could be useful in such an use-case.
I did this bot with starter-pack-rasa-stack which is able to make two kind of actions through get methods : jokes and booking rooms. If I am able to make him tell me jokes I have issues at making him register a reservations. That is to say it is able to call for the ActionJoke class in actions.py but not for ActionBookRoom class.
Indeed, even if every story call for action_room when provided all details like one can see in this one:
## Generated Story 7889435598882720442
* greet
- utter_greet
* book_room
- utter_ask_room
* book_room{"name_room": "blue"}
- slot{"name_room": "blue"}
- utter_ask_day
* book_room{"day": "tomorrow"}
- slot{"day": "tomorrow"}
- utter_ask_hour_start
* book_room{"hour_start": "10h"}
- slot{"hour_start": "10h"}
- utter_ask_duration
* book_room{"duration": "30 min"}
- slot{"duration": "30 min"}
- action_room
* goodbye
- utter_goodbye
- export
Yet it goes straight to goodbye and I don't know how I can retrain the model or train it online to make him take into account this new action.
So how can I make the bot doing this new action?
You should add the new stories to training stories file and retrain the model by running the train script again (e.g. make train-core)
I am trying to create simple printer support chat bot using rasa-core via nlu interpreter, bot should get the printer model, and printer type and post a issue.
I have used the printermodel and printertype variable in slot and entity, but the slots are not getting populated from the chat string.
Please help me on this.
Not very much information to go off of, but here are several things I would check if my slots weren't being filled correctly:
Is NLU parsing the entities correctly? Slots are usually filled from NLU entities. Send your text direct to the NLU and see if the entities are found.
Entity and Slot names are not consistent? The default method of filling slots without custom programming expects the slot name to match the entity name.
Are the slots defined correctly in the domain information?
If you're still having trouble I encourage you to create an issue or join us on gitter.
For example, we have to design simple conversation
User: I am Shivam
Bot: Hello Shivam
Here, we have to extract name and respond using it.
Step 1: In nlu.md file
## intent:told_name
- i am [shivam](name)
- my name is [shivam](name)
- hi, i am [shivam](name)
Step 2 In domain.yml file
intents:
- told_name
actions:
- utter_greet
entities:
- name
slots:
name:
type: text
templates:
utter_greet:
- text: "Hello {name}"
- text: "Hello {name}, happy to meet you."
Step 3 In stories.md file
# story_01
* told_name{"name": "Mayank"}
- utter_greet
I think, you are missing someting in step 3
I found out that the FormWizard only __init__'s once, when the url is request by multiple users at the same time (me in 2 browsers :).
This results in the fact that my temporarily stored data on the wizard's instance is wrongfully shared between users.
I'm doing some DB hits in the second step, and based on that outcome I do a conditional wrap-up in the done() method. code/description: Django FormWizard best .. well .. useful practices
Anybody have some advise on how to handle this?
Thanx a lot
After redoing the code of my 2 wizards, the solution that uses a dict on the FormWizard's instance now uses a nested dict with the session id as the name for the nested dict.
Thus instead of:
self.wizdata
I now use:
sk = request.session._session_key
self.wizdata[sk]
Example and full detail here.
Regards,
Gerard.