Fix(MassiveAction): fix item2 reconciliation

[stonebuzz]

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 !37540

In GLPI, if a search option references a table different from the main object, the MassiveAction class will attempt (if the main item and the related item can be assigned to an entity) to load the related item to extract the entity (and the sub-entity if recursive) and compare it to the entity of the main item to "authorize" or deny the update.

However, the loading of the related item is performed via a getFromDB() (thus using the ID column) from the value of the modified field (=/).

Thus, when the field is text, the condition on the entity is never verified and update action is authorized.

But when the field is numeric (dropdown / number / yes no), the loading is erroneous.

For example, with Yes or No, GLPI will load sytematically the related item with ID 1 or ID 0 (which does not correspond to the ID of the line I am trying to modify via the massive actions).

This is a case we have detected in the Fields plugin since we added the entities_id and is_recursive columns.
pluginsGLPI/fields#858

We have not found a similar case in GLPI (via the relation tables), primarily because there is no search option defined on a main asset for a relation table pointing to a 'numeric' field with 'allow_massiveaction => true'.

Let's take the example of a Ticket ID 14305, which has a fields field of type YesNo and a related line indatabase concerning container table.

Via the massive actions, I want to update this field.

First case: update to "No"

GLPI detects that the modified field references a different SQL table than the main item (Ticket) and the related / main item (PluginFieldsTickettickettest) can be assigned to an entity.
GLPI will then attempt to load the related item (PluginFieldsTickettickettest) with getFromDB(value of the modified field => 0).
This line does not exist in the database, the check on the entity is bypassed, and GLPI authorizes the update.

Second case: update to "Yes"

GLPI detects that the modified field references a different SQL table than the main item and that the main item (Ticket) and the related item (PluginFieldsTickettickettest) can be assigned to an entity.
GLPI will then attempt to load the related item (PluginFieldsTickettickettest) with getFromDB(value of the modified field => 1).
This line does not exist in the database, the check on the entity is performed, and GLPI refuses the update because the entity of the main item (Ticket) and the entity of the related item (PluginFieldsTickettickettest) are not the same.

@cedric-anne I am available to show you (it will certainly be more effective in person).

Screenshots (if appropriate):

[trasher]

As usual, I'll ask for a test case - as far as I remember MA already have tests.

[stonebuzz]

I managed to implement a test that validates the basic behavior — specifically the update of a dropdown field — is still working as expected and remains consistent with entity management. ✅

However, writing a test for updating a relation table via a dropdown, number, or yesno field is more complicated. GLPI doesn’t natively allow relation tables to be updated through massive actions. To detail:

• The corresponding searchOptions usually have the massiveaction attribute set to false. For instance: Item_Disk::rawSearchOptionsToAdd().

• Some classes also implement getForbiddenStandardMassiveAction(), explicitly adding MassiveAction::UPDATE to the list of disallowed actions.
  So if anyone knows of a class or a searchOption I could leverage to test relation field updates via massive actions, I’d be glad to hear about it.

For context, the original bug was related to the Fields plugin, which does allow updating relation tables — something that core GLPI typically restricts in this context.