[FR] Add implicit behavior to CopyUtil.copy_intent_to_agent()?

[Greenford]

Situation:

A tagged intent is dependent on 1+ entity types. Current behavior of copy_intent_to_agent()>_remap_parameters_in_intent() is to ONLY create or update the intent itself without consideration to the entity type dependencies. Entity type dependencies absent from the destination agent cause the method to throw an error when attempting to retag the intent's training phrases with an entity type in the dest agent with the same display name.

Proposal:

Edit copy_intent_to_agent() to create or update entity type dependencies and log the changes, possibly adding a parameter to make this behavior optional. Work started in branch feature/copy_intent_update

Alternative:

Add error handling around CopyUtil line 338 providing more explicit explanation than KeyError:<entity_type.display_name>

Ask:

Thoughts? Do you prefer the proposal or alternative?

[Greenford]

@kmaphoenix @MRyderOC @cgibson6279 inviting comments

[MRyderOC]

Good catch! As you mentioned the basic solution would be adding a boolean parameter like copy_entities to this function.
Meanwhile, you need to consider the following scenarios:

1. dest agent has the same entity type but with different name --> copying will cause duplicate entity types
2. dest agent has the same entity type with the same name but the annotations used different parameter id --> copying will throw an error however copying is unnecessary
3. there is a different entity type in dest agent with the same name --> copying will throw an error

At the very least, this function should copy all the training phrases without annotations

[Greenford]

@MRyderOC thank you for the feedback!

1. This is true. I'm unsure whether it's preferable to make a duplicate occasionally or throw a KeyError frequently. I think I will add a copy_entities param, with the default set to not copy. If it throws a KeyError, the error message will include a suggestion to change copy_entities to copy the entities.
2. I haven't encountered this error; would you provide more details? I'm not seeing a line in SCRAPI that would throw it - is this an error the v3beta1 API would return in a response?
3. This would also be an error returned from the API? I think leaving that error is fine - serves as a cue for the user to re-namespace the entity type display names to resolve the conflict.

The minimum I'm aiming for is copying the training phrases with annotations - seems like much more work to manually re-tag the phrases than to re-namespace and re-run the script.