fix(itil): Ensure readonly logic is applied on backend for ITILObjects

[froozeify]

Checklist before requesting a review

• 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.

Description

User could edit the hidden input value on a readonly field and changed it value.
At the creation for readonly field we'll match the value based on the one defined in the Template predefined fields if it go one.

In other case it will fallback on the og value or unset it from the input, like it was done in #21134

While doing that I also update some hardcoded value to use it's enum correspondence.

Screenshots (if appropriate):

Screencast.from.2025-10-21.16-21-26.webm

[cconard96]

👎 Wouldn't this break API uses, or anything else that updates an ITIL Object beyond the case of a regular user directly trying to update using the web interface?

[AdrienClairembault]

Wouldn't this break API uses, or anything else that updates an ITIL Object beyond the case of a regular user directly trying to update using the web interface?

For the API, I don't know if we want templates to be applied but I guess it make sense? If a user can't set a field through the UI, he should not be able to do it with the API too.

However, this code should not impact all ->update() operations from PHP code, for example we don't want to prevent a rule value from being applied.

So I guess we need something else than prepareInputForUpdate, maybe a new lifecycle hook that would be executed only for UI updates + both APIs? Maybe prepareUserInputForUpdate?

This is something we kinda already talked about with @cedric-anne, there is a need to have a separate check from prepareInputForUpdate as it currently contains profile based operations for some itemtype (e.g. rights checks that impact the input) that interfer with PHP logic sometimes.

Now, whether this is a good idea to start include this in a bugfixe issue in another question... Tbh I don't mind it because it would have a very low impact since the new method would be empty on CommonDBTM and only implemented in specifics child classes (so no behavior change expect this specific fix).

[cconard96]

This has always only been a feature that affects the display of fields in the web UI with no backend enforcement and I don't think it is good to change that on a bugfix version.

I'm also not sure how useful the feature is as of GLPI 11 or if it makes sense to continue to feature or phase it out. It has always confused some users. Some thought it was meant to be a sort of service catalog but now that's been done by Forms and enforced simplified users to use Forms for the initial ticket creation. It seems to me that something like Forms makes more sense for controlling fields.
There is one odd feature which I am not sure works 100% anymore where you can restrict statuses that can be used based on template (which is more that it is dependent on category). This seems to me like it doesn't need to be tied to templates necessarily.

For the API, I don't know if we want templates to be applied but I guess it make sense? If a user can't set a field through the UI, he should not be able to do it with the API too.

This is too dependent on us assuming everyone is using the API as their own user to do tasks and not a script doing automation with other systems where all of the fields are expected to be usable. Maybe a specific category is set to use a profile that makes the External ID readonly but a script that creates those kinds of tickets from another system is expected to set that field initially.

When a lot of assumptions on how people use GLPI are involved, I will always lean towards not agreeing on a change for a bugfix version.

So I guess we need something else than prepareInputForUpdate, maybe a new lifecycle hook that would be executed only for UI updates + both APIs? Maybe prepareUserInputForUpdate?

I am against enforcing this for either API. It may break things users are already using and severely limits the usefulness of things we may want to do with the API in the future. Maybe it could be opt-in with a special property in the input from the API if someone really wants to use the behavior for something like predefined fields but even that usefulness seems limited to me.

[froozeify]

I've update the code so the readonly is only applied on query from the controllers.

But indeed creating a prepareUserInputForUpdate could be very useful (specially in case like that, where we want to do specific enforcement only on the user input side - and to see if API is seen as an user input), probably in a dedicated PR.

For the choice indeed we either see the API has having the same logic as a frontend user (so enforcing the readonly status) or be more like a system tool and having less restriction so (I think it's the current API logic)

[orthagh]

As I agree to not impact the API, at least for now, I would like to not make the function call in legacy controllers (front/*.form.php).
Could you move into postAdd/Update methods and make a specific case for disabling the behavior for API ?

[froozeify]

@orthagh setting it in those place like in prepareInputForUpdate will be also impacting the API and system actions.
I'm not sure it will be feasible in a postAdd/Update since at this point we won't have the previous value in DB to rollback to it.

Doing the proposal of @AdrienClairembault would be a great idea (creating a new prepareUserInputForUpdate) but this modification should be done for the next release (major or minor not into a bugfix).

After exchanging with him, for now doing it in the legacy controller is the way and the code could be change in the future to use the new prepareInputForUpdate.
It's a dedicated discussion we should have with cedric and adrien to get more in detail with it.

[AdrienClairembault]

As I agree to not impact the API, at least for now, I would like to not make the function call in legacy controllers (front/*.form.php).
Could you move into postAdd/Update methods and make a specific case for disabling the behavior for API ?

I don't agree with this, only user actions should trigger this check.
We don't want all PHP code to be impacted by this change (for example, the rule engine should not be blocked from editing the field).

For anything related to rights/template, the controller is the right place IMO.

[froozeify]

Reverting since also plugin, cron would be impacted

see comments

[cedric-anne]

See latest comment.

[trasher]

I do not know if e2e tests failure is related or not

[AdrienClairembault]

New e2e test is failing.

[stonebuzz]

Hi @froozeify

From the Tag plugin, we are now able to add tags to tickets.

However, we are encountering the following warning:

[2025-11-18 08:38:43] glpi.WARNING: *** Warning: Undefined array key "entities_id" at CommonITILObject.php line 8360
Backtrace:
  ./src/CommonITILObject.php:8360
  ./src/CommonITILObject.php:2368                    CommonITILObject->getITILTemplateFromInput()
  ./front/ticket.form.php:89                         CommonITILObject->enforceReadonlyFields()
  ...Glpi/Controller/LegacyFileLoadController.php:64 require()
  ./vendor/symfony/http-kernel/HttpKernel.php:181    Glpi\Controller\LegacyFileLoadController->__invoke()
  ./vendor/symfony/http-kernel/HttpKernel.php:76     Symfony\Component\HttpKernel\HttpKernel->handleRaw()
  ./vendor/symfony/http-kernel/Kernel.php:197        Symfony\Component\HttpKernel\HttpKernel->handle()
  ./public/index.php:70                              Symfony\Component\HttpKernel\Kernel->handle()

This issue appears to be related to a missing entities_id value when loading the ITIL template.

For reference, see: pluginsGLPI/tag#302