Детали задачи
- 
    История 
- 
    Решение: Нет решения
- 
    Medium 
- 
    Не заполнено
- 
    Не заполнено
- 
    Не заполнено
- 
        28.07-11.08, 06.10-31.10, 25.08-08.09
- 
        Требуется
Описание
Необходимо предоставить возможность потенциальным клиентам работать с no-code/low-code инструментами без поднятия отдельного стенда
Предлагаемое решение: Предусмотреть в воркспейсах роль локального администратора с доступом к инструментам конфигурации. Для редактирования локальному администраторы должны быть доступны только те артефакты которые связаны с воркспейсом (чтобы не давать доступ ко всем артефактам). Механизм связи необходимо проанализировать. Предложение по механизму связи: на уровне общего администратора системы указывать, какие типы данных/модели BPMN доступно для редактирования локальным администраторам и в каких воркспейсах.
Инструменты, которые должны быть доступны локальному администратору:
- типы данных
- модели BPMN
- модели DMN
- канбан
- редактирование экранных форм
- редактирование журналов
- редактирование дашбордов для всех пользователей внутри воркспейса
- меню
- шаблоны нотификаций
—
Общие концепции по реализации для артефактов вне ecos-data (как правило hibernate)
Концепции можно пересмотреть, но в процессе реализации воркспейсных артефактов pavel.simonov@citeck.ru руководствовался ими
System ID
- У воркспейса добавлено поле systemId и именно оно используется для префикса в ссылках на воркспейсные артефакты.
- Поле systemId старается быть похожим на id воркспейса, но в нем присутствует замена спец символов, лимитирование по длинне, защита от дублирования одного systemId у двух воркспейсов и прочие доработки. В будущем наверняка появится необходимость отказаться от требования уникальности workspace id (сейчас два разных пользователя не могут создать себе по воркспейсу с одним и тем же id) и тут поле systemId будет очень кстати.
- В коде добавлен класс IdInWs (identifier in workspace), который содержит в себе два поля - id (собственно старый добрый обычный идентификатор артефакта) и workspace (идентификатор воркспейса (не systemId!)). Для конвертации между IdInWs и текстовым представлением следует всегда использовать WorkspaceService. Он внутри вычисляет systemId у воркспейса и добавляет именно его в качестве префикса. В логах запись вида aaa::bbb означает, что aaa - это id воркспейса (не systemId!). Если же aaa:bbb (одно двоеточие), то aaa - это systemId воркспейса
Принципы по доработке артефактов
- В описание артефакта добавляется текстовое поле workspace
- В бд убирается требование уникальности ext_id и вместо него добавляется уникальность по ext_id + workspace
- В бд у всех записей поле workspace проставляется пустой строкой (считаем это дефолтным воркспейсом), добавляется not-null ограничение (чтобы не усложнять себе жизнь условиями с проверкой на null) и указываем, что значение по умолчанию для поля пустая строка на случай если будет понижение версии микросервиса и в insert перестанет попадать поле workspace.
- Значение поля workspace проставляется при мутации атрибута _workspace (приходит при любой мутации с UI) через метод
workspace = workspaceService.getUpdatedWsInMutation(workspace, ctxWorkspace)
Этот метод не дает перезаписать воркспейс если он уже задан (миграция между WS пока не предусмотрена)
5. Основная концепция - перекладываем сложности работы с воркспейсами на плечи микросервиса, в котором существует артефакт. У нас уже есть как минимум два клиента, которые занимаются созданием и деплоем артефактов - UI и AI. Нужно чтобы эти клиенты могли работать максимально просто (с добавлением атрибута _workspace при создании). В такой концепции ничего на формах для артефактов можно не дорабатывать.
6. Ссылка на артефакт в воркспейсе (EntityRef.getLocalId) всегда содержит префикс "{workspace_system_id}:", но атрибут id при этом не должен возвращать id с префиксом. Исключением являются Resolved DAO (emodel/type, uiserv/rjournal, uiserv/rform, uiserv/rboard). Они возвращают атрибут id с префиксом. Это позволяет избежать ряда доработок на UI.
7. Воркспейссы "", "default", "admin$..." (начинается на admin$) считаются воркспейсами с глобальными сущностями и все что в них создается в бд должно попадать с полем workspace равным пустой строке. Соответственно при поисковых запросах если мы хотим получить что-то в admin$workspace, то нужно искать записи с workspace == "".
8. В BPMN движке есть много завязок на наши id и чтобы разрешить конфликты процессов с одним id между воркспейсами нужен префикс. Использовать ":" здесь уже нельзя и поэтому был выбран достаточно уникальный и безобидный разделитель ".." (две точки)
Доработки, без которых не желательно релизиться
- Слушатели в bpmn никак не локализованы в workspace и будут слушать вообще все события в системе
- Скрипты в bpmn выполняются с полными системными правами. Нужно их как-то локализовать (выполнять под user = ws_system и authority "ROLE_SYSTEM_WS_{workspaceSystemId}" ?)
- При скачивании воркспейсных артефактов нужно из всех внутренних ссылок вырезать префиксы "{workspaceSystemId}:" чтобы можно было без проблем импортировать в их в другом WS. Но тут есть нюанс, что возможно имеет смысл отличать ссылки на локальные артефакты в пределах одного WS и ссылки глобальные, чтобы при импорте не добавлять префикс туда, куда не следует.
- В доклибе отсутствует возможность создать Файл:Документ/Таблицу/Презентацию
Вложенные файлы
Вложенные файлы
Связи запроса
- relates to
- 
                    ECOSCOM-5886 Notifications from private WS are written to the journal in the administrator section -         
- New
 
-         
- 
                    ECOSCOM-5883 Notification templates with the same ID -         
- Сделать
 
-         
- 
                    ECOSCOM-5884 Incorrect counter values in the "Notification Templates" journal -         
- Готово
 
-         
- mentioned on

























 
        