Form automatically fills in all `from_text` slots in RC2

[koaning]

I am working on a bot in RC2 where I'm supposed to give my name.

> python -m rasa --version

Rasa Version      :         3.0.0rc2
Minimum Compatible Version: 3.0.0rc1
Rasa SDK Version  :         3.0.0rc1
Rasa X Version    :         None
Python Version    :         3.7.9
Operating System  :         Linux-5.11.0-7614-generic-x86_64-with-Pop-20.10-groovy
Python Path       :         /home/vincent/Development/rasa-3.x-form-examples/venv/bin/python

Here's a snippet of the domain file where the bot is having well.

forms:
  name_form:
    required_slots:
      - first_name
      - last_name

slots:
  first_name:
    type: text
    influence_conversation: true
    mappings:
      - type: from_text
        conditions:
         - active_loop: name_form
           requested_slot: first_name
  last_name:
    type: text
    influence_conversation: true
    mappings:
      - type: from_text
        conditions:
         - active_loop: name_form
           requested_slot: last_name

This form behaves well, here's a snippet for the behavior in rasa shell.

Your input ->  hi there                                                                                                                                                                
Hey! How are you?

Your input ->  i want to tell you my name                                                                                                                                              
What is your first name?

Your input ->  vincent                                                                                                                                                                 
What is your last name?

Your input ->  warmerdarm                                                                                                                                                              
Ok. Thanks!
I will remember that your name is vincent warmerdarm!

So far so good. But let's now remove the conditions.

forms:
  name_form:
    required_slots:
      - first_name
      - last_name

slots:
  first_name:
    type: text
    influence_conversation: true
    mappings:
      - type: from_text
  last_name:
    type: text
    influence_conversation: true
    mappings:
      - type: from_text

Here's what rasa shell does now.

Your input ->  i want to tell you my name                                                                                                                                              
Ok. Thanks!
I will remember that your name is i want to tell you my name i want to tell you my name!

This is a bit strange. The form has two slots but they both automatically get filled from a single utterance. I'd argue that this is a bit greedy, similar to the issue described here. What's going to be confusing to the end-user is that the two responses for asking the user is completely skipped too.

responses:
  utter_ask_first_name:
  - text: What is your first name?
  utter_ask_last_name:
  - text: What is your last name?
  utter_submit:
  - text: Ok. Thanks!
  utter_slots_values:
  - text: I will remember that your name is {first_name} {last_name}!

If anybody is interested in reproducing this issue, the project can be found here.

[indam23]

Was just going through the docs on unique entity mapping matching - it sounds like similar behavior for other mapping types is desired? I.e. only fill slots based on user utterances inside a form if a) the slot is requested (so default requested_slot limitation) AND/OR b) the slot mapping is unique in the form

IMO though, this adds complexity to the global and explicit conditions behaviour. If anything, I'd argue for removing unique entity mapping matching in favor of users having to specify requested_slot to make that limitation too.

[ancalita]

@melindaloubser1 The removal of unique entity mapping matching in forms might be too last minute before the release, we could follow-up on this after the release. The reason being I don't want to make a hasty removal and replace with conditions that won't be tested properly before the release planned for next week. Considering this behaviour is only for when requested_slot is other than the slot with the from_entity mapping, we'd have to add support for requested_slot to be processed as a list, when there are multiple other requested_slot(s).

@koaning Based on the discussion here: https://github.com/RasaHQ/rasa/issues/10219, we will mandate the use of conditions to maintain 2.x form behaviour in 3.0. The main reason conditions were added was for this specific use-case in forms and expecting the same 2.x form behaviour without this key in 3.0 is a usage error imo.

[indam23]

Agreed, too short notice now, also not sold on it, but something to consider for after 🙌

[indam23]

Re.

we'd have to add support for requested_slot to be processed as a list, when there are multiple other requested_slot(s).

I don't think this would be needed to remove unique entity mapping (in the future). It would just mean if the user has multiple slots in one form filled by one entity, they would need to constrain those slot mapping with requested_slot. Each mapping would still only need to give one requested_slot though - right?

[ancalita]

Oh I was talking about the requested_slot for a unique entity mapping being available as a list (to list all other slots when they are requested to allow this entity mapping to be used), but I think you're referring to restricting a non-unique entity mapping with requested_slot: same_slot, right? Which is indeed a more efficient solution 😄

[indam23]

Yep exactly!

[ancalita]

Follow-up issue created :)

@koaning would it be ok to close this issue since the solution is to use conditions in the slot mapping?

[koaning]

That's fine, but with a footnote that it would be good to make sure these conditions are explicitly mentioned in the migration guide. They occur to me as a very good/safe practice that many folks will initially be unfamiliar with.

Thanks for the checking 😄 !

[ancalita]

@koaning I've added this note in the from_text section of the docs:

To maintain the 2.x form behavior when using `from_text` slot mappings, you must use [mapping conditions](./domain.mdx#mapping-conditions), where both `active_loop` and `requested_slot` keys are defined.

Plus, developed a bit this paragraph in the migration guide:

For slots that should be filled only in the context of a form, add [mapping conditions](./domain.mdx#mapping-conditions) 
to specify which form(s) should be active, as well as indicate if the `requested_slot` should be the same slot.
Adding `conditions` is required to preserve the behavior of slot mappings from 2.0, since without them
the mappings will be applied on each user turn regardless of whether a form is active or not.

Let me know if that's alright!