Доступ к записям при увольнении сотрудника

[HakimzyanovA]

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

Вот. А как сделать, чтобы обращения клиентов, которые создает пользователь, автоматически назначались на ту группу доступа, к которой этот пользователь принадлежит? Допустим, группу доступа, которая обрабатывает обращения из данного населенного пункта

[sanys]

Обновление 2.7
Действие автоматизации при создании записи.
Действие разрешаем для нужной группы пользователей.
Настраиваем в действии автоматизации какие поля должны быть установлены автоматически (Например поле Группа пользователей) при создании записи. Подразумевается, что для пользователя, который создает запись, данное поле недоступно.

[HakimzyanovA]

Я выше спрашивал о возможности такого решения...
Но ведь группа для разных пользователей разная должна быть, для Петрова и Иванова одна, для Сидорова другая. Как с этим быть?

[support]

Коллеги, я уже запланировал функционал объедения аккаунтов. Войдя под своим аккаунтом, можно будет переключится на другой, привязанный к тебе аккаунт человека, который в отпуске или уволился. Связывать аккаунты сможет администратор.
Пока такого функционала нет, вы можете просто передавать учетные записи человека, который уволился, другому сотруднику.
Если же такой вариант не подходит, и хочется видеть все задачи записи под одним аккаунтом, тогда через автоматизацию нужно менять назначенных или создателя...

[HakimzyanovA]

тогда через автоматизацию нужно менять назначенных или создателя...

А как поменять через автоматизацию назначенных в большом количестве записей сразу?

[HakimzyanovA]

Имхо, если бы в автоматизацию при создании новой записи добавить функцию назначения новой записи на группу доступа в зависимости от значения полей записи, это было бы гораздо более гибко и позволило решить широкий класс задач.
Например:
1. Если "создано"="Иванов" то "назначено на"=группа "операторы1"
2. Когда запись создана в публичной форме, там "создано" пусто. Поэтому нужно условие вида
Если "Город"="Город1" то "назначено на" =группа "операторы1"

т.е. не нужно ограничиваться именно случаем увольнения или болезни сотрудника

Войдя под своим аккаунтом, можно будет переключится на другой, привязанный к тебе аккаунт человека, который в отпуске или уволился.

В некторых случаях будет очень неудобно. Вы представьте: стоит очередь клиентов перед оператором, а он переключается между тремя аккаунтами - своим и еще двоих уволившихся, чтобы найти предыдущее обращение клиента, который пришел во второй раз...

И еще один момент - Петров ушел на больничный, администратор передал запись Иванову. В журнале аудита действия будут отражены под Петровым, если Иванов переключится на эту запись? С точки зрения безопасности не очень правильно.

[support]

Вы представьте: стоит очередь клиентов перед оператором, а он переключается между тремя аккаунтами - своим и еще двоих уволившихся, чтобы найти предыдущее обращение клиента, который пришел во второй раз...

В таком случае назначать обращение на конкретного пользователя - не корректное решение. Я бы использовать тип поля "Группа пользователей", создал бы там отдел для каждого пользователя и назначал обращение на отдел. Ушел сотрудник в отпуск или уволился, я бы изменил пользователя для отдела и нет проблем.

Еще есть правила видимости, тоже можно с ними что то придумать, но тут уже нужно смотреть на конкретные задачи
https://docs.rukovoditel.net.ru/index.php?p=82

А как поменять через автоматизацию назначенных в большом количестве записей сразу?

Есть массовое обновление записей, выбрали записи сотрудника, который уволился, и изменили назначенного пользователя. Можно этот процесс сделать через автоматизацию.

[Oleg]

Коллеги, я уже запланировал функционал объедения аккаунтов. Войдя под своим аккаунтом, можно будет переключится на другой, привязанный к тебе аккаунт человека, который в отпуске или уволился. Связывать аккаунты сможет администратор.
Пока такого функционала нет, вы можете просто передавать учетные записи человека, который уволился, другому сотруднику.
Если же такой вариант не подходит, и хочется видеть все задачи записи под одним аккаунтом, тогда через автоматизацию нужно менять назначенных или создателя...

Это будет круто, долга жду этот функционал. Спасибо большое

[HakimzyanovA]

В таком случае назначать обращение на конкретного пользователя - не корректное решение.

Совершенно с Вами согласен. Смотрите: оператор сидит на потоке клиентов, принял документы, отсканировал, создал обращение, следующий клиент. Иногда клиентов очень много. Т.е. сейчас оператор не назначает ни на кого обращение.
Можно конечно вменить ему это в обязанности, но будут ошибаться, назначив не на ту группу и тд.
Кроме того, есть обращения через публичную форму, у которых поля "создано" и "назначено" пустые после создания.

Я поэтому и ищу способ автоматизировать процесс назначения новой записи на группу.

[sanys]

А как поменять через автоматизацию назначенных в большом количестве записей сразу?

1. Делаете бэкап базы
2. Создаёте процесс автоматизации для нужной сущности.
3. Кнопку размещаете в Меню с выбранными.
4. Назначаете кнопку только для администратора.
5. В фильтрах процесса настраиваете выбор записей уволенного сотрудника.
6. В действиях добавляете действие изменения поля created_by на нужного пользователя.
7. Переходите в сущность и выбираете все записи.
8. Действие с выбранными - Ваш процесс.
9. Проверяете.
Если что-то пошло не так, откатываете базу обратно.
Естественно все проводить в режиме обслуживания, что бы во время работы не добавлялись новые данные.