Ролевая модель Ruxeo#

Версия: 1.0 Дата: 2026-05-13 Аудитория: аналитики, тестировщики, администраторы стенда, разработка. Связанные документы: - LICENSING_SERVICE_SPECIFICATION.md — лицензирование и per-user module access (исчерпывающая) - SYSTEM_META_ROLES_CONCEPT.md — концепция мета-ролей и резолвинга в workflow - META_ROLES_AUTO_FILL_ANALYSIS.md — авто-заполнение child-ролей при создании БЕ - CHAT_TOBE_SPECIFICATION.md — ACL чатов

Цель документа. Дать единую картину «кто, к чему и почему получает доступ» в Ruxeo. Тестировщик с обычной (не-administrators) учёткой должен по этому документу понимать, в какие группы он должен быть включён, чтобы увидеть тот или иной функционал.

1. Четыре независимых контура контроля доступа#

Доступ пользователя к функциональности и документам в Ruxeo определяется пересечением четырёх независимых проверок. Если хотя бы одна проверка не пройдена — пользователь не увидит экран, не сможет открыть документ или ему откажут в операции.

┌──────────────────────────────────────────────────────────────────────┐
│                    КОНТУРЫ ДОСТУПА В RUXEO                            │
├──────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  A. LICENSE GROUPS              B. META-ROLES                         │
│  ─────────────────              ──────────────                        │
│  Доступ к МОДУЛЮ                Доступ к ФУНКЦИЯМ модуля              │
│  (drawer / cover page /          (создать / согласовать /             │
│   doctype поднимается)            подписать / удалить)                │
│                                                                       │
│   rxdf_licensed_users            rxdf_meta_admins                     │
│   rxcm_licensed_users            rxdf_meta_approvers                  │
│   rxfa_licensed_users            rxcm_meta_signatories                │
│   rxhr_licensed_users            rxhr_meta_hr_managers                │
│   rxar_licensed_users            ...                                  │
│   rxsm_licensed_users                                                 │
│   rxsp_licensed_users                                                 │
│   rxai_licensed_users                                                 │
│                                                                       │
│  C. CHILD ROLES per-BU          D. DYNAMIC ACL                        │
│  ──────────────────              ──────────────                       │
│  Доступ к ДАННЫМ                 Точечный доступ к КОНКРЕТНОМУ        │
│  конкретной БЕ                   документу                            │
│                                                                       │
│   Администраторы ЦЕНТР           • Workflow: на время задачи          │
│   Согласующие договоры ЦЕНТР      • Чат: на время членства в чате    │
│   Бухгалтеры ФИЛИАЛ_1            • Делегирование (computed groups)   │
│   HR-менеджеры ЦЕНТР                                                 │
│   ...                                                                 │
│                                                                       │
└──────────────────────────────────────────────────────────────────────┘

           Пользователь видит документ ⇔ ВСЕ четыре проверки прошли

1.1 Зачем именно четыре контура, а не один#

Контур	Меняется когда	Принимает решение о…
A. License groups	Раз в год при покупке/продлении лицензии	…подключённости модуля на инсталляции
B. Meta-roles	Редко, при ребрендинге процесса	…функциональной роли пользователя в процессе
C. Child roles per-BU	При найме / переводе сотрудника	…полномочиях в конкретной БЕ
D. Dynamic ACL	На каждом шаге процесса	…временном доступе к конкретному документу/чату

Эта декомпозиция позволяет, например, забрать у уволенного сотрудника доступ ко всем БЕ одной операцией (исключить из Администраторы ЦЕНТР), не трогая лицензии и не разбирая ACL каждого документа.

2. Контур A — Лицензионные группы (`*_licensed_users`)#

2.1 Назначение#

Лицензионные группы определяют, подключён ли модуль конкретно для этого пользователя. Это не «есть ли лицензия у инсталляции» (это решается в RxbmLicenseService), а «выдал ли администратор пользователю слот».

2.2 Полный список (8 групп)#

Module ID	License group	Drawer / cover page	Документы под защитой
`rxdf`	`rxdf_licensed_users`	Документооборот	`IncomingDocument`, `OutgoingDocument`, `InternalDocument`, `RxdfOrder`, `RxdfAssignment`, `RxdfExtensionRequest`
`rxcm`	`rxcm_licensed_users`	Договоры	`Contract`, `AdditionalAgreement`, `PowerOfAttorney`, `MachineEnabledPowerOfAttorney`
`rxfa`	`rxfa_licensed_users`	Финансовый архив	`RxfaInvoice`, `RxfaWorkAct`, `RxfaCorrectionInvoice`, `RxfaReconciliationAct`, `RxfaBankGuarantee`, `RxfaBankGuaranteeRequest`, `RxfaAssetDocument`, `RxfaDocumentSetDoc`
`rxhr`	`rxhr_licensed_users`	Кадровый архив	`PersonnelEvent`, `HiringDocument`, `ContractDocument`, `VacationDocument`, `LeaveDocument`, …
`rxar`	`rxar_licensed_users`	Архив (LTArch)	`ArchiveCase`, `TransferInventory`, `DisposalAct`, `NomenclatureItem`, `NomenclatureSection`
`rxsm`	`rxsm_licensed_users`	Service Management	`RxsmRequest`, `RxsmService`, `RxsmCMDBConfigurationItem`, `RxsmSLARule`, `RxsmPriorityRule`, `RxsmAutoClosureRule`
`rxsp`	`rxsp_licensed_users`	Scan Processing	(нет защищаемых doctypes — модуль работает в фоне)
`rxai`	`rxai_licensed_users`	AI Services	(нет защищаемых doctypes)

Источник: LICENSING_SERVICE_SPECIFICATION.md §7.12, конфигурация в OSGI-INF/rxbm-module-access-contrib.xml.

2.3 Что именно скрывается без лицензии#

Уровень	Что произойдёт	Реализация
Drawer-иконка	Не отображается	`<nuxeo-filter user="[[user]]" group="rxdf_licensed_users,administrators">` в `*-drawer.html`
Cover page модуля	Не отображается	тот же `nuxeo-filter` в `*-cover-page.html`
Плитка на главной	Скрывается сервером	`RxbmHomeModuleTileService.getTilesForUser()` — фильтрация по `licenseModuleId`
Отчёты (meta-reports)	Не возвращаются API	`RxbmMetaReportsServiceImpl.isVisibleToUser()`
Документ модуля	`Access.DENY` при любом обращении	`RxbmModuleAccessSecurityPolicy` (order 25) → `RxbmModuleAccessService.hasModuleAccess()`
Task layout	Открывается в ошибке «permission denied»	Задача в инбоксе видна, но `target document` блокируется policy

Важно для тестировщика. Если тестируете под учёткой без *_licensed_users, то иконка модуля в drawer-е не появится в принципе — это не баг, это политика лицензии.

2.4 Кто получает доступ автоматически#

administrators (встроенная группа Nuxeo) — обходит все license-проверки (principal.isAdministrator() короткое замыкание).
Все остальные пользователи — должны быть явно добавлены в нужные *_licensed_users.

2.5 Шаги выдачи лицензионного слота пользователю#

С sansay372-iter3 — через специализированный admin-экран; стандартный Users & Groups больше не рекомендуется для выдачи лицензионных слотов, потому что не показывает limit/used и обходит compliance-guard.

Открыть Admin Center → Управление лицензиями (administration:rxsgn-...).
Раскрыть секцию Управление слотами.
Найти карточку нужного модуля (rxdf, rxhr, rxcm, ...). На карточке видны:
used / limit (например 12 / 50),
статус-бейдж: OK (есть запас), WARNING (≥80%), EXCEEDED (>лимита), UNLIMITED (limit = 0),
список текущих пользователей слота (группа {module}_licensed_users).
В поле «Выдать слот пользователю» ввести Nuxeo username и нажать Выдать. Backend проверяет лимит:
если used < limit — пользователь добавляется в группу, страница перерисовывается;
если used >= limit > 0 — диалог force (см. ниже).
Force-override (deliberate over-allocation): при попытке выдачи поверх лимита появляется confirm-диалог "limit reached (N/M). Выдать слот всё равно (force, превысить лимит)?". Согласие отправляет повторный запрос с force=true, который обходит pre-check. Использовать только при осознанном compliance-решении (закупка дополнительных слотов оформлена, лицензионный ключ ещё не пересчитан и т.п.) — действие фиксируется в логах.
Отзыв слота: в строке пользователя в той же карточке — ссылка Отозвать, confirm-диалог "Отозвать слот {moduleId} у {username}?", далее UserManager.setMemberUsers без него.

Под капотом — Rxbm.GetLicenseSlotOverview (read) и Rxbm.ManageLicenseSlot (write); обе admin-only. Детали — LICENSING.md §2.8 и §6.8.

3. Контур B — Системные мета-роли#

3.1 Назначение#

Мета-роли — это функциональные» роли в процессе (Согласующий, Подписант, Регистратор, Контролёр…), которые не привязаны к конкретной БЕ. Они выполняют две задачи:

Родительская группа для per-BU child-ролей (см. контур C). Например, член группы Согласующие ЦЕНТР через parentGroups автоматически наследует всё, что раздано группе rxdf_meta_approvers.
Точка ACL на глобальных корневых папках (workspaces, общие справочники) — раздаётся через операции Rx**.SetupMetaRolePermissions.

3.2 Категории мета-ролей#

В Ruxeo есть два типа мета-ролей:

Тип	Имеет per-BU child-ролей?	Назначение	Примеры
Иерархические (`perBU=true`)	Да	Зонтик для BU-специфичных ролей, резолвится в workflow	`rxdf_meta_approvers`, `rxcm_meta_signatories`
Плоские (`perBU=false`)	Нет	Системно-уровневые роли, прав не делегируется на BU	`rxbm_meta_sys_admins`, `rxar_meta_archivists`

3.3 Полный реестр мета-ролей по модулям#

Подробнее см. концепцию: SYSTEM_META_ROLES_CONCEPT.md. Сводно — 55 мета-ролей:

Base Module (`rxbm`) — 14 мета-ролей#

Мета-роль	`perBU`	Назначение
`rxbm_meta_sys_admins`	нет	Системные администраторы платформы Ruxeo
`rxbm_meta_config_managers`	нет	Менеджеры конфигурации (parameter store, feature flags)
`rxbm_meta_bu_admins`	да	Администраторы конкретной БЕ
`rxbm_meta_orgstructure_managers`	нет	Менеджеры оргструктуры (БЕ/подразделения/должности)
`rxbm_meta_division_admins`	да	Администраторы подразделений в пределах БЕ
`rxbm_meta_employee_managers`	да	Менеджеры сотрудников БЕ
`rxbm_meta_clerks`	да	Делопроизводители (регистрация документов)
`rxbm_meta_delegation_managers`	да	Управление делегированиями
`rxbm_meta_template_managers`	нет	Менеджеры шаблонов документов (общесистемные)
`rxbm_meta_directory_managers`	нет	Менеджеры справочников
`rxbm_meta_calendar_managers`	нет	Менеджеры календаря (рабочее время, праздники)
`rxbm_meta_auditors`	нет	Системные аудиторы (read-only логи, audit)
`rxbm_meta_bu_users`	да	Обычные пользователи БЕ
`rxbm_meta_viewers`	да	Просмотрщики БЕ (read-only по конкретной БЕ)

DocFlow (`rxdf`) — 10#

rxdf_meta_admins, rxdf_meta_template_managers, rxdf_meta_registrars, rxdf_meta_initiators, rxdf_meta_approvers, rxdf_meta_signatories, rxdf_meta_clerks, rxdf_meta_resolution_managers, rxdf_meta_executors, rxdf_meta_controllers, rxdf_meta_viewers (звёздочкой* — плоские, без perBU)

Contract (`rxcm`) — 8#

rxcm_meta_admins, rxcm_meta_managers*, rxcm_meta_initiators, rxcm_meta_approvers, rxcm_meta_signatories, rxcm_meta_registrars, rxcm_meta_financial_controllers, rxcm_meta_controllers, rxcm_meta_viewers. Демо-роли Норникеля (rxcm_nn_legal_reviewers, rxcm_nn_registrars) — отдельный контрибушн, на не-демо стендах могут не создаваться.

FinArch (`rxfa`) — 8#

rxfa_meta_admins, rxfa_meta_accountants, rxfa_meta_operators, rxfa_meta_managers, rxfa_meta_signers, rxfa_meta_bg_specialists, rxfa_meta_controllers, rxfa_meta_viewers.

HR Archive (`rxhr`) — 5 + 4#

Иерархические: rxhr_meta_hr_managers, rxhr_meta_employee_managers, rxhr_meta_directors, rxhr_meta_legal, rxhr_meta_admins, rxhr_meta_operators, rxhr_meta_controllers, rxhr_meta_viewers. Плоские: rxhr_meta_personnel_specialists, rxhr_meta_payroll_specialists, rxhr_meta_consent_managers, rxhr_meta_hr_viewers.

LTArch (`rxar`) — 10 (все плоские)#

rxar_meta_admins, rxar_meta_nomenclature_managers, rxar_meta_archivists, rxar_meta_operators, rxar_meta_storage_specialists, rxar_meta_retention_managers, rxar_meta_disposal_specialists, rxar_meta_expert_commission, rxar_meta_controllers, rxar_meta_viewers.

Архив управляется централизованно — per-BU дочерних ролей нет.

Trips (`rxtr`) — 3 иерархические#

rxtr_meta_approvers, rxtr_meta_hr_managers, rxtr_meta_expense_approvers.

HR Portal (`rxhp`) — 6 иерархических#

rxhp_meta_admins, rxhp_meta_hr_operators, rxhp_meta_hr_managers, rxhp_meta_signatories, rxhp_meta_controllers, rxhp_meta_viewers.

4. Контур C — Дочерние роли per-BU#

4.1 Механика#

При создании записи в справочнике rxbm_dir_businessunits (с кодом {buCode} и меткой {buLabel}) слушатель RxbmBusinessUnitDirectoryListener вызывает RxbmMetaRoleService.createChildRolesForBU(). Сервис проходит по всем ChildRoleDefinition (из *-child-roles-contrib.xml каждого модуля), у которых perBU=true, и на каждую мета-роль создаёт одну Nuxeo-группу:

groupname  = pattern.replace("{buCode}",  buCode);   // "Согласующие ЦЕНТР"
grouplabel = labelPattern.replace("{buLabel}", buLabel);
parentGroups = [metaRoleId]                          // ["rxdf_meta_approvers"]

parentGroups — это нативный механизм Nuxeo: член дочерней группы автоматически получает права родительской. Поэтому ACE (Согласующие ЦЕНТР, ReadWrite) и (rxdf_meta_approvers, Read) независимо работают для одного и того же пользователя.

4.2 Сколько ролей создаётся на одну БЕ#

Модуль	Количество per-BU child-ролей
`rxbm`	7
`rxdf`	8
`rxcm`	7 (+2 для Норникель-демо)
`rxfa`	6
`rxhr`	8
`rxtr`	3
`rxhp`	6
`rxar`	0 (модуль централизован)
Итого на одну БЕ	45 (47 на Норникель-демо)

При создании БЕ «ЦЕНТР» появятся группы: Администраторы ЦЕНТР, Согласующие ЦЕНТР, Подписанты ЦЕНТР, Бухгалтеры ЦЕНТР, HR-менеджеры ЦЕНТР, и так далее.

4.3 Синхронизация#

Авто при создании БЕ — через RxbmBusinessUnitDirectoryListener.
Ручная синхронизация — через Admin UI «Meta-Roles Management» (операции MetaRole.SyncChildRoles, MetaRole.EnsureMetaRoles).
При удалении БЕ — deleteChildRolesForBU() доступен, но не вызывается автоматически (см. Гэп G-3 ниже).

4.4 Что даёт членство в per-BU роли#

Через parentGroups — все ACE, навешанные на мета-роль (контур B).
Через прямые ACE на BU-корневой папке — раздаются операцией Rx**.SetupBUWorkspaceACLs (см. §6).
Через резолвинг в workflow — задачи, назначенные на мета-роль, при старте маршрута резолвятся в именно ту child-роль, которая соответствует БЕ документа (см. fail-fast архитектура v2.0 в SYSTEM_META_ROLES_CONCEPT.md).

5. Контур D — Динамический ACL#

5.1 Workflow-доступ#

Механизм — стандартный Nuxeo grantPermissionToTaskAssignees():

На graphnode задаётся <rnode:taskAssigneesPermission>ReadWrite</rnode:taskAssigneesPermission>.
При создании задачи Nuxeo добавляет временный ACE (assignee_group, ReadWrite, granted, ACL=routing) на документ.
При завершении задачи ACE снимается автоматически.

В Ruxeo сверху докручены: - RxbmAddParallelActorsOperation — выдача ACL при добавлении соисполнителя в уже идущую параллельную задачу. - RxbmRemoveParallelActorOperation — отзыв ACL при удалении.

Какие permissions выдаются (по узлам):

Permission	Где встречается
`ReadWrite`	основные узлы согласования/подписания/регистрации
`Read`	manager-approval, execution (ознакомление, контроль)
`Write`	приказы DocFlow (без чтения «лишнего»)
(пусто)	start/end-узлы

5.2 Срок жизни workflow-ACL#

Выдаётся при создании задачи, снимается при её завершении (стандартный routing).
Если задача переназначена/делегирована — новый assignee получит ACL только при следующем taskCreated. Прямое делегирование «на лету» (см. computed-groups, ниже) требует кастомной обработки.
После завершения маршрута ACL routing очищается, документ возвращается к исходному ACE-набору (автор, BU-роли через мета-роли и т.д.).

5.3 Делегирование (computed groups)#

Делегирование реализовано через ComputedGroupsService (см. memory project_delegation_computed_groups, миграция завершена 2026-04-21). На время делегирования пользователь-делегат автоматически попадает в вычисляемую группу делегатора и наследует все его права (включая per-BU child-роли и license-группы).

5.4 Чат-доступ#

Чат (RuxeoChatRoom) хранит ACL независимо от документа-контекста. Ключевые моменты:

Наследование заблокировано в setupChatRoomACL() — localAcl.add(ACE.BLOCK). Это намеренно: участник чата не получает доступ к привязанному документу, а читатель документа не получает доступ к чату.
Участник чата получает ReadWrite на сам чат (через grantChatAccess). Не на родительский документ.
Удаление участника через removeParticipant() вызывает revokeChatAccess() — ACE удаляется.
SSE-канал проверяет членство в chatParticipants — события message_added/updated/deleted уходят только участникам.

Реализация: RuxeoChatServiceImpl.setupChatRoomACL() (л. 1226–1264), RxbmInviteToChatOperation.

6. ACL на корневых папках (security setup)#

Операции Rx**.SetupMetaRolePermissions и Rx**.SetupBUWorkspaceACLs (XML-определения в *-security-setup.xml каждого модуля) накладывают ACE на корневые workspace.

6.1 Соглашение об именах ACL#

{module}_meta_roles — ACL на глобальных корневых папках (например, /default-domain/workspaces/{ModuleRoot}). Кому: мета-ролям.
{module}_bu_{buCode} — ACL на BU-папке. Кому: per-BU child-ролям.

6.2 Кто создаёт корневые папки модулей#

Корневые workspace создаёт RxbmRepositoryInitializationService через дескрипторы FolderStructureDescriptor (см. контрибушены в rxbm-repository-init-contrib.xml и аналогичные модульные). Структура BU:

/default-domain/workspaces/
    DirectoriesWSP/             — общесистемные справочники
    DocFlow/                    — корень DocFlow модуля
    Contracts/                  — корень контрактов
    FinArch/
    ...
    {BU code}/                  — корневая папка БЕ
        DocFlow/
        Contracts/
        ...

6.3 Сводная таблица ACE (выборка)#

Модуль	ACL	Группа	Permission
rxbm	meta_roles	`rxbm_meta_sys_admins`	`Everything`
rxbm	meta_roles	`rxbm_meta_bu_admins`	`ReadWrite`, `BaseModule.ManageBU`
rxbm	meta_roles	`rxbm_meta_config_managers`	`Read`, `BaseModule.ManageSettings`
rxbm	meta_roles	`rxbm_meta_orgstructure_managers`	`Read`
rxbm	meta_roles	`rxbm_meta_auditors`	`Read`
rxbm	meta_roles	`rxbm_meta_viewers`	`Read`
rxbm	bu_{code}	`Администраторы {BU}`	`Everything`
rxbm	bu_{code}	`Пользователи {BU}`	`Read`+`AddChildren`
rxbm	bu_{code}	`Делопроизводители {BU}`	`Read`
rxbm	bu_{code}	`Менеджеры сотрудников {BU}`	`ReadWrite`
rxdf	meta_roles	`rxdf_meta_admins`	`Everything`
rxdf	meta_roles	`rxdf_meta_template_managers`	`Read`
rxdf	meta_roles	`rxdf_meta_registrars`	`Read`
rxdf	meta_roles	`rxdf_meta_clerks`	`ReadWrite`
rxdf	bu_{code}	`Делопроизводители ДО {BU}`	`ReadWrite`
rxcm	meta_roles	`rxcm_meta_admins`	`Everything`
rxcm	meta_roles	`rxcm_meta_managers`	`ReadWrite`
rxcm	bu_{code}	`Менеджеры договоров {BU}`	`ReadWrite`
rxfa	meta_roles	`rxfa_meta_admins`	`Everything`
rxfa	bu_{code}	`Бухгалтеры {BU}`	`ReadWrite`
rxhr	meta_roles	`rxhr_meta_hr_managers`	`Everything`
rxhr	bu_{code}	`HR-менеджеры {BU}`	`Everything`
rxar	meta_roles	`rxar_meta_admins`	`Everything`
rxar	bu_{code}/Nomenclatures	`rxar_{BU}_nomenclature_managers`	`LTArch.ManageNomenclature`
rxar	bu_{code}/ArchiveCases	`rxar_{BU}_archivists`	`LTArch.Read`
rxar	bu_{code}/DisposalActs	`rxar_{BU}_disposal_specialists`	`LTArch.CreateDisposalAct` + `blockInheritance=true`

Полные списки см. в OSGI-INF/{module}-security-setup.xml каждого модуля.

6.4 Custom permissions#

Каждый модуль регистрирует свой набор кастомных прав в *-permissions.xml:

Модуль	Группа	Кол-во	Пример важных
Base	`BaseModule`	38	`Admin`, `ManageBU`, `EditBUCard`, `ManageBusinessUnits`, `ManageDivisions`, `CreateEmployee`, `ViewPersonalData`, `RegisterDocument`, `ManageDelegation`, `ManageDirectories`, `UseChat`, `ViewAuditLogs`
DocFlow	`DocFlow`	16	`Read`, `Create`, `Edit`, `Register`, `Approve`, `Sign`, `StartWorkflow`, `CreateResolution`, `ControlExecution`, `Admin`
Contract	`Contract`	16	`Read/Create/Edit`, `Approve`, `Sign`, `CreateAgreement`, `ViewFinancial`, `EditFinancial`, `ViewConfidential`, `Admin`
FinArch	`FinArch`	17 + 6 legacy	`Process`, `TrackOriginal`, `ManageDocumentSet`, `ManageBankGuarantee`, `ViewFinancial`, `ControlSLA`, `Admin`
HR	`HRArchive`	11	`ManagePersonnelEvents`, `ManageLeave`, `ApproveLeave`, `ManageConsent`, `ViewPersonalData`, `Admin`
LTArch	`LTArch`	21	`ManageNomenclature`, `ApproveNomenclature`, `ManageCases`, `ManageStorage`, `ManageBorrowing`, `ApplyLegalHold`, `CreateDisposalAct`, `ExecuteDisposal`, `Admin`

Каждый *.Admin через <include>Everything</include> означает «полный контроль».

7. Алгоритм проверки доступа#

Когда пользователь открывает документ или функцию, Nuxeo / Ruxeo последовательно проходят:

1. Принципиал — администратор?  → YES  → ACCESS GRANTED (короткое замыкание)
                                  ↓ NO

2. RxbmModuleAccessSecurityPolicy:
       moduleId = getModuleIdForDocType(doc.type)
       moduleId == null?  → пропускаем (не модульный doc)
       hasModuleAccess(user, moduleId)?  → NO → DENY
                                          ↓ YES

3. Стандартный Nuxeo ACL-стек:
       ACP = mergedAcp = LOCAL_ACL ⊕ INHERITED_ACL ⊕ ROUTING_ACL
       для каждой группы пользователя (включая parentGroups и computed):
         если есть ACE (group, requested_perm, granted) — GRANTED
         если есть ACE (group, requested_perm, denied)  — DENY
       Иначе — DENY (deny-by-default).

4. Для UI-фильтров (drawer, плитка, отчёт): дополнительно сервер/клиент
   спрашивают принадлежность к {module}_licensed_users.

Ключ для тестировщика. Если документ открывается с ошибкой «доступ запрещён», проверять надо в порядке: (1) состоит ли пользователь в {module}_licensed_users, (2) состоит ли в подходящей Per-BU child role (которая нужна на этом workspace), (3) если задача — открыта ли она ещё.

8. Связь ролей и функциональности (для тестировщика)#

Сводная таблица «что я как тестировщик увижу, если попаду в группу X»:

Группа	Drawer / Cover Page	Что могу делать
`administrators`	Все модули	Всё
`rxdf_licensed_users` + `Пользователи ЦЕНТР`	Документооборот	Создание/чтение документов в БЕ ЦЕНТР, запуск процессов
`rxdf_licensed_users` + `Регистраторы ЦЕНТР`	Документооборот	+ регистрация документов в ЦЕНТР
`rxdf_licensed_users` + `Согласующие ЦЕНТР`	Документооборот	+ согласование (workflow-задачи приходят сюда)
`rxdf_licensed_users` + `Подписанты ЦЕНТР`	Документооборот	+ подписание
`rxdf_licensed_users` + `Делопроизводители ДО ЦЕНТР`	Документооборот	+ полный ReadWrite на DocFlow-workspace БЕ ЦЕНТР
`rxdf_licensed_users` + `Просмотрщики ДО ЦЕНТР`	Документооборот	Только чтение
`rxcm_licensed_users` + `Менеджеры договоров ЦЕНТР`	Договоры	Создание/ведение договоров в БЕ ЦЕНТР
`rxcm_licensed_users` + `Подписанты договоров ЦЕНТР`	Договоры	Подписание (workflow)
`rxcm_licensed_users` + `Финансовые контролеры договоров ЦЕНТР`	Договоры	Контроль дорогостоящих договоров
`rxfa_licensed_users` + `Бухгалтеры ЦЕНТР`	Финансовый архив	ReadWrite на финдокументы БЕ
`rxhr_licensed_users` + `HR-менеджеры ЦЕНТР`	Кадровый архив	Everything на HR-данные ЦЕНТР
`rxar_licensed_users` + `rxar_meta_archivists`	Архив	Чтение архивных дел, добавление документов
`rxar_licensed_users` + `rxar_meta_disposal_specialists`	Архив	Создание актов уничтожения (по подпапке `DisposalActs/`)
`rxsm_licensed_users` + (любая платформенная роль)	Service Management	Создание заявок
`rxbm_meta_sys_admins`	Admin Center (часть)	Системная конфигурация (без `administrators` Nuxeo)
`rxbm_meta_directory_managers`	Admin Center → Справочники	Управление справочниками
`rxbm_meta_orgstructure_managers`	Admin Center → Оргструктура	Управление БЕ и подразделениями

9. Известные гэпы и риски#

Эти моменты влияют на тестирование и могут быть восприняты как «недоступный функционал», но являются архитектурными ограничениями или незакрытыми задачами.

G-1. RXAR централизован — нет per-BU дочерних ролей#

LT Archive (rxar) не создаёт дочерних ролей при добавлении БЕ. Все права раздаются плоским мета-ролям (rxar_meta_archivists, …). Пользователь, имеющий обычную BU-роль «Пользователи ЦЕНТР», не получит доступ к архиву ЦЕНТР через эту роль.

Что делать тестировщику: для архивных кейсов добавляйте пользователя в плоские rxar_meta_* группы напрямую.

G-2. CRM — глобальный домен, нет SetupBUWorkspaceACLs#

CRM применяет SetupMetaRolePermissions к /crm (глобальная папка), а SetupBUWorkspaceACLs для CRM не предусмотрена. CRM-данные доступны через мета-роли централизованно.

G-3. При удалении БЕ дочерние роли не удаляются автоматически#

deleteChildRolesForBU() есть в сервисе, но листенер не вызывает его на directoryEntryDeleted. Пустые группы могут накапливаться. Влияния на доступ нет (никто в них уже не входит), но они захламляют UserManager.

G-4. SetupBUWorkspaceACLs запускается вручную#

Операции Rx**.SetupBUWorkspaceACLs определены, но не вызываются автоматически при создании BU-workspace. Их надо запускать через Admin UI → Security Setup или Automation. Если на стенде создали БЕ, но операцию забыли вызвать — BU-папка без BU-ACE, доступ только через parentGroups-мета-роли.

Проверка: на тестовом стенде после создания свежей БЕ выполнить Rxbm.SetupBUWorkspaceACLs + аналогичные для модулей, иначе локальных ACE на workspace БЕ не будет.

G-5. Делегирование задач (handoff внутри задачи) не передаёт ACL автоматически#

Если внутри открытой задачи пользователь передаёт её другому, новый assignee получит ACL только при следующем taskCreated. До тех пор он не видит документ. Делегирование через computed-groups (контур D §5.3) работает иначе — там делегат сразу подхватывает все права делегатора.

G-6. Версии и приложения не наследуют workflow-ACL#

Когда workflow выдаёт ReadWrite участнику на основной документ, старые версии и child-документы (приложения) не получают этот ACE. Если задача требует анализа истории — нужны прямые права (мета-роль rxbm_meta_auditors или просмотрщик).

G-7. Чат и документ — разные ACL#

Намеренное архитектурное решение (см. CHAT_TOBE_SPECIFICATION.md). Тестировщику может казаться странным, что он: - видит чат, но не видит документ-контекст (unfurl-карточка с пометкой «нет доступа»), - или видит документ, но не видит чат на нём (его не пригласили в чат).

Это не баг.

G-8. Несогласованность именования групп в RXAR#

В rxar-security-setup.xml ACL ссылается на группы вида rxar_{buCode}_archivists (английский паттерн), тогда как остальные модули используют русские локализованные имена Архивисты {BU}. Если такие группы не создаются (см. G-1), ACE «висит в воздухе» и никто прав не получает. Это потенциальный источник «недоступного функционала».

G-9. Лицензионные группы и `administrators` — fail-open поведение#

Если RxbmModuleAccessService недоступен (например, при старте), RxbmHomeModuleTileService не фильтрует плитки. На раннем этапе старта приложения тестировщик может временно увидеть лишние модули — это известное fail-open поведение, не баг.

G-10. Тестирование роли «обычного пользователя»#

Чтобы корректно протестировать систему «глазами линейного сотрудника БЕ ЦЕНТР» без админских прав, минимальный набор:

- {module}_licensed_users           (для каждого нужного модуля)
- Пользователи ЦЕНТР                (rxbm_meta_bu_users → BU-чтение)
- Возможно: Согласующие ЦЕНТР / Подписанты ЦЕНТР — для проверки WF-задач

Чтобы увидеть админский функционал на уровне БЕ, нужна Администраторы ЦЕНТР (наследник rxbm_meta_bu_admins).

Чтобы увидеть системный админский функционал (справочники, оргструктура) — соответствующая системная мета-роль (rxbm_meta_directory_managers, rxbm_meta_orgstructure_managers и т.д.), а не глобальные administrators.

10. Что отдать тестировщику (чек-лист)#

Эта спека — ответ на «откуда я получаю доступ».
Список БЕ, в которых ведётся тестирование, и кодов БЕ.
Учётка тестировщика, явно включённая в:
{module}_licensed_users для каждого тестируемого модуля;
Пользователи {BU} (как минимум) — для базового чтения;
дополнительные per-BU роли по сценарию (Согласующие, Подписанты, и т.д.);
системная мета-роль, если нужны общесистемные настройки (rxbm_meta_directory_managers для справочников и т.п.).
Гарантия, что для тестовой БЕ выполнена операция SetupBUWorkspaceACLs всех тестируемых модулей (см. G-4).
Уведомление: не использовать administrators (Nuxeo built-in) — она перекрывает все проверки и скрывает реальные права.

Changelog#

Версия	Дата	Изменения
1.0	2026-05-13	Первая ревизия. Сводка по 4 контурам + полный реестр ролей + 10 гэпов.