Skip to content

Fix - Entity injection fails when additional fields (Fields plugin) are mapped - #708

Open
RomainLvr wants to merge 1 commit into
11.0/bugfixesfrom
fix/fields-entity-duplicate
Open

RomainLvr wants to merge 1 commit into
11.0/bugfixesfrom
fix/fields-entity-duplicate

Conversation

@RomainLvr

Copy link
Copy Markdown
Contributor

Checklist before requesting a review

Please delete options that are not relevant.

  • I have performed a self-review of my code.
  • I have added tests (when available) that prove my fix is effective or that my feature works.
  • I have updated the CHANGELOG with a short functional description of the fix or new feature.
  • This change requires a documentation update.

Description

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

Follow-up of #703. When injecting entities with a column mapped to an additional field (Fields plugin), every line ends as "Import failed" and the logs show:

MySQL query error: Duplicate entry 'Entity-2268-11' for key 'glpi_plugin_fields_entitycontactentites.itemtype_item_container'

Before inserting a linked item, dataAlreadyInDB() looks for an existing row restricted to the entity set by addNeededFields(), which copies the primary item's entities_id. For an entity, this field is its parent. Fields always stores its row in the entity of the parent item (getEntityID()), which for an entity is the entity itself. The existing row is never found, so it is inserted again. PluginDatainjectionEntityInjection::addOrUpdateObject() runs the injection twice, so the error appears on the very first import.

Fix

  • When the primary type is Entity, linked items are searched and written in the entity itself instead of its parent.
  • Other itemtypes are not affected.

Tests

  • FieldsContainerRightTest: a Fields value is injected on a new entity, then updated on an existing one.
  • The Fields stubs now force the stored entity from the parent item, like the real plugin, and a stub container on Entity was added.

@RomainLvr RomainLvr self-assigned this Nov 12, 2026
@RomainLvr RomainLvr added the bug label Nov 12, 2026
@RomainLvr
RomainLvr requested review from a team, Lainow, MyvTsv and jdurand-teclib and removed request for a team November 12, 2026 09:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants