NexTool Solutions

Пользовательское поле в GLPI — это архитектурное решение, а не один клик. Правильный вопрос — не «Fields или встроенное?», а: данные, которые нужно хранить, — это атрибут того, что уже существует, или это новая сущность со своей жизнью? Ответ определяет инструмент — и цену, которую вы будете платить в ближайшие годы.

Что на самом деле решает каждый подход

Плагин Fields (поддерживается Teclib) добавляет дополнительные поля к типам объектов, которые уже есть в GLPI: заявке, компьютеру, пользователю, контракту, поставщику. Вы создаёте контейнер (блок полей), выбираете, в каких типах он отображается, и добавляете поля: текст, выпадающий список, дата, число, да/нет, URL. Это по-прежнему практичный способ сказать «у каждой заявки должно быть поле Центр затрат».

Пользовательские объекты GLPI 11 (пользовательские активы) решают другую задачу: создают новый тип объекта прямо в ядре, без плагина. Это официальная замена старого GenericObject. Вы определяете «Автомобиль», «Переговорную» или «Лабораторное оборудование» с собственными полями, и он ведёт себя как полноценный актив: попадает в инвентаризацию, связывается с заявками, отображается в отчётах.

Если кратко обозначить границу: Fields добавляет атрибуты к существующему; встроенный объект создаёт сущность. Путаница между ними — источник почти всех проблем сопровождения, которые возникают потом.

Прямое сравнение

Где живут данные (и почему это важно)

Каждый контейнер Fields становится отдельной таблицей в базе — с одной строкой на объект и одним столбцом на поле. Прежде чем принимать решение, стоит посмотреть, что уже есть в среде:

-- Where the Fields plugin stores values: one table per container,
-- with one row per item and one column per custom field.
SELECT table_name AS container_table
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE 'glpi_plugin_fields_%'
ORDER BY table_name;

-- Definitions: containers (which types they apply to) and each one's fields
SELECT c.name AS container, c.itemtypes, f.name AS field, f.type
FROM glpi_plugin_fields_containers c
JOIN glpi_plugin_fields_fields f
  ON f.plugin_fields_containers_id = c.id
ORDER BY c.name, f.ranking;

Это важно по двум эксплуатационным причинам. Во-первых, каждое поле Fields, помеченное как доступное для поиска, становится search option, и поисковый движок GLPI обрабатывает её дополнительным LEFT JOIN к таблице контейнера. У клиента с 15 и более контейнерами в Ticket список заявок начинает тормозить — не из-за объёма данных, а из-за JOIN в SELECT поиска. Во-вторых, встроенные объекты хранятся в схеме ядра, поэтому попадают в экспорт, API и отчёты так же, как стандартные поля, без параллельной таблицы, которую нужно сверять.

Компромисс, который проявляется в сопровождении

При сопровождении парков GLPI клиентов реальная цена Fields — не установка, а день мажорного обновления. Fields — жёсткая зависимость: при миграции с GLPI 10 на 11 среда поднимается, только когда есть версия плагина, совместимая с новым ядром. Нам уже приходилось держать окно обновления клиента в ожидании, пока плагин опубликует совместимую сборку, — с десятками контейнеров в продуктиве, которые нельзя было отключить. У встроенного объекта такого барьера нет: он и есть ядро и обновляется вместе с ним.

Две типичные ошибки, которые мы часто исправляем. Первая — моделировать целую сущность как набор полей в заявке: «Договор на обслуживание» превращается в 12 полей Fields в Ticket, которые невозможно нормально выводить списком, фильтровать или связывать; там нужен был объект (или собственный модуль Контрактов GLPI). Вторая — обратная: создавать целый пользовательский актив для того, что было двумя организационными атрибутами существующего типа, — сложность моделирования без отдачи. И предупреждение, которое мы даём всегда: скрытие поля Fields по профилю — это отображение, а не безопасность. Значение остаётся в базе и утекает через API, экспорт или поиск. Если данные чувствительные, контроль должен быть другим.

Вердикт по сценариям

Используйте Fields, когда данные — это атрибут уже существующего типа и вы не хотите управлять новым типом: центр затрат и проект в заявке, внутренний инвентарный номер в компьютере, табельный номер у пользователя, обязательные или условные поля по категории заявки. Это быстро, без простоя и без миграции схемы, которую вам пришлось бы администрировать.

Используйте встроенный пользовательский объект, когда у «вещи» есть своя жизнь и вы будете выводить её списком, фильтровать и связывать с заявками как объект: автомобили, помещения, лабораторные активы, оборудование, которое не вписывается ни в один стандартный тип. И обязательно — когда уходите с GenericObject при миграции на GLPI 11: это официальный путь замены.

Оба подхода сосуществуют. Вполне допустимо иметь пользовательский актив для сущности и при этом использовать Fields, чтобы добавить тот или иной организационный атрибут к заявкам, ссылающимся на этот актив. Недопустимо использовать один инструмент для работы другого.

Стоимость и трудозатраты

Лицензия: оба бесплатны (GPL). Настоящая стоимость — сопровождение. Fields берёт плату риском зависимости при каждом мажорном обновлении и нагрузкой на поиск по мере роста числа контейнеров. Встроенный объект берёт плату первоначальным моделированием — вы проектируете тип, а не добавляете поле, — но потом не создаёт нагрузки ни при обновлении, ни параллельными JOIN. Честная оценка: добавить поле Fields — минуты; хорошо смоделировать пользовательский актив — от нескольких часов до дня, с учётом полей, профилей и инвентаризации.

В NexTool мы внедряем и сопровождаем оба подхода в GLPI клиентов. Если вы выбираете между добавлением новых полей и моделированием объекта — или вам нужно уйти с GenericObject, не сломав историю, — наш консалтинг по GLPI поможет принять решение до того, как оно превратится в технический долг.

Проверено командой NexTool Solutions.