When you create custom fields with the Fields plugin for GLPI, the container defines which itemtypes show the new tab. If you later need to add more itemtypes (for example Certificate or Domain), the web interface is not enough: you have to work directly on the database.
In this article we explain why a manual intervention is needed and walk through the full procedure, including the checks and fixes required to avoid incomplete tables.
Neteye version 4.49
GLPI 11.0.9
Plugin Fields 1.24.5
The Fields plugin does not modify GLPI’s native tables. For each container it generates dedicated structure and code, and it does so for every container × itemtype pair:
glpi_computers, but in a table named glpi_plugin_fields_<itemtype><containername>s. For the neteyeperimeter container we get glpi_plugin_fields_computerneteyeperimeters, glpi_plugin_fields_printerneteyeperimeters, and so on. Each row links an object (items_id and itemtype) to its container (plugin_fields_containers_id).inc folder.These tables and classes are created at two moments: when the container is created, and during the plugin’s installation or update. In both cases the plugin reads the container’s itemtypes column and creates whatever is missing.
The critical point is this: itemtypes are chosen and validated only at creation time. The container update code handles changes to the label, but it has no path for changing the itemtypes. That is why the interface does not let you edit them on an existing container.
However, by editing the itemtypes column by hand and reinstalling the plugin, you take advantage of a real mechanism. The installation routine re-reads all containers, regenerates the class files, and runs the table installation for every itemtype listed in itemtypes. Classes and tables therefore appear for the new itemtypes as well.
The problem is that these tables are created with the base schema, meaning only the technical columns. The columns of the individual custom fields are not added. The result is a tab that shows up but has no usable fields. Hence the correction step (Step 4), which recreates the table by copying it from one that is already complete.
Practical consequences:
We verified this procedure on containers of type tab. To check the type of your containers, run this query on the database:
SELECT id, name, type, subtype, itemtypes FROM glpi_plugin_fields_containers;
| id | name | type | subtype | itemtypes |
+----+----------------------------+------+---------+-------------
| 8 | authorized | tab | NULL | ["Software"] |
| 19 | neteye | tab | NULL | ["Computer","NetworkEquipment","Printer"] |
| 30 | esdataset | dom | NULL | ["PluginFieldsLogsourcefieldDropdown"] |
Check the type column. In our case ids 8 and 19 are of type tab. We did not modify dom containers (fields inserted directly into the object’s main form) and we do not guarantee the procedure works for them.
Before touching anything, back up the database and the plugin files.
Back up the GLPI database:
mysqldump glpi > bck_glpi.sql
Back up the plugin’s inc folder:
cp -a /neteye/shared/glpi/data/files/plugins/fields/inc ./bck_fields_inc
Update the glpi_plugin_fields_containers table, listing all the itemtypes in which you want to see the tab, not only the new ones, because the field is overwritten in full.
UPDATE glpi_plugin_fields_containers
SET itemtypes = '["Computer","NetworkEquipment","Printer","Phone","PDU","PassiveDCEquipment","Certificate","Database","Domain"]'
WHERE id IN (19);
From the GLPI container, force a reinstall of the plugin and clear the cache:
podman exec -u 33 -it <glpi_container> php bin/console plugin:install --force --username=<admin user> fields
podman exec -u 33 -it <glpi_container> php bin/console cache:clear
Then log in to the GLPI web console and re-enable the “Additional fields” plugin.
After the reinstall, the plugin creates the table for each new itemtype, but only with the base columns. For example, for Certificate:
MariaDB [glpi]> desc glpi_plugin_fields_certificateneteyeperimeters;
| Field | Type | Null | Key | Default | Extra |
+-----------------------------+------------------+------+-----+-------------+------
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| items_id | int(10) unsigned | NO | | NULL | |
| itemtype | varchar(255) | YES | MUL | Certificate | |
| plugin_fields_containers_id | int(10) unsigned | NO | | 19 | |
| entities_id | int(10) unsigned | NO | MUL | 0 | |
| is_recursive | tinyint(4) | NO | MUL | 0 | |
All the custom field columns are missing. To get a complete table that is correctly linked to the container, recreate it by copying the structure from a table that is already correct, such as the Computer one.
Warning:
DROP TABLEalso deletes the data. If the table already contains values, export them first. If you have just created it through the reinstall, it is normally empty.
-- 1. Drop the incomplete table
DROP TABLE glpi_plugin_fields_certificateneteyeperimeters;
-- 2. Recreate it by copying the structure from a complete table
-- (the Computer table is already correctly linked to the container)
CREATE TABLE glpi_plugin_fields_certificateneteyeperimeters
LIKE glpi_plugin_fields_computerneteyeperimeters;
-- 3. Set the correct default value for the itemtype column
ALTER TABLE glpi_plugin_fields_certificateneteyeperimeters
ALTER COLUMN itemtype SET DEFAULT 'Certificate';
The third command is needed because the copy carries over the default of the source table (Computer).
Repeat these three commands for every new itemtype and every container you modified, adapting the table name (glpi_plugin_fields_<itemtype><containername>s) and the default value of itemtype.
tab.inc folder.itemtypes in glpi_plugin_fields_containers.--force, clear the cache, and re-enable “Additional fields”.itemtype.By following these steps, the new tabs appear on all the desired itemtypes, with all fields available.