Fix Update source for Monitor and Peripheral

[Lainow]

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 !41896
• Here is a brief description of what this PR does
  Fixed the Update Source field not updating for monitors and peripherals when inventorying a computer.

Screenshots (if appropriate):

[Lainow]

Liked to #23018

[trasher]

Tests are failing. In the other PR, I said that it could be a good idea to be more generic, if that does not break anything; and I'm afraid it's the case.

[stonebuzz]

Yes, some tests failed because the autoupdatesystems_id field is attempting to insert a non-integer value into the database.

  SQL: INSERT INTO `glpi_unmanageds` (`autoupdatesystems_id`, `name`, `entities_id`, `date_creation`, `date_mod`) VALUES ('GLPI Native Inventory', 'Avaya Inc', '0', '2026-02-09 15:19:16', '2026-02-09 15:19:16')
  Error: Incorrect integer value: 'GLPI Native Inventory' for column 'autoupdatesystems_id' at row 1

The current approach is too generic

Based on my understanding, all classes that extend InventoryAsset (and therefore do not go through MainAsset) do not have an autoupdatesystems_id set.

In some cases, this is expected—for example, NetworkPort, since the field does not exist for this object.

In other cases, however, this is not expected, as the field does exist in the database schema.

At first glance, only the following classes (which extend InventoryAsset) should be updated to correctly set autoupdatesystems_id in the prepare() method:

I therefore propose the following approach:

• For each class extending InventoryAsset (see screenshot), verify whether the autoupdatesystems_id field exists in the database.
• If the field exists, ensure that its value is set in the prepare() function (and adapt tests).

This approach would limit the scope of the changes while ensuring consistency and correctness.

What do you think @trasher ?

[trasher]

My idea would be to try handling that like the handleLinks() method; once the mainitem has been processed, the inventory system can be made available. Or something like that.
I do not like the idea to work with prepare() because it requires a change in each class; we will forget when adding a new one. Also, in the possible items list, only a few are really concerned; and some may be but won't from core (like clusters).

Basically, each item which have the field should automatically take main item one value; this value will never bet set in their data.
I cannot be more precise, I do not have enough time rigth now to work on this.

[Lainow]

Instead of creating another method just for that, I put it directly in handleLink because technically it's also part of link management. It okay like that @trasher ?

[trasher]

Instead of creating another method just for that, I put it directly in handleLink because technically it's also part of link management. It okay like that @trasher ?

Yes, that seems correct.

[trasher]

Also, please fix tests and lint

[trasher]

I've changed the tests (because this is no longer handled in prepare method).

Currently, Monitor tests are OK, while Peripherals are not. In both cases we reach the new code part, and result is the same ($value->autoupdatesystems_id = Dropdown::getDropdownName(...) ==>  ) - I do not know what the problem is (and I do not have time to work on this :/)

[trasher]

Seems OK now, just waiting for tests to finish