Пользовательский контекст: правила маршрутизации пользователей между порталами и агентстким интерфейсом
https://home.simpleone.ru/record/article/158591871514542862
Правила, определяющие каким пользователям какие интерфейсы и порталы доступны в зависимости от пользовательских критериев.
Под портальным контекстом подразумевается, предопределенный картой портала, набор страниц, либо агентский интерфейс.
После авторизации пользователя, либо при попытке перехода по URL уже авторизованного пользователя, либо после имперсонации под другим пользователем производится проверка портального контекста пользователя, на основании префикса портала, если он указан в URL и правил портального контекста, содержащих пользовательские критерии (UC). В результате подобной проверки определяется может ли пользователь работать в контексте текущего портала, если да то переходит на главную страницу этого портала, если нет, то производится поиск первого доступного портала и переход на его главную страницу.
Портальный контекст сохраняется в течении всего пользовательской сессии.
Предполагаем, что в системе будет существовать набор правил для каждого портала, определяющий:
порядок применения порталов
категории пользователей, для которых портал доступен
правила редиректа контроллеров агентского интерфейса на страницы/ноды портала (record, list, page)
Механизм должен носить опциональный характер и для управления его активацией/деактивацией предполагается наличие системного свойства (portals.portal_context.enable: true/false).
В случае, если портал или агентский интерфейс не имеет правил портального контекста, то он доступен любым пользователям.
Для пользователей с ролью admin/vendor портальный контекст не учитывается. Перечень ролей указывается в системном свойстве (portals.portal_conteхt.override_roles admin, itsm_agent, etc.) Вендор в явном указании не нуждается.
В случае, если для пользователя не найден ни один портальный контекст, то происходит переход на страницу 403.
Для каждого портала и для агентского интерфейса возможен только один набор правил.
Функционально обеспечена реализация следующих кейсов:
Кейс для администратора:
1. Создаю новый контекст портала.
2. В форме выбираю портал из списка порталов (еще не имеющих контекста) или агентский интерфейс(также, если контекст для него еще не существует).
3. Контекст портала приобретает имя портала или агентского интерфейса
4. Указываю порядок проверки контекста (целое число)
5. В связанном списке “Аудитория”(Audience или Auditory) выбираю категории пользователей, которым контекст доступен. Категории определяются пользовательскими критериями. Проверка критериев производится через “ИЛИ”.
5. В связанном списке ”Маппинг страниц” (Page Mapping), в новых записях указываю название контроллера агентского интерфейса и соответствующую страницу портала.
6. Для активации контекста устанавливаю флаг “Active”.
Кейсы пользователя, при активированном механизме проверки портального контекста:
Примеры использования для "агентских" ссылок:
Пример 1:
1. авторизуюсь через системную страницу логина /login
2. доступен агентский контекст, переходим на главную страницу после авторизации
3. не доступен агентский контекст, но найден первый доступный портальный контекст, переходим на главную страницу данного портала
4. нет ни одного доступного контекста, переходим на 403
Пример 2:
1. перехожу по ссылке в агентском интерфейсе, например /form/change_request/XXXXXXXXXXXXXXXXX
2. доступен агентский контекст, переходим на страницу в агентском интерфейсе после авторизации
3. не доступен агентский контекст, но найден первый доступный портальный контекст,
4. ищем соответствующую контролеру страницу в маппинге страниц
5. нашли, переходим на эту страницу портала, с передачей параметров в URL.
6. не нашли открываем портальную 404
7. нет ни одного доступного контекста, переходим на 403
Примеры использования для "портальных" ссылок:
1. авторизуюсь через портальную страницу логина /portal_suffix/login
2. проверяем доступен ли пользователю контекст для portal_suffix
- да, переходим на главную страницу портала portal_suffix
- не доступен контекст для portal_suffix ищем другие контексты
3. производим поиск других доступных контекстов,
- нашли, переходим на эту страницу портала, с передачей параметров в URL
- не нашли, нет ни одного доступного контекста, переходим на 403
4. перехожу по портальной ссылке /portal_suffix/announce?XXXXXXXXXXXX
5. проверяем доступен ли пользователю контекст для portal_suffix
- да, переходим на страницу портала/portal_suffix/announce
- не доступен контекст для portal_suffix ищем другие контексты
6. производим поиск других доступных контекстов,
- нашли, переходим на указанную страницу портала, если в карте портала есть такая страница, с передачей параметров в URL, иначе 404 страница найденного портала
- не нашли, нет ни одного доступного контекста, переходим на 403
Что уже есть, что можно вытащить из сторис
есть свойство portals.portal_context.enable, По-умолчанию значение false. Принимает true/false., Свойство создано и используется для включения и отключения механизма
есть свойство portals.portal_context.override_roles, Свойство создано и используется в механизме для задания ролей, для которых механизм будет отключен. По-умолчанию пустое значение. Принимает список ролей, для которых отключен механизм.