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

[Лагуто Виталий Евгеньевич]

Здравствуйте

Можно ли ограничить сотрудников в правах на редактирование контактов, действий и т.п.

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

Мне очень нравиться как это реализовано например в Drupal https://cloud.mail.ru/public/MjPZ/LqYfoMaU2

 

[Dmitry Goncharenko]

Здравствуйте, Виталий!
На текущий момент, как правило, тот сотрудник, который создал объект, может его редактировать. Я допускаю, что иногда нужно запретить редактирование, поэтому давайте посмотрим, что скажут по этому поводу другие участники форма. Наберем статистику - какие объекты и в каких ситуациях нужно не давать редактировать (тут примеры из жизни очень помогут проникнуться ситуацией) и подумаем над реализацией.

[Лагуто Виталий Евгеньевич]

Есть печальный опыт в той CRM в которой мы работали. Были как случайные, так и преднамеренные удаления.

Еще смущает что в диалоге удаления кнопка "Отмена" красного цвета... Я бы рефлекторно нажал серую.

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

[Dmitry Goncharenko]

Еще смущает что в диалоге удаления кнопка "Отмена" красного цвета... Я бы рефлекторно нажал серую.

По этому поводу у нас даже внутри команды есть разногласия )

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

Тут, похоже, ошибка. Разберемся и поправим.

[Лагуто Виталий Евгеньевич]

Временное решение пока такое:
1. Создал отдельного пользователя, или можно выбрать иного ответственного или админа.
2. В шаблоне создания контактов и предприятия выставил его в качестве создателя.
3. Поле из шаблона скрыл.
4. Контакт создается от имени "псевдо админа" и править его могут только админы.



 

Добавлено спустя 22 минуты 38 секунд:
В тему поддержки моей идеи с правами хочу добавить, что у Мегаплана это есть :)

[Dmitry Goncharenko]

Временное решение пока такое:
1. Создал отдельного пользователя, или можно выбрать иного ответственного или админа.
2. В шаблоне создания контактов и предприятия выставил его в качестве создателя.
3. Поле из шаблона скрыл.
4. Контакт создается от имени "псевдо админа" и править его могут только админы.

Да, действительно вариант. Хоть и слегка костыльный, но работать будет.

В тему поддержки моей идеи с правами хочу добавить, что у Мегаплана это есть :)

Спасибо, надо будет как-то зарегистрироваться и  глянуть как оно там реализовано, может действительно удачное решение.

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

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

[Лагуто Виталий Евгеньевич]

Костыль для проекта пока не получается. Все равно автор перезаписывается на создателя не смотря на шаблон.

А костыль для задач даже не знаю как сделать. постановщика задачи менять не логично :(

Не могу сказать что в Мегаплане оно реализовано удачно (ИМХО). просто оно там есть и для руководства это является преимуществом.
Мне больше нравиться идея Drupal. Где все модули предоставляют свои функции в общую таблицу. А там под каждую роль пользователя можно указывать доступно это ему или нет. И ролей можно напридумывать много (не только администратор и пользователь).
 

[Лагуто Виталий Евгеньевич]

Добавлю за мнение о необходимости редактировать права и создавать роли viewtopic.php?f=36&t=1968

[Лагуто Виталий Евгеньевич]

Еще в поддержку идеи viewtopic.php?f=36&t=2006

[Илья Федоров]

+1
Но у меня есть другое пожелание, добавить роль "пользователь+". Это должен пользователь для которого доступно изменение любых полей задачи (в рамках шаблона) в том числе сроков - без согласования с Постановщиком или аудитором. Единственное ограничение запрет на "удаление" задачи.
Объясню почему это важно в моем проекте.
Команда небольшая порядка 40 человек. Пока 95% задач это задачи от внешних Постановщиков (как Контрагенты так и обычные покупатели), которых пока в систему пускать не планируем.
Вся переписка идет через систему работы с задачами (сейчас FreshDesk), через отправку сообщений. Сроки для различных задач зависят от ситуации и очень часто от наличия ответа от Постановщика, при этом Постановщик не может диктовать и устанавливать сроки по задаче, они решаются на стороне команды. По части задач (порядка 45%) требуется уточнение информации или согласование с третьей стороной и сроки по таким задачам зависят от того когда ответит Постановщик или третья сторона.
За месяц поступает и обрабатывается порядка 2500 "запросов", распределители задач (руководители) помимо собственно управлением и распределением задач, самостоятельно занимаются решением части задач
Сотрудникам даны полномочия самостоятельно принимать решения о том какой срок установить по задаче ориентируясь на конкретный запрос (задачу), при этом сотрудники работают в команде и если у него не осталось задач в которых он назначен исполнителем, то он может перейти к решению задач сменщика или коллеги (особенный контроль задачам которые ждут ответа-уточнения Постановщика, или переданы на согласование третьей стороне).
Если им оставить роль "пользователь", то им будет заблокировано изменение части полей - например контрагента, и на любую корректировку срока пойдет уведомление аудитору, он должен его подтвердить
Есть обходное решение при выборе Исполнителя (или сразу при создании задачи по проекту, у нас методика проект = группа решения) устанавливать аудиторами всю группу в целом, но это подходит если в группе всего 2-3 человека, а если их больше (например в другой группе планируется количество сотрудников порядка 6 человек+руководитель) то списков уведомляемых да еще и с аватарками занимает очень много места на форме задачи.
Наличие такой роли как пользователь+ позволит решить эту проблему и упростит работу в рамках такого кейса.
Спасибо.

[Вячеслав Дзюба]

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