Сделки. Гибкая настройка прав для роли в разных статусах

Avatar
Пак Ирина
  • обновлен

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

User Story: Я, как администратор схемы сделки, находясь в настройке прав доступа к свойству "Х" в статусе "А" могу настроить права доступа для определенной роли "!" индивидуально и это не затронет права другой роли и права настраиваемой роли "!" в другом статусе.

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

Ответы 8
Avatar
2
Васюкова Инесса

Права для разных ролей в разных статусах регулируют динамические роли. Почему здесь они не подходят? Зачем в каждом статусе настраивать разные права доступа из настроек прав (если я правильно поняла)?

Почему в Статусе 1 Иванов И. имеет доступ "может делиться файлами" а в статусе 2 не имеет такого права? Все права из настроек прав относятся к иным модулям (не сделки).

Avatar
1
Брофман Александр
Цитата от Васюкова Инесса

Права для разных ролей в разных статусах регулируют динамические роли. Почему здесь они не подходят? Зачем в каждом статусе настраивать разные права доступа из настроек прав (если я правильно поняла)?

Почему в Статусе 1 Иванов И. имеет доступ "может делиться файлами" а в статусе 2 не имеет такого права? Все права из настроек прав относятся к иным модулям (не сделки).

Как пример, если есть необходимость зафиксировать в Статусе 2 заполненное в Статусе 1 поле, после чего вывести его из оборота и скрыть на последующих статусах.

Лично у меня был опыт, когда сотрудник с правом доступа в поле на завершающих статусах "подбивал" данные под нужные себе. 

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

Avatar
0
Васюкова Инесса
  • На рассмотрении
Цитата от Брофман Александр

Как пример, если есть необходимость зафиксировать в Статусе 2 заполненное в Статусе 1 поле, после чего вывести его из оборота и скрыть на последующих статусах.

Лично у меня был опыт, когда сотрудник с правом доступа в поле на завершающих статусах "подбивал" данные под нужные себе. 

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

То есть вам приходится заводить сколько сотрудников - столько и ролей? И вам нужно на каждого сотрудника для каждого статуса право на просмотр/редактирования поля?

Avatar
1
Брофман Александр
Цитата от Васюкова Инесса

То есть вам приходится заводить сколько сотрудников - столько и ролей? И вам нужно на каждого сотрудника для каждого статуса право на просмотр/редактирования поля?

Да, для реализации необходимой логики приходится изворачиваться. 

Да, мне необходимо на разных статусах разный уровень доступа, при этом применяющееся правило "выполняется самое строгое правило" не дает настроить на определенный статус право на чтение, при условии, что на дальнейших статусах или статусах до этого поле должно быть спрятано. 

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

Avatar
2
(Админ) Кулевацкий Сергей Анат

Уважаемые коллеги, 

1) речь идет об элементарных (т.е. минимально допустимых) требованиях по разграничению прав доступа пользователей (хотя бы и на уровне ролей) к данным;

2) режим настройки схемы процесса изначально разработан для обеспечения возможности для каждой роли назначить права доступа (пусть даже из ограниченного набора значений и по конкретно заданному правилу) к каждому из свойств в каждом  из статусов ИНДИВИДУАЛЬНО,  т.е. БЕЗ ВЛИЯНИЯ на права других ролей и/или на права доступа к конкретных свойств в других статусах. На это же указывает и его описание в документации - см. НАСТРОЙКА ПОЛЕЙ и ПАРАМЕТРЫ ПОЛЕЙ:

  https://help.megaplan.ru/article/settings/deals/programm#%D1%81%D1%85%D0%B5%D0%BC%D1%8B-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2-%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-%D0%BF%D0%BE%D0%BB%D0%B5%D0%B9-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2. 

Таким образом речь идет об отсутствии в Мегаплане ЗАЯВЛЕННОЙ базовой функциональности по обеспечению разграничения прав доступа или о баге в ее реализации. 

И это в эксплуатируемой коммерческой системе. Вы что шутите?!!! Кому и какие еще аргументы нужны для того, чтобы НЕМЕДЛЕННО начать устранять эту проблему? 

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

Avatar
0
Лихацкий Сергей
Цитата от Васюкова Инесса

Права для разных ролей в разных статусах регулируют динамические роли. Почему здесь они не подходят? Зачем в каждом статусе настраивать разные права доступа из настроек прав (если я правильно поняла)?

Почему в Статусе 1 Иванов И. имеет доступ "может делиться файлами" а в статусе 2 не имеет такого права? Все права из настроек прав относятся к иным модулям (не сделки).

Чет много текста, и суть ускользает на мой взгляд. Простой пример для 100% аккаунтов:
есть менеджер и есть РОП.
Менеджеру - нужно в разных статусах разные поля показывать или прятать, банально из-за большого их количества в целом, к примеру.
РОПу - нужно все поля видеть на всех статусах, для аналитики, как минимум...

Нужно для КАЖДОЙ роли добавить настройки по СТАТУСАМ, не меняя текущую логику и все) 

Avatar
0
Константинов Илья

Добавлю, что доп поля сделки (все допы, что созданы) необходимо МЕНЯТЬ местами.

Например если вверху идет клиент (и поля по нему), потом скажем "объект" и данные по нему, а внизу  группа "x" и данные по нему - то для МЕНЕДЖЕРА такой порядок ОК, а вот для ДРУГОЙ роли- нет. Я хочу группу "x" для другой роли показывать вверху, а не внизу.

Прошу это также учесть и внести.


Портал поддержки клиентов работает на UserEcho