I have an issue finding the best spot to intervene in the rasa flow. My use case is that I want to alter the user’s message text in a specific case, more exactly, when a certain entity is found. At first, it seemed that the logical place to do that was in a custom nlu component. And indeed, that’s where one add information for future processing in the nlu pipeline. But as it turns out, the only thing that cannot be changed is the text of the message, and I think it is because of this line: rasa/processor.py at f3a3fb7ab391482da5ae7f6f789f0a8c7d600f8b · RasaHQ/rasa · GitHub if it would be parse_data.text, the situation would’ve been resolved
Also, the log following also adds the received text instead of the changed one.
user says hi
if message.text == hi: message.text = "Hello"
This being the situation, I have some open questions:
Is it intended that you cannot change by all means the user text at this level?
Is there a better place to alter user input? It can be done in a custom policy, but it really feels wierd to alter the tracker.
Is there a way to implement a custom tracker? (maybe if there is no other evident solution, this would be a better workaround)
PS: This is a very specific use case and the example is just to prove the technical situation, not the functional one.
If you want the bot to extract the entity first and then based on the entity extracted, alter the text then I guess a custom component would be the best option.
But if you know the exact entity value before hand and just want to alter the user text if this entity value is present, then you can have a custom implementation of the channel you are using and intercept the incoming message before sending it to rasa nlu.
saurabh-m523 My case falls into the first situation you described. That was also my first bet, but it seems you cannot change the text in the custom nlu component.
You can change the text property of the received message: Message parameter, but that’s not going to alter what is saved in the tracker/tracker store…
The only way I found so far was to alter the tracker in a custom policy, but it is weird, as the policies should just predict next actions, not alter nlu output…