Fix (Business Rule) - Ticket Name Rule execution

[RomainLvr]

Checklist before requesting a review

Please delete options that are not relevant.

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes !37861
• Here is a brief description of what this PR does

Fixed execution of rules using ticket title. These rules were not validated if the user did not modify the ticket title.

To correct this, simply add the ticket name field to the input in the fillInputForBusinessRules() function.

Screenshots (if appropriate):

[stonebuzz]

Please note that in the upcoming major release of GLPI (version 11), it will be possible to configure multiple approval steps.

#19069

Now, I fully agree that in the interface, it is indeed possible to trigger a new approval request once a validation has been completed—whether approved or rejected—even though the business rules do not allow it.

what do you think @cedric-anne @orthagh

[cedric-anne]

Now, I fully agree that in the interface, it is indeed possible to trigger a new approval request once a validation has been completed—whether approved or rejected—even though the business rules do not allow it.

what do you think @cedric-anne @orthagh

It does not make sense to ask the same user for a new validation of the same ticket as long as there is no support of multiple validations in GLP 10. IMHO, the fact that it is possible to create multiple validations requests for the same user for a same ticket is a bug. We should not change this behaviour in GLPI 10.

[RomainLvr]

ping @stonebuzz

[cedric-anne]

We already had many discussions about this topic. Nos having all the fields in the rules engine input is a known limitation and, unless we find a way to handle it without changing the behaviour of the existing rules, we should not change it.

I am not sure it is a good idea to force this field value in the rules input, especially in a bugfixes version.

[cconard96]

We already had many discussions about this topic. Nos having all the fields in the rules engine input is a known limitation and, unless we find a way to handle it without changing the behaviour of the existing rules, we should not change it.

I am not sure it is a good idea to force this field value in the rules input, especially in a bugfixes version.

My opinion is that historically, the rules engine always worked with the changeset, not previous or current values, so it should stay that way. Focus should instead be on a more advanced automation solution either as a direct replacement or something to use alongside the rules engine.