feat(RuleTicket): add new action 'replace' for actors

[stonebuzz]

add new action 'replace' for actors

🤖 Generated by Copilot at 236c2b4

This pull request adds a feature to replace actors of ITIL objects based on rules, instead of appending them. It modifies the CommonITILObject, RuleCommonITILObject, and RuleAction classes to handle the new action type and input keys for replacing actors. It also adds a test function to verify the feature in tests/functional/RuleTicket.php.

🤖 Generated by Copilot at 236c2b4

• Add a new variable to store the input key for replacing actors of a given itemtype and type in the CommonITILObject class (link)
  • Unset the input key for replacing actors from the input array (link)
• Add a new option replace to the getActions function in the RuleAction class. The option replace is used to indicate that the action type is to replace the value of a field by another value, instead of assigning or appending it (link)
  • Otherwise, call the parent function to execute the action as usual (link)
  • _users_id_requester: replace users as requesters, with the input key _replace_users_requesters (link)
  • _groups_id_requester: replace groups as requesters, with the input key _replace_groups_requesters (link)
  • _users_id_assign: replace users as assigns, with the input key _replace_users_assigns (link)
  • _groups_id_assign: replace groups as assigns, with the input key _replace_groups_assigns (link)
  • _suppliers_id_assign: replace suppliers as assigns, with the input key _replace_suppliers_assigns (link)
  • _users_id_observer: replace users as observers, with the input key _replace_users_observers (link)
  • _groups_id_observer: replace groups as observers, with the input key _replace_groups_observers (link)

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	!29783

[cedric-anne]

I am not against this change, but last time we discussed about it, we said that we should not do it in a bugfixes version.

see #11957 (comment)

[stonebuzz]

as you like (I can rebase on main) but it's a bug that's been hanging around until now

the rule engine offers 'assign' and 'append' action, the two should have a different behaviour

@orthagh what do you think?

[cedric-anne]

the rule engine offers 'assign' and 'append' action, the two should have a different behaviour

In fact, they act differently, but maybe not as people can expect it.

1. Create a ticket with A as assignee.
2. Update the ticket to assigne B and C.
   -> A assign X rule will remove the new assignees B and C and assign X. Result will be to have A and X as assignees.
   -> A append X rull will append X to B and C. Result will be to have A, B, C and X as assignees.

@orthagh what do you think?

We talk about it just now. He said it is preferable to fix it in main branch.

[stonebuzz]

A assign X rule will remove the new assignees B and C and assign X. Result will be to have A and X as assignees.

No, for me :

A assign X rule will remove old assign A the new assignees B and C and assign X. Result will be to have only X as assigne.

[cedric-anne]

A assign X rule will remove the new assignees B and C and assign X. Result will be to have A and X as assignees.

No, for me :

A assign X rule will remove old assign A the new assignees B and C and assign X. Result will be to have only X as assigne.

I was explaining the current result. What you describe is the result of your proposal.

[cedric-anne]

Test is not enough complete.

1. It should ensure that action like replace users assigned will have no impact on requesters and observers, nor on groups or suppliers.
2. It should verify that replacement also removes actors in existing input (not only existing actors).
3. It should verify that, when there is no existing actors, it does not fail.
4. It should verify the ONADD case too.

You should probably have a data provider that is used to test multiple combinations.