Права доступа к кнопке или полю из поля задачи

[tech]

Добрый день всем. Насколько была бы интересна возможность назначать того, кому показывать кнопку или дать возможность редактировать поле не выбором из системных полей (постановщик, исполнитель, аудитор) и не на основе вхождения в рабочую группу, а из пользовательского поля задачи? И тогда уж наоборот - всем за исключением сотрудника или контакта из пользовательского поля задачи.

[Сергей Голубев]

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

[Митраков Евгений]

Однозначно +

[Роман Колмаков]

+

[Денис Сахаров]

Желаем немедленно!

[Dmitry Goncharenko]

А накидайте, пожалуйста, примеров - в каких ситуациях и какие задачи это бы решило.

[tech]

Добрый день, Дмитрий. Спасибо, что читаете.
Пример - делаю "под себя" вариант процессинга "На чьей стороне мяч". Задача - сделать так, чтобы обратиться к нужному сотруднику мог любой из тех, у кого есть доступ к задачу, но нажать кнопку "Забрать мяч" мог только тот, кто мяч передал.
Два пользовательских поля типа Сотрудник - "На чьей стороне мяч" - доступ к редактированию и всех, у кого есть доступ к задаче. и "Кто передал" (Инициатор) - доступа нет ни у кого.
Кнопка "Забрать мяч" - доступ только у сотрудника из поля "Кто передал".
При изменении поля "На чьей стороне мяч" сценарием автор изменения заносится в поле "Кто передал" и он получает доступ к кнопке "Забрать мяч".
По нажатию кнопки оба поля очищаются.
Дополнительный сценарий - если поле "На чьей стороне мяч" изменено не другим сценарием и предыдущее значение не равно "Не выбрано" - вернуть предыдущее - это на случай, если кто решит изменить не кнопкой (доступ-то есть у всех).

Аналогично с оформлением запроса на расходы. Тут подробно расписывать нет надобности - понятно, что нажать кнопку "Деньги получил" должен иметь возможность только тот, кто запрос оформил. И не всегда он Постановщик, т.к. у Постановщика слишком много прав. Делаю Постановщиком робота. А Исполнитель - тот, кто деньги выдаёт. Приходится костыли придумывать с включением того, кто запрос оформил в рабочую группу, исключением из неё и т.д. Но права рабочей группы распространяются на весь аккаунт, и получается, что пока такая задача у сотрудника одна - костыль работает. А если несколько - где задачи в разных статусах и права должны быть разные - не работает.

[Dmitry Goncharenko]

Спасибо, красивые примеры. Штука сложная, но обсудим, насколько реально так сделать.

[tech]

Спасибо, Дмитрий!

[Dmitry Goncharenko]

Обсудили, видим тут решение чуть в другой плоскости - появление возможности задать кастомную роль на уровне задачи/шаблона и давать доступ ей. То есть, в примере про получение денег под отчет заводим роль "Финответственный", и даем возможность редактировать поле "Деньги получены" только сотруднику в этой роли.

Такая доработка есть у нас в планах, надеюсь тут порадовать новостями через какое-то время.

[tech]

Спасибо, Дмитрий!

[Кирилл Киреев]

Да, очень часто такая опция нужна.

Примеры такие же как у коллег, оформляет заявку кто-то приходится выкидывать его из постановщиков в поле типа «инициатор» и костылять.

[Кирилл Киреев]

Ещё пример: работает над сделкой продавец. Он может редактировать все поля сделки, но когда сделка перетекает в стадию сопровождения договора у него остаётся доступ и ряд полей он может редактировать, а ряд не может. И тут снова жонглирование и компромиссы между группами сотрудников /системными ролями в задаче

[Smirnov Yuri]

Поддерживаю. +1