Дополнительные поля

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

​

Модель данных

Одна запись справочника описывает одно дополнительное поле одного раздела.

​

Разделы

Поле обязательно относится ровно к одному разделу. В новом справочнике доступны: клиент, услуга, инвентарь, автомобиль, самокат, мотоцикл, комплект, продукт, точка проката, категория, аренда, позиция аренды с инвентарём, позиция аренды с услугой, лид, мастерская, документ и шаблон документа. Разделы мастерской, документа, шаблона документа и три транспортных раздела (автомобиль, самокат, мотоцикл) появились только в новом справочнике — в старом наборе их нет. Обратная асимметрия тоже есть: в старом наборе присутствует раздел «документ клиента», которого в новом перечне разделов не существует.

​

Типы значений

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

​

Глобальные поля платформы и уникальность имени

Если у поля не указана компания, оно считается глобальным: платформа заводит его один раз, и оно попадает в списки всех компаний. Правило уникальности действует только на поля компании: внутри тройки «компания + раздел + имя» повторов быть не может. На глобальные поля ограничение не распространяется, и оно не сравнивает поле компании с глобальным — поэтому в одном разделе может оказаться и своё, и платформенное поле с одинаковым именем, и оба вернутся в списке.

​

Где хранятся значения

Описание поля хранится в общей (платформенной) части базы и относится к компании целиком. Само же значение живёт в карточке той сущности, к которой поле привязано: у клиента, аренды, единицы инвентаря, продукта, точки проката и других — в их собственном хранилище дополнительных данных, под ключом, равным имени поля. Отсюда следуют два практических вывода:

• удаление описания поля не стирает уже введённые значения — они остаются в карточках, но перестают быть видимыми;
• преобразования данных при смене типа значения не предусмотрено: старые записи продолжают хранить прежний формат, а потребители (документы, расчёты по смене, метрики) будут интерпретировать их по новому типу.

​

Кэш списка полей

Список дополнительных полей запрашивается практически на каждом экране, поэтому он кэшируется агрессивно.

• Для каждой компании существует свой ключ кэша, и в нём лежит уже готовый список: поля компании плюс все глобальные поля платформы, объединённые в один плоский перечень.
• Срок жизни кэша — сутки (86 400 секунд). Это намеренное исключение: по умолчанию записи кэша в системе живут 15 секунд.
• Вне контекста компании (когда запрос выполняется на общей части базы) список пуст.
• Кэш компании очищается автоматически при сохранении и при удалении дополнительного поля этой компании.

Порядок полей в списке ничем не задан: он определяется базой данных и может измениться после правок. Также по ответу нельзя отличить своё поле от глобального — признака принадлежности в выдаче нет, хотя редактировать можно только свои.

​

Два поколения настройки

​

Старый способ: один объект по разделам

Исторически все дополнительные поля компании передавались и хранились одним объектом, сгруппированным по разделам: продукт, комплект, инвентарь, услуга, клиент, документ клиента, точка проката, аренда, позиция аренды с инвентарём, позиция аренды с услугой, лид, категория. Внутри каждого раздела — простой список описаний полей без идентификаторов. Ключевые особенности:

• сохранение перезаписывает набор целиком: разделы, которых нет в запросе, теряют свои поля, поэтому отправлять нужно всегда полную картину. Это верно и для частичного обновления — там недостающие разделы даже не подставляются пустыми, а просто исчезают из хранимого объекта;
• у полей нет идентификаторов — «изменить одно поле» технически невозможно, список раздела всегда заменяется новым;
• значение попадает в общую настройку компании и подчиняется общей механике настроек: запись в таблицу настроек плюс обновление короткоживущего кэша настроек;
• набор типов здесь свой и короче: нет ссылок на ремонт, документ и шаблон, а ссылки на продукт и на комплект обозначаются иначе, чем в новом справочнике;
• подпись можно не передавать — тогда она останется пустой, но явно переданная пустая подпись будет отклонена как ошибка.

​

Новый способ: отдельные записи

Новый интерфейс работает с полями как с обычным справочником: получить весь список, добавить одно поле, изменить одно поле, удалить одно поле. Список отдаётся без постраничной разбивки и берётся из суточного кэша, а операции с конкретной записью идут напрямую в базу и ищут запись только среди полей текущей компании — глобальные поля видны, но недоступны для изменения и удаления. Проверки при сохранении записи: раздел и тип обязаны быть из списков допустимых значений, имя и подпись обязательны, подсказка необязательна, а варианты значений должны быть списком. Состав вариантов и их соответствие типу значения не проверяются. Повтор имени в том же разделе понятной ошибки не даёт — это ограничение базы, и наружу оно выходит как сбой сервера. При переходе на новый справочник уже существующие наборы были однократно перенесены в отдельные записи: для каждой компании поля всех разделов превратились в записи, поля без имени пропускались, подпись при отсутствии подставлялась из имени, тип по умолчанию — строка. Постоянной синхронизации между двумя поколениями нет.

​

Сравнение

​

Что читает остальная система

Несмотря на существование справочника, все внутренние потребители дополнительных полей сегодня читают старый набор:

• Документы. При генерации документа значения дополнительных полей клиента, аренды, инвентаря, продукта и точки проката подставляются в шаблон по имени поля; для инвентаря и продукта подстановка работает в строках табличной части документа. Для полей аренды со ссылочным типом «клиент» вместо одного значения подставляется целый блок реквизитов связанного клиента. К полям инвентаря документ дополнительно добавляет три встроенных значения: идентификационный номер (VIN), цвет и общий пробег. Если значения в карточке нет, в документ попадает заглушка из подчёркиваний.
• Смены. При закрытии смены числовые дополнительные поля аренды (целые и дробные) суммируются по сменe и выводятся отдельными строками в итоговом сообщении о закрытии.
• Метрики скидок. Числовые дополнительные поля аренды суммируются и возвращаются в отчёте по скидкам отдельным блоком.

Смены и метрики берут только те поля, у которых заданы и имя, и тип, и только числовые типы. Документы такого отбора не делают и берут все описанные поля соответствующих разделов.

​

Права доступа

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

​

Типичные сценарии

Добавить поле в карточку клиента. Пока создание записи в новом справочнике не работает, рабочий путь один: владелец компании сохраняет старый набор целиком, добавив в раздел «клиент» новое описание. Так поле появится и в интерфейсе, и в подстановках документов. Убрать поле. Удаление описания скрывает поле из интерфейса и сбрасывает кэш справочника, но значения остаются в карточках. Если позже завести поле с тем же именем и в том же разделе, старые значения снова станут видны. Платформа заводит поле для всех. Глобальное поле сразу попадает в выдачу тех компаний, чей кэш ещё не прогрет, а остальные увидят его в течение суток. Компании смогут заполнять такое поле, но не смогут его переименовать или удалить, и в документы его значения не попадут — документы читают только старый набор.

​

Подводные камни

Ограничения, о которых стоит помнить

• Сброс кэша выполняется в том контексте компании, в котором произошло сохранение, а ключи кэша дополнительно разделяются по компаниям — правка из фонового или служебного контекста может очистить не тот ключ, который читают запросы пользователей.
• Ограничение уникальности не действует для глобальных полей и не сравнивает поле компании с глобальным: в одном разделе могут сосуществовать одноимённые своё и платформенное поля, и оба попадут в список.
• Глобальные поля видны в списке, но недоступны для изменения и удаления — операции с конкретной записью ищут её только среди полей текущей компании и отвечают «не найдено».
• В выдаче списка нет признака принадлежности: по ответу нельзя понять, какое поле принадлежит компании, а какое платформе, хотя редактировать можно только свои.
• Список полей отдаётся без сортировки — порядок определяется базой и может измениться после правок.
• Наборы разделов и типов у двух поколений не совпадают, а перенос выполнялся в обход проверок: перенесённые записи могут хранить раздел «документ клиента» и старые обозначения продукта и комплекта, которых в новом перечне нет.
• Признаки обязательности, показа в таблице и доступности в фильтрах нигде на сервере не читаются: карточка сохранится даже без заполненного обязательного дополнительного поля.
• В старом формате подпись можно не передавать (тогда она останется пустой), но явно переданная пустая подпись отклоняется как ошибка.
• При сохранении записи в новом справочнике раздел и тип проверяются по спискам допустимых значений, имя и подпись обязательны, а варианты значений должны быть списком; состав вариантов и их соответствие типу значения не проверяются.
• Числовые дополнительные поля аренды заявлены как дополнительные варианты сортировки отчёта по скидкам, но при применении сортировка по ним отбрасывается — упорядочить отчёт по такому полю нельзя.
• Отбор по заполненности имени и типа и по числовым типам делают только итоги смены и метрики скидок; генерация документов такого отбора не выполняет и берёт все описанные поля своих разделов.

​

Связанные страницы