> For the complete documentation index, see [llms.txt](https://docs.aamsystems.ru/passoffice/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aamsystems.ru/passoffice/passoffice-guide/admin-guide-doc/administration/profili-operatorov/migraciya-profilei.md).

# Миграция профилей

**Что изменилось в версии 1.9**

До версии 1.9 все настройки оператора (настройки оператора, настройки внешнего вида, роли, аудит, уведомления) хранились в операторе.\
Начиная с версии 1.9 они вынесены в отдельный объект **«Профиль оператора»**.

#### Как происходит миграция

**Бюро пропусков**

После обновления система автоматически создаст **несколько отдельных профилей** для каждого уникального набора настроек:

* Профиль с **ролями**
* Профиль с **настройками оператора и настройками внешнего вида**
* Профиль с **группами операторов**
* Профиль с **событиями аудита**
* Профиль с **каналами уведомлений**

Если у нескольких операторов полностью совпадали роли — будет создан **один общий профиль ролей**. Если совпадали настройки оператора и настройки внешнего вида — один общий профиль этих настроек. Аналогично для аудита и каналов уведомлений.

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

После миграции вы сможете при необходимости объединить или отредактировать эти профили вручную.

**Active Directory**

Если до обновления до версии 1.9 в Active Directory были заданы:

* роли
* настройки оператора
* настройки внешнего вида

— после миграции они **не потеряются** и будут перенесены автоматически.

Перейдите в раздел: **Настройки интеграции → Active Directory → Профили операторов**

В открывшейся таблице вы увидите:

| Столбец                | Что будет указано                                                                                                                                               |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Группа AD**          | Название группы из Active Directory, к которой привязывались настройки                                                                                          |
| **Профили операторов** | Список созданных профилей (роли, настройки оператора и настройки внешнего вида), которые система автоматически сгенерировала из прежних настроек этой группы AD |

То есть связь «группа AD → набор прав и настроек» полностью сохраняется, просто теперь вместо прямого указания ролей и настроек в AD используется объект **«Профиль оператора»**.

**Что делать дальше**

* При необходимости можно отредактировать или объединить созданные профили.
* Новые группы AD можно сразу привязывать к уже существующим или новым профилям оператора.

После миграции ничего вручную переносить не нужно — всё работает как раньше, только через удобные профили.

**OpenID**

Аналогично Active Directory после обновления до версии 1.9 произойдёт автоматическая миграция настроек OpenID.

Если ранее в настройках OpenID для атрибутов (claims) были заданы роли, настройки оператора и настройки внешнего вида, после миграции они будут преобразованы следующим образом:

Перейдите в раздел: **Настройки интеграции → OpenID → Профили операторов**

В таблице вы увидите строки вида:

| Атрибут OpenID (claim) | Профили операторов (созданные автоматически)                                          |
| ---------------------- | ------------------------------------------------------------------------------------- |
| adminRole (пример)     | Список профилей оператора, которые система создала из прежних значений этих атрибутов |

То есть связь «значение атрибута OpenID → набор прав и настроек» полностью сохраняется, но теперь вместо прямого указания ролей и настроек в claim используется объект **«Профиль оператора»**.

После миграции всё работает автоматически и без ручных действий:

* пользователи продолжают логиниться через OpenID с теми же правами
* при необходимости вы можете отредактировать или объединить созданные профили
* новые атрибуты OpenID сразу можно привязывать к существующим или новым профилям оператора

#### Как объединяются несколько профилей у одного оператора

Если оператору назначено сразу несколько профилей, итоговые настройки формируются по следующим простым правилам:

**Чекбоксы (включено/выключено)**

* Если опция включена **хотя бы в одном** профиле — в результате она будет **включена**.

**Числовые значения**

* Берётся значение из **первого** профиля, где оно задано.

**Списки разрешений** (доступные площадки, категории, группы доступа и т.п.) и **Списки по умолчанию** (площадка по умолчанию, группа доступа по умолчанию и т.п.)

* Списки **объединяются**.
* Если в любом из профилей стоит «Все» — в результате будет «Все».

**Запреты и ограничения** (например, «запретить оформление заявок для определённых подразделений»)

* Если в любом из профилей запрета **нет** — в результате запрета тоже не будет.

**Отчёты**

* Видимость отчётов, мониторы и пользовательские отчёты — **объединяются** (если отчёт виден хотя бы в одном профиле — он будет виден).
* Настройки колонок и трансформеров — берутся из **первого** профиля.

**Шаблоны редакторов, CSV, QR-кодов и другие шаблоны**

* Берётся из **первого** профиля, где они заданы.

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.aamsystems.ru/passoffice/passoffice-guide/admin-guide-doc/administration/profili-operatorov/migraciya-profilei.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.