Доработки модуля ввода данных

Бизнес-требования

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

Решение

Строка итогов: подпись «Итого», типы данных, отсутствие схлопывания текста

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> форма со строкой итогов.

Изменения:

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

Сценарии использования

• Пользователь открывает форму ввода со строкой итогов. Система показывает подпись с «Итого» и корректно отформатированные итоги.
• Пользователь сужает колонку. Подпись «Итого» остаётся узнаваемой; при нехватке места срабатывает согласованное с дизайном поведение (перенос, сокращение с tooltip и т.п.), слово «Итого» не исчезает бесследно.
• Пользователь вводит или меняет данные в столбцах с типами. Итог пересчитывается и отображается с учётом типа; при ошибке типа показывается сообщение или индикатор ошибки в зоне итога.

Системная логика – фронтенд

• Верстка и стили строки итогов исключают коллапс текста (flex, min-width, white-space или иные приёмы по текущему стеку).
• Перед отображением итога выполняется проверка или приведение к типу столбца; при невозможности приведения отображается ошибка без «тихого» искажения данных.
• Локализуемая строка для заголовка зоны итогов содержит «Итого».

Системная логика – бэкенд

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

Консолидация: сопоставление полей (латиница, алиасы)

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> настройки консолидации -> сопоставление полей.

Изменения:

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

Сценарии использования

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

Системная логика – фронтенд

• Снять или расширить ограничение «только латиница» в поле ввода и в клиентской валидации; сообщения об ошибкиах в том же стиле, что и в остальных формах.
• Поля ввода и отображения для алиаса; передача алиаса при сохранение алиаса в модель настройек в теле запроса вместе с остальными полями консолидации.

Системная логика – бэкенд

• Валидация идентификатора поля при сохранении настроек консолидации согласована с фронтендом; при необходимости экранирование или каноническая форма хранения.
• В модели настроек консолидации добавлены поля алиасов при их отсутствии; миграции и обратная совместимость для старых конфигураций без алиасов.

Пересчёт идентификаторов строк при удалении

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> таблица строк формы (если в интерфейсе отображаются порядковый номер строки или иной идентификатор, зависящий от порядка).

Изменения:

• После удаления строки пользователь не видит «дыр» в отображаемой нумерации или внутре показанниых пользователю идентификаторах, если там, гдкие они показвываюодятся в интерфейсе.UI.
• Целевая модель (строгий пересчёт порядковых idid, илибо стабильные UUID с потдересчётольным тполько отображаемого порядка) фиксируется в реализации и в описании задачи для согласования с формулами и интеграциями.

Сценарии использования

• Пользователь удаляет одну или несколько строк из середины набора. Идентификаторы строк, используемые для ссылок, консолидации, формул, обновляются согласно выбранной модели.

Системная логика – фронтенд

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

Системная логика – бэкенд

• При пехрсистанентностии строк на сервере: пересчёт orderпорядка или sequential id при удалении, либо политика «стабильный id + order» с атомарным обновлением связанных сущностей.
• APIОтвет на удаленияе и последующейая звыдагрузкича формы всозвдержащает согласованный набор id.id и порядка.

Визуальная индикация комментария к ячейке

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> ячейки таблицы ввода.

Изменения:

• Ячейка с комментарием отличается от ячейки без комментария: иконка, маркер угла, цветовая метка или комбинация по гайдлайнам продукта.
• По наведению или клику доступен просмотр текста комментария (при уже существующем сценарии — дополнить индикацией).

Сценарии использования

• Пользователь добавляет комментарий к ячейке. Сразу после сохранения ячейка получает визуальный признак.
• Пользователь просматривает таблицу: ячейки с комментариями различимы без открытия каждой.

Системная логика – фронтенд

• Отрисовка индикатора по флдагунным илячейки (наличию текста комментария в данных ячейки); обновление индикатора при добавлении и удалении комментария.

Системная логика – бэкенд

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

Согласованность ограничений видимости столбцов DIS и Fastboard (CLS)

Пользовательский интерфейс

Расположение:

• Fastboard -> модуль ввода данных -> форма.
• DIS -> те же правила видимости столбцов для пользователя.

Изменения:

• Во Fastboard пользователь не видиотображаются столбцы формы, запрещённые для нпользоватегля по правилам DIS, в том числе сразу после загрузки страницы (нбетз кратковременного потобркаженияза запрещённых столбцов до применения прав).

Сценарии использования

• Пользователю в DIS запрещены два столбца. Он открывает ту же форму во Fastboard. Эти столбцы отсутствуют в сетке и в настройках просмотра для данного пользователя.

Системная логика – фронтенд

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

Системная логика – бэкенд

• Единый источник правды по видимости столбцов для пользователя и контекста формы; эндпоинт зЗагрузка схемы и данных формы для Fastboard применяет те же правила CLS,видимости столбцов (CLS), что и для DIS.
DIS,
• Прв одном месте или кэшс переирспользованием общей логики.
• Кэш и схотвемты фне ормы учитывдають права пользователя, чтобы не отдавать полную содержимое и метаданные запрещённыхему столбцов в обход огэтих пранвиченийл.

Поиск по спискам в модальных окнах

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> модальные окна с длинным списком выбора (конкретный перечень — в поля, справочники, свядзанныдаче сущиносвентари заци т.д.и).

Изменения:

• Над списком или в шапке модального окна — поле поиска с фильтрацией по подстроке без учёта регистра (или по правилам продукта).
• Пустой поиск показывает полный список; при отсутствии результатов — понятное сообщение.

Сценарии использования

• Пользователь открывает модальное окно с большим списком, вводит часть имени, список сокращается до совпадений.

Системная логика – фронтенд

• ПРереалиспользуемый компонентация поиска пдля модалок со спискуом вцеликом модна клиенте: фильтрация уже загруженыхного оспискнах; при необходимости дебаунс ввода.
• ПереченьДля модальных окон, гдля внедрения фиксируется в подзадаче инвентаризации экранов модуля ввода данных.

Системная логика – бэкенд

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

Базовый режим и режим редактирования: доступность элементов

Пользовательский интерфейс

Расположение:

• Модуль ввода данных -> панели и меню настроек формы.

Правила доступности:

• Выражение: настройка «Выражение» доступна только при включённом режиме редактирования; в базовом режиме скрыта или недоступна.
• Строка итогов: работает всегда, вне зависимости от режима (отображение и использование итогов; при наличии отдельногом редакторае правил итогирования пграницы базового реденжиема согласуеоватсяь с продуктовой политикой:, сминимум. — чтение итогов в базовом прежиме без блокчанировкия).
• Бизнес-процесс: в режиме редактирования секция отображается, элементы настройки привязки и параметров недоступны (только просмотр, read-only или disabled).
• Консолидация: работает в штатном режиме в обоих режимах, без искусственного отключения в базовом режиме, если иное не следует из политики безопасности.

Сценарии использования

• Пользователь в базовом режиме: не открывает настройку выражения; строка итогов и консолидация работают; бизнес-процесс не доступен для настройки (при скрытии секции в базовом режиме — по текущему UX продукта).
• Пользователь включает режим редактирования: настройка выражения доступна; бизнес-процесс виден, но не редактируется; консолидация без ухудшения относительно штатного поведения.

Системная логика – фронтенд

• Единые флаги режима редактирования для условного рендера и disabled-снедоступноясти (disabled) элементов настройкий; единые точки входа для меню и панелей настроек.

Системная логика – бэкенд

• Сервер отклоняет попытки изменить выражение или бизнес-процесс в обход UI, если режим или роль не позволяют.

Критерии приёмки

• В строке итогов отображается слово «Итого» (или локализованный эквивалент); при стандартных размерах окна и колонок текст не сливается в нечитаемую строку; значения итогов соответствуют типам столбцов, при ошибке типа пользователь видит явную обратную связь.
• В консолидации при сопоставлении полей допустимы символы, согласованные с бэкендом, без ограничения «только латиница»; алиас задаётся, сохраняется и отображается в интерфейсе настроек и связанных местах.
• После удаления строк набор идентификаторов или порядковых номеров согласован с зафиксированной в реализации моделью и не ломает консолидацию, ссылки и повторное открытие формы; отображаемая нумерация без «дыр», если нумерация показывается.
• Ячейка с комментарием визуально отличима сразу после добавления комментария и при последующем просмотре таблицы.
• Пользователь с запретом на два столбцаы в DIS не видит эти столбцы во Fastboard при загрузке и дальнейшей работе; для этого пользователя не передаётся содержимое запрещённых столбцов в обход правил CLS.
• В согласованном перечне модальных окон модуля ввода данных поиск по списку фильтрует элементы ожидаемо; при отсутствии совпадений отображается понятное состояние пустого списка.
• В базовом режиме настройка выражения недоступна; строка итогов отображается и используется; консолидация работает штатно; в режиме редактирования выражение настраивается; бизнес-процесс виден, но не настраивается; при наличии серверных проверок попытки обойти ограничения через API отклоняются.

Примечания для постановки в работу

• Уточнить у заказчика, относится ли формулировка «строка итогов работает всегда» только к просмотдру итогов или также к изменению правил итогирования в базовом режиме — от этого зависит точное правило disabled для редактора итогов.
• Для поиска в модальных окнах зафиксировать явный список экранов в подзадаче инвентаризации.
• При необходимости запрета обхода настроек через прямой вызов API добавить проверки на бэкенде и тогда дополнить соответствующий подраздел документа разделом «Системная логика – бэкенд».