Contents
Тип данных - основной артефакт ECM, описывающий объект. В типе данных определяются метаданные, которые будет содержать объект, статусы жизненного цикла, роли, которые могут работать с объектом. Тип данных связан с формой и журналом.
Типы ECOS - артефакты с типом model/type.
В ECOS на основе типа данных создаются следующие артефакты:
У каждого типа данных должен быть родитель. Базовые типы данных:
Кейс (case) - тип для хранения записи, изменяемой во времени посредстовом связи ее с бизнес-процессом (не явлется статической). Маркером того, что тип будет кейсом является необходимость прикрепления к нему процесса и указания при создании общей информации, атрибутов, ролей, статусов и матрицы прав.
Справочник (datalist) - тип для хранения наборов бизнес-данных, которые будут использоваться как статические данные для документов, не участвующие непосредственно в бизнес-процессах. Маркером того, что тип будет даталистом является указание при его создании только общей информации и перечня атрибутов.
В качестве родителя можно использовать созданный ранее тип данных.
Родительские атрибуты попадают в список наследуемых атрибутов (:ref:`Атрибуты<ecos-model_label>`) и по флагу «Наследовать» можно наследовать форму, действия, шаблон нумерации.
Для просмотра существующих типов и их редактирования создан журнал Типы данных (Раздел администратора - Модель - Типы данных):
По умолчанию в журнале типов данных системные типы не отображаются.
Для отображения ТОЛЬКО системных типов перейдите в настройки таблицы, выставите Системный тип - Да:
Тип данных можно создать или загрузить уже созданный в систему.
Подробнее см. раздел ниже
Для создания типа данных необходимо нажать + - Создать новый тип:
Откроется форма создания типа данных:
Для загрузки созданного типа данных необходимо нажать + - Загрузить тип:
Файл формата .yaml
id: hr-offices-type
name:
ru: Офисы
storageType: ECOS_MODEL
parentRef: emodel/type@data-list
formRef: uiserv/form@hr-offices-form
journalRef: uiserv/journal@hr-offices-journal
inheritActions: false
defaultCreateVariant: true
model:
attributes:
- id: officesCode
name:
ru: Код
- id: officesCity
name:
ru: Город
- id: officesAddress
name:
ru: Адрес
В журнале администратору с каждой записью доступен стандартный набор действий:
- скачать в виде json-файла;
- удалить;
- открыть карточку в соседней вкладке;
- открыть на редактирование;
- редактировать json-файл;
- копировать.
Форма создания нового типа состоит из следующих вкладок:
:ref:`Основные<data_types_main>` – основные характеристики типа данных.
:ref:`Атрибуты<ecos-model_label>`– характеристика, определяющая свойства объекта.
:ref:`Аспекты<type_aspects>`– функционал расширения типа данных без изменения самого типа.
:ref:`Роли<roles_statuses>` – роли, которые участвуют в работе с объектом.
:ref:`Статусы<roles_statuses>`– статусы, по которым объект будет перемещаться по мере выполнения бизнес-процесса.
:ref:`Стадии<stages>`– этапы жизненного цикла документа.
:ref:`Варианты создания<create>` – настройка поддержки выбора варианта создания после выбора типа
:ref:`Связи<datatypes_associations>` – настраиваются для отображения, добавления и удаления связанных объектов в виджете «Связи»» на карточке объекта.
:ref:`Конфигурация контента<datatypes_content>` – настройки работы с содержимым (контентом).
Родитель, форму, журнал, указанные по умолчанию можно изменять.
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Id (обязательное) | уникальный идентификатор типа | test_type (snake case) |
2 | Имя | локализованное название компонента | Тестовый тип |
3 | Шаблон отображения имени | локализованный шаблон заголовка записи, отображаемого при запросах ее локализованного имени (расширеный вариант для параметра п.2).
Поддерживает выражения с использованием данных записи
|
Тестовый тип № ${counter} |
4 | Описание | локализованное описание данного типа ECOS (необязательно). | Тип, используемый для тестовых целей |
5 | Родитель | тип данных, на основании которого, создается текущий. | выбирается из списка предлагаемых:
Остальное – иные созданные ранее типы данных.
|
6 | Форма | ссылка на форму, которая будет открываться при инициировании создания записи данного типа.
Наследование формы позволяет не заполнять в дочернем типе поле "форма", это поле в итоге заполнится значением из родительского типа.
|
есть вариант создания автоматически по умолчанию (Форма по умолчанию), создания вручную (Создать-Создать форму), загрузки (Создать-Загрузить форму). |
7 | Журнал | ссылка на журнал, который будет отображать записи данного типа | есть вариант создания автоматически по умолчанию (Журнал по умолчанию), создания вручную (Создать-Создать журнал), загрузки (Создать-Загрузить журнал). |
8 | Шаблон нумерации | шаблон нумерации :ref:`См. Шаблоны нумерации<number_template>` | выбирается из списка предлагаемых |
9 | Форма дополнительной конфигурации типа | [уточнить] | |
10 | Журнал | Отображать библиотеку документов | |
11 | Действия | Cсылки на действия, которые будут доступны в соответсвующем виджете всех записей данного типа, а также в журнале, связанном с типом (:ref:`подробнее о действиях<ui_actions>`).
Возможно наследование дейсвтий от родительского или же наоборот его запрет (управляется проставлением соответсвующего флага)
|
выбирается из списка предлагаемых |
12 | Дополнительные свойства | [уточнить] | |
13 | Тип источника данных | хранилище, в которое будут заноситься записи данного типа (название отражает не использумую БД, а сервис, в БД которого будут направляться запросы). Значение "По умолчанию" означает, что для места хранения будет использоваться "ID источника данных (14)" из текущего или родительского типа и при этом не будет никакого автоматического создания хранилища. Т.е. при типе источника данных "По умолчанию" предполагается, что место хранения уже подготовлено заранее. | выбирается из списка предлагаемых. |
14 | ID источника данных | иденифтикатор источника для случая, когда используется хранилище не встроенное по умлочанию в систему (в случае когда в п.14 выбран выриант Custom) | test_datasource (snake case) |
15 | Канбан доска | выбор канбан-доски :ref:`См. Канбан-доска<kanban_board>` |
Рассмотрим на примере журнала:
При нажатии на "Создать-создать журнал" открывается форма создания журнала:
При нажатии на "Создать-загрузить журнал" открывается форма загрузки журнала:
Функциональность реализована в настройках компонента :ref:`Select Journal во вкладке "Кастомные"<Select_journal>`
При нажатии на "Изменить" открывается журнал, содержащий все созданные в системе журналы:
При нажатии на Редактировать открывается форма редактирования соответствующей выбранной сущности на новой вкладке.
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Id | идентификатор поля, по которому оно будет доступно на форме, в журнале. | testAttribute (camelCase) |
2 | Имя | имя поля для отображения пользователю. | Тестовый атрибут |
3 | Тип | тип поля. :ref:`Поддерживаемые типы<ecos-model_types>` | выбирается из списка предлагаемых. По умолчанию выставляется text. |
4 | Множественный | множественный ввод разрешен | флаг |
5 | Обязательный | поле обязательно к заполнению | флаг |
6 | Настройка прав для атрибута | функционал, позволяющий произвести настройку прав доступа в отношении "Роль-Статус" для конкретного атрибута. :ref:`См. подробно<count_attributes>` | выбирается состояние доступа атрибута на пересечении сетки "Роль-Статус" |
7 | Вычисляемые атрибуты | функионал, позволяющий установить выражение-зависимость, позволяющий гибко создавать производные атрибуты :ref:`См. подробно<attribute_rights>` | настройка конфигурации в зависимости от типа и сложности вычисления атрибута |
8 | Наследуемые атрибуты | отображение значений наследумых от родительского типа атрибутов в соответсвии с п. 1, 2 и 6 (при условии что родительский тип задан и имеет атрибуты) | отсутствует |
9 | Настройка прав для типа данных | функционал, позволяющий произвести настройку прав доступа документа в отношении "Роль-Статус".
А также выгрузить и удалить полную схему прав (включая настройки из п.6) :ref:`См. подробно<doc_rights>`
|
выбирается состояние доступа документа на пересечении сетки "Роль-Статус" |
Тип - тип вычисляемого атрибута. Поддерживаются:
- Script - вычисление атрибута на основе
javascript'а
;- Attribute - вычисление атрибута на основе другого атрибута (можно делать алиас на глубоко вложенный атрибут. Например:
idocs:counterparty.idocs:fullOrganizationName?str)
;- Значение - константное значение;
- Counter - значение будет генерироваться по счетчику при создании документа и не меняться со временем.
- Template - шаблонная строка. Можно использовать вставки вида ${…}. Например:
${someAttribute?str}
. Вместо данного плейсхолдера будет подставлено значение укзанного атрибута;Метод хранения - тип сохранения. Определяет, нужно или нет сохранять вычисленное значение и если да, то в какие моменты. Возможные значения:
- None - сохранение не нужно. При каждом обращении вычисляем значение заново;
- On empty - сохранять вычисленное значение только если сохраненное значение отсутствует (т.е. при запросе значения вернулся
null
);- On create - сохранять вычисленное значение только после создания. Последующие мутации никак данный атрибут не затронут и он будет работать как обычный атрибут.
- On mutate - сохранять вычисленное значение при каждой мутации. В случае использования :ref:`Records API<Records_API>` для изменения записи гарантируется актуальность значения.
Объекты в глобальной области видимости:
Records - адаптер для RecordsService; | Методы: get(recordRef: String): AttValueScriptCtx // возвращает объект аналогичный value, который описан выше query(query: Object, attributes: Any?) // возвращает объект вида: |
value - текущий документ; | Свойства
id: String //глобальный идентификатор записи localId: String //локальный идентификатор записи Методы:
load(attributes: Any?): Any? // загрузка атрибутов у текущей записи. Можно передавать массив, строку и объект <String, String> Пример:
Вычислить атрибут на основе трех других:
var firstName = value.load('firstName'); var lastName = value.load('lastName'); return lastName + ' ' + firstName; |
log - логгер. | [уточнить] |
Warning
Прикладных сервисов в контексте скрипта нет.
Матрица прав - таблица, которая показывает, какими правами обладает конкретная роль на отдельные виды данных.
Права могут быть настроены отдельно на документ, отдельно на его атрибуты.
Настройка прав осуществляется на форме редактирования типа во вкладке :guilabel:`Атрибуты`.
Important
Редактор доступен только в Enterprise версии ECOS.
Права на документ:
Important
Чтобы сформированные по умолчанию права на документ вступили в силу, нажмите Сохранить
Права на атрибут:
Important
Чтобы сформированные по умолчанию права на атрибут вступили в силу, нажмите Сохранить
Important
При разработке модуля необходимо по соответствующей кнопке скачать матрицу прав. Полученный json поместить в модель по пути: app/artifacts/model/permissions
Вычисление прав для PermissionsDef (документа или атрибута) делится на два этапа:
1. Применение матрицы прав <Роль, <Статус, Уровень_прав>>. Есть 3 уровня прав:
- NONE - нет прав;
- READ - чтение;
- WRITE - чтение и запись.
2. Применение правил. Правила нужны в случаях, когда логика распределения прав не укладывается в простую матрицу. Примеры:
- Если есть 2 состояния документа в одном статусе, но с разными правами;
- Если уровень прав зависит от атрибутов документа.
Значения, которые вычисляются на этапах 1 и 2 должны быть абсолютными. Т.е. если у нас есть конфигурация прав, то она на 100% описывает текущий уровень прав и не предполагает наличие дополнительных механизмов.
- Роли и статусы берутся из конфигурации типа. Если какой-то роли или статуса нет в конфигурации типа, то наличие этих сущностей в конфиге прав игнорируется.
- Если для роли, статуса или атрибута нет настройки прав, но они присутствуют в типе, то по умолчанию выставляется право только на чтение.
- Если у документа выставлен статус или есть роль, которые отсутствуют в конфиге типа, то права для них по умолчанию пустые (нет возможности даже читать).
Данные условия относятся к настройкам матрицы без системных статусов и ролей.
Статус есть в типе | Статус есть в матрице | Роль есть в типе | Роль есть в матрице | Уровень прав |
---|---|---|---|---|
Да | Да | Да | Да | Из матрицы |
Да | Да | Да | Нет | Чтение |
Да | Да | Нет | Да | Нет прав |
Да | Да | Нет | Нет | Нет прав |
Да | Нет | Да | Да | Чтение |
Да | Нет | Да | Нет | Чтение |
Да | Нет | Нет | Да | Нет прав |
Да | Нет | Нет | Нет | Нет прав |
Нет | Да | Да | Да | Нет прав |
Нет | Да | Да | Нет | Нет прав |
Нет | Да | Нет | Да | Нет прав |
Нет | Да | Нет | Нет | Нет прав |
Нет | Нет | Да | Да | Нет прав |
Нет | Нет | Да | Нет | Нет прав |
Нет | Нет | Нет | Да | Нет прав |
Нет | Нет | Нет | Нет | Нет прав |
При необходимости можно настроить в типе системные статусы и роли. Для этого достаточно указать ID равным одному из предопределенных значений:
Роли:
- EVERYONE - виртуальная роль, к которой относятся все пользователи. Assignees у такой роли всегда пустые, но если роль EVERYONE по матрице получает права, то они распространяются на всех пользователей в системе.
Статусы:
- EMPTY - пустой статус. Полезен для приватных сущностей, которые недоступны на чтение всем пользователям в системе. Пустой статус может быть в случае если процесс для кейса не найден или операция старта процесса еще не завершилась;
- ANY - любой статус. Вариант использования: для справочников можно задать права для ANY и EVERYONE на чтение, а для изменения записей завести отдельную группу.
Основная логика находится в библиотеке ecos-model-lib.
Конфигурация прав хранится в микросервисе ecos-model.
TypePermsDef id: String // Идентификатор настроек. Уникальный в пределах системы typeRef: RecordRef // Тип ECOS, к которому относятся настройки прав permissions: PermissionsDef // Настройка прав на документ attributes: Map<String, PermissionsDef> // Настройка прав на атрибуты
PermissionsDef matrix: Map<String, Map<String, PermissionLevel>> // Матрица прав <Роль, <Статус, Уровень_прав>>. rules: List<PermissionRule> // Дополнительные правила для гибкой настройки
PermissionLevel (enum) NONE // нет прав READ // права на чтение WRITE // права на чтение и запись
PermissionRule roles: Set<String> // Роли, для которых применяется правило permissions: Set<String> // Список прав statuses: Set<String> // Статусы, в которых данное правило применимо. Пустой список - любой статус condition: Predicate // Условие, по которому данное правило применимо в формате предиката (см. Язык предикатов). type: RuleType // Тип правила RuleType (enum) ALLOW - разрешение. Если правило активно, то permissions добавляются для указанных ролей REVOKE - отбирание прав. Если правило активно, то permissions убираются из списка уже существующих прав у ролей
При поиске матрицы прав учитывается иерархия типов ECOS. При этом ищется первая не пустая конфигурация и дальше поиск прекращается. Т.е. никакого объединения настроек прав из разных типов не происходит.
Пример конфигурации
id: "2a5c3f00-06d5-4b62-8192-1b9116f12db4" typeRef: "emodel/type@contracts-cat-doctype-contract" permissions matrix: confirmers: approval: WRITE reworking: NONE initiator: approval: READ reworking: WRITE scan-man: approval: WRITE reworking: NONE rules: [] attributes:: cm:name: matrix: confirmers: approval: WRITE reworking: NONE initiator: approval: READ reworking: WRITE scan-man: approval: WRITE reworking: NONE rules: [] cm:title: matrix: confirmers: approval: WRITE reworking: NONE initiator: approval: READ reworking: WRITE scan-man: approval: WRITE reworking: NONE rules: []
Выберите спект из списка. По кнопке "Настроить" можно отредактировать конфигурацию - открывается форма, настроенная для :ref:`аспекта<aspects_user>`.
Атрибуты из добавленных аспектов будут доступны в создаваемом типе данных.
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Id | уникальный идентификатор роли | myTestRole (camel case) |
2 | Название логики | имя роли | Тестовая роль |
3 | Участники роли | статическое заполнение роли.
Выбор группы и/или отдельных пользователей из оргструктуры, которые будут выполнять функцию данной роли.
|
выбирается из списка оргуструктуры организации |
4 | Атрибуты | динамическое заполнение роли. Выбор атрибута типа, на который будет ссылаться роль для получения назначаемых пользователей. | выбирается из списка предлагаемых атрибутов |
5 | Динамическая роль | динамическое заполнение роли.
Установление произвольной гибкой логики, по которой будет произведено вычисление состава пользователей роли.
|
настройка конфигурации в зависимости от сложности и набора заивисимых данных для вычисления состава роли |
Note
Все назначенные роли (статические, динамические, атрибутивные) объединяются.
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Id | уникальный идентификатор статуса | testStatus (camel case) |
2 | Название логики | имя статуса | Тестовый статус |
На форме документа статус может быть отражен следующим образом:
В компоненте :ref:`Text field <Text_Field>`:
- название поля может быть любым,
- имя свойства - _status,
- скрыть и заблокировать на ввод, если необходимо не отображать на форме.
Стадии — этапы жизненного цикла документа. В каждую стадию входит один или несколько статусов.
Прежде, чем приступить к работе над стадиями, необходимо заполнить :ref:`Статусы<roles_statuses>`.
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Название стадии | Наименование стадии | testStage (camel case) |
2 | Статусы | Перечень статусов, входящих в стадию | Выбирается из списка предлагаемых статусов |
Каждый статус может быть назначен только на одну стадию:
Стадии отображаются в виджете :ref:`виджете "Стадии"<widget_stages>`
Настройка поддержки выбора варианта создания после выбора типа настраиваются на вкладке :guilabel:`Варианты создания`
п/п | Наименование | Описание | Пример заполнения |
---|---|---|---|
1 | Id | уникальный идентификатор варианта создания | testCreate (camel case) |
2 | Имя | имя поля для отображения пользователю. | Тестовый статус |
3 | Форма | имя поля для отображения пользователю. | Тестовый статус |
4 | Разрешен для | пользователь или группа, для которых разрешен функционал. | |
5 | Дополнительно | дополнительные настройки. | |
6 | Вариант создания по умолчанию | Нужно или нет автоматически сгенерировать вариант создания для типа | |
7 | Добавить варианты создания дочерних типов | Нужно или нет в списке вариантов создания текущего типа отображать варианты создания дочерних типов |
п/п | Наименование | Описание |
---|---|---|
1 | Id | идентификатор связи. Обязательное поле (если не заполнено, то сервер такую связь не сохраняет).
Это поле нужно для:
1. Перезаписывания конфигурации связи в дочернем типе. Т.е. если мы в дочернем типе укажем тот же ID, то по сути перезатрем конфигурацию связи
2. Указание атрибута, в котором связь сохранится (если не задано значение в поле "Атрибут")
|
2 | Имя | имя связи для отображения в интерфейсе |
3 | Атрибут | в который новые связи будут добавляться и из которого будут загружаться.
Как правило это ассоциация из вкладки :guilabel:`Атрибуты`. Если не задано то используется значение поля ID.
|
4 | Направление связи | определяет какие связи отображать в виджете связей. Любая связь строится по принципу SOURCE -> TARGET
- SOURCE - обратное к target связь у источника. При открытии карточки TARGET мы увидим нашу связь. При открытии карточки SOURCE мы ничего не увидим.
- TARGET - связь отображается только у документа, который хотим привязать. При открытии карточки TARGET мы ничего не увидим. При открытии карточки SOURCE мы увидим нашу связь.
- BOTH - двухсторонняя связь. И на карточке SOURCE и на карточке TARGET увидим нашу связь.
|
5 | Связанный тип | тип сущностей, с которыми мы можем связать нашу ноду |
6 | Журналы | список журналов, которые можно использовать для создания новой связи. Если необходимо создавать связи не с одним определенным типом. |
Для добавления возможности связать документ с простой ссылкой (Id - webLinks, Направление связи - TARGET):
Связи (associations) настраиваются для отображения, добавления и удаления связанных объектов в виджете Формы :ref:`«Связи документов»<widget_doc_associations>` на карточке объекта.
Работа с контентом в ECOS осуществляется с использованием атрибутов ECOS типа с типом "Содержимое".
Атрибут _content служит для доступа к основному контенту записи без необходимости узнавать в каком именно атрибуте хранится контент. По умолчанию атрибут с контентом - content, но этот атрибут можно переопределить в типе во вкладке :guilabel:`Конфигурация контента`.
При загрузке нового контента в свойство “_content” имя содержимого записывается в свойство name сущности (если оно определено в атрибутах).
Контент в свойстве _content всегда имеет имя, которое совпадает с именем сущности (оно переопределяет имя самого контента).
п/п | Наименование | Описание |
---|---|---|
1 | Атрибут с основным контентом | атрибут, в котором находится контент, который доступен через свойство “_content”.
Может быть сложным с указанием свойства из связанной сущности. Например - “linkedRecord.content”.
Если это поле оставить пустым, то основным полем с контентом будет “content“.
|
2 | Тип хранилища | место где будет сохраняться контент.
По умолчанию “local“, что в свою очередь означает, что контент будет сохраняться в БД в той же схеме, что и таблица сущностей нашего типа.
Другие типы хранилища пока не поддерживаются.
|
3 | Атрибут с контентом для предпросмотра | атрибут, в котором находится контент, который будет использоваться для предпросмотра документа.
Если не указать значение, то используется “Атрибут с основным контентом”
|
Для работы в java с контентом следует использовать интерфейс EcosContentApi:
Загрузка:
EntityRef tempFile = contentApi.uploadTempFile()
.withMimeType("application/pdf")
.writeContent((writer) -> writer.writeBytes(imageContent1));
ObjectData attributeForMutation = ObjectData.create()
.set("customContentAtt", tempFile);
// Создание
EntityRef newFileWithContent = recordsService.create("emodel/test", attributeForMutation);
// Обновление
recordsService.mutate(newFileWithContent, attributeForMutation);
Чтение:
EntityRef ref = EntityRef.valueOf("emodel/test@localId");
EcosContentData contentData = contentApi.getContent(ref, "attributeWithContent");
if (contentData == null) {
throw new RuntimeException("Content is null");
}
// При работе с файлами, максимальный размер которых может быть более ~20мб
// чтение контента в массив байт следует по возможности избегать. Иначе есть риск получить OutOfMemoryError
byte[] bytes = contentData.readContent(reader -> {
try {
return IOUtils.toByteArray(reader);
} catch (Exception e) {
throw new RuntimeException(e);
}
});
Есть несколько сценариев для работы с отображаемым именем сущности.
Если необходимо, чтобы имя сущности всегда формировалось по шаблону, то следует использовать поле dispNameTemplate в типе;
Если необходимо, чтобы именем сущности можно было управлять, то следует в список атрибутов добавить атрибут с id = ‘name'. Система автоматически будет использовать это поле для отображаемого имени (скаляр ?disp в Records API)
- Можно вывести поле name на форму и тогда пользователь сможет сам им управлять
- Можно поле name не выводить на форму, но позволить пользователю работать с “_content” атрибутом. В этом случае при загрузке нового контента автоматически будет изменяться поле name и => отображаемое имя.
Для типа данных доступны автоматически генерируемая форма и журнал:
Рассмотрим подробнее на примере. Заполним атрибуты типа данных:
На форме типа после создания становятся доступны действия с автосгенерированными формой и журналом:
Журнал получает идентификатор – type$idтипа, название - как и тип данных, и может полноценно использоваться в системе – может быть добавлен в :ref:`меню<menu_add>`:
Перейти в журнал и создать элемент журнала:
Перейдем в журнал «Журналы»:
Автосгенерированный журнал нельзя редактировать, т.к. он генерируется на лету при каждом обращении.
Для журнала доступны действия:
- скачать,
- редактировать json,
- копировать,
- открыть журнал в соседней вкладке.
По нажатию на глаз открывается дашборд для просмотра свойств сгенерированной журнала:
Для созданного типа данных для формы доступны следующие действия:
Тестировать форму - как будет выглядеть форма в итоговом виде:
Для просмотра формы необходимо нажать Submit:
На форме присутствуют поля в соответствии с данными и типом, указанным в атрибутах.
|
|
Автосгенерированную форму можно скопировать, чтобы присвоить идентификатор и отредактировать под себя. :ref:`См. подробнее ниже<auto_form_change>`
|
Перейдем в журнал «Формы».
Форма получает идентификатор – type$idтипа, название - как у типа данных.
Автосгенерированную форму нельзя редактировать.
Для формы доступны действия:
- тестировать форму,
- скачать,
- редактировать json,
- копировать,
- открыть форму в соседней вкладке.
По нажатию на глаз открывается дашборд для просмотра свойств сгенерированной формы:
Если необходимо изменить форму. Например, чтобы в форме инициатор выбирался автоматически как текущий пользователь.
Для этого необходимо скопировать форму из журнала «Формы», или карточки типа данных.
Переименовать:
В типе данных проставляется данная форма и становятся доступны действия, включая редактирование:
Нажать «Редактировать»:
Далее перейти к редактированию компонента:
На вкладке «Кастомные» выставить чекбокс «Текущий пользователь по умолчанию», сохранить компонент:
Далее сохранить форму, тип данных.
В журнале «Формы» при этом пропадет автосгенерированная форма, т.к. она не выбрана по умолчанию в типе данных.
И добавлена созданная вручную, для которой доступны и редактирование, и удаление:
Проверим – при создании заявления на отпуск инициатором автоматически проставляется текущий пользователь: