Renaming a Fields container leaves columns in old table and causes dropdown values not to persist

[clintswartzlander]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

GLPI Version

11.0.8

Plugin version

1.24.2

Bug description

Environment

• GLPI: 11.0.8
• Fields plugin: 1.24.2
• Item type: Ticket
• Container type: DOM

Summary

After renaming a Fields container, the plugin created/used a new database table based on the new container name, but existing field columns remained in the old table. The field metadata continued to point all fields to the same container ID, so the UI displayed the fields and submitted the correct values, but the values did not persist.

Original configuration

The container was originally named:

Ticket Details

It was later renamed to:

General Information

All three dropdown fields remained assigned to container ID 1:

• requestingdepartmentfield
• locationfield
• displaylocationfield

Metadata query:

SELECT id, name, label, type, plugin_fields_containers_id
FROM glpi_plugin_fields_fields
ORDER BY plugin_fields_containers_id, id;

Result:

1  requestingdepartmentfield  Requesting Department  dropdown  1
2  locationfield              Location               dropdown  1
7  displaylocationfield       Display Locations      dropdown  1

Container query:

SELECT id, name, label, type, itemtypes
FROM glpi_plugin_fields_containers
ORDER BY id;

Result:

1  generalinformation  General Information  dom  ["Ticket"]
Database state after rename

The old table still contained two field columns:

glpi_plugin_fields_ticketticketdetails

plugin_fields_requestingdepartmentfielddropdowns_id
plugin_fields_locationfielddropdowns_id

The active renamed table contained only the newer field:

glpi_plugin_fields_ticketgeneralinformations

plugin_fields_displaylocationfielddropdowns_id
Symptoms
The ticket form displayed all three fields.
The browser submitted the expected POST keys and values, for example:
plugin_fields_requestingdepartmentfielddropdowns_id = 20
plugin_fields_locationfielddropdowns_id = 17
After saving, the values reverted to blank.
PHP logged undefined array key warnings such as:
Undefined array key "plugin_fields_requestingdepartmentfielddropdowns_id"
Undefined array key "plugin_fields_locationfielddropdowns_id"
Cloning Forms that referenced one of the affected Fields questions could also produce a 500 error in the Form tab.
Root cause observed

The container rename changed the generated/active table name, but the existing field columns were not migrated from the old table to the new table. The plugin metadata therefore described one container, while the physical schema for that container was split across two tables.

Workaround used

After taking a database backup, I manually added the missing columns to the active table and migrated any existing values from the legacy table:

ALTER TABLE glpi_plugin_fields_ticketgeneralinformations
    ADD COLUMN plugin_fields_requestingdepartmentfielddropdowns_id INT(10) UNSIGNED NOT NULL DEFAULT 0,
    ADD COLUMN plugin_fields_locationfielddropdowns_id INT(10) UNSIGNED NOT NULL DEFAULT 0;

Then the existing data was copied from glpi_plugin_fields_ticketticketdetails into glpi_plugin_fields_ticketgeneralinformations, followed by:

Regenerate container files
Clear GLPI cache
Restart Apache

After that, both dropdown values saved and reloaded correctly.

Expected behavior

When a container is renamed, the plugin should either:

Rename/migrate the associated table and preserve all field columns and data, or
Prevent renaming once schema/data exists and clearly warn the administrator.

The current behavior silently leaves the schema split across old and new tables, which is difficult to diagnose and results in data loss on save.

Notes

I am not suggesting the manual SQL above as the permanent implementation fix; it was only a repair that confirmed the diagnosis. The plugin should handle the schema migration or block unsafe renames.

### Relevant log output

```shell

Page URL

No response

Steps To reproduce

No response

Your GLPI setup information

No response

Anything else?

No response

[stonebuzz]

This #1221
Should fix your issue

[clintswartzlander]

Thank you for looking at this.

I reviewed PR #1221, but I believe it addresses a different case. That PR prevents prepareLabel() from corrupting a container name during a partial update when the label key is absent.

In my case, the container was intentionally renamed from Ticket Details to General Information. After the rename:

• glpi_plugin_fields_ticketgeneralinformations became the active table.
• plugin_fields_requestingdepartmentfielddropdowns_id and
  plugin_fields_locationfielddropdowns_id remained in
  glpi_plugin_fields_ticketticketdetails.
• All three fields still referenced the same container ID in
  glpi_plugin_fields_fields.
• Submitted values were present in the HTTP request but could not persist
  because the corresponding columns were absent from the active table.

Manually adding the missing columns to
glpi_plugin_fields_ticketgeneralinformations and migrating the old values
immediately resolved the issue.

Does the plugin currently support renaming a DOM container after fields have
already been created? If so, I believe the rename process needs to rename or
migrate the associated table/columns. If container renaming is not supported,
perhaps the UI should prevent it or warn the administrator.