Роль "Наблюдатель" проекта. Как Аудитор по доступу, но без возможности удаления задач, смены статусов и кастомных полей

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

Столкнулся с недостаточностью ролей в проекте.

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

Хочется иметь роль "Контролер" (или "наблюдатель") в проекте.
Эта новая роль похожа на Аудитора проекта, но без возможности менять статусы и удалять задачи.
Должны быть:
1. Доступ ко всем задачам проекта
Не должно быть
1. Возможности удалять задачи проекта
2. Возможности менять статус задач проекта
3. Возможности менять кастомные поля задач проекта
Еще, как дополнительное пожелание, чтобы Контролеры не показывались бы в списке оповещаемых, когда пишут действие по задаче. Либо здесь может быть 2 режима у контролера. Либо он участник переписки в ленте действий, либо нет.

Теперь кейс, когда это требуется:
В компании выполняются однотипные проекты.
Проекты оформляем проектами, в проекте есть главная задача и подзадачи по типовым этапам.
Внутри этапа могут быть произвольные подзадачи.
В проекте порядка 20 стандартных этапов и порядка 100 подзадач.
Есть отдел руководителей проектов
Один из этого отдела назначается руководителем конкретного проекта.
Требуется, чтобы другие сотрудники отдела руководителей проектов имели бы доступ к информации ко всем таким проектам. Нужно для того, чтобы сотрудники отдела проектов видели бы в деталях все, что происходит в смежных проектах, могли бы взять какие-то наработки из смежных проектов, в общем, чтобы была прозрачность рабочей информации. Без этого сотрудники в своих проектах часто изобретают то, что уже сделано в параллельно ведущихся или выполненных проектах.

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

Участник проекта по умолчанию неудобен по следующим причинам:
1. Не работает для уже созданных проектов
2. Если мы добавляем участника, то он становится участником переписки, его могут выбрать для оповещения и т.п. А здесь нужно только предоставить доступ к информации о том, что задачи есть и к действиям и файлам по задаче.

Очень хочется в проектах Роль - Контролер проекта. Чтобы по доступу к задачам, как аудитор, но без возможности менять статус, завершать, менять кастомные поля и атрибуты. Может, вообще, только для чтения.
Также желательно, чтобы на эту роль можно было бы группу пользователей назначить

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

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

[Dmitry Goncharenko]

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

[Sergey Kudich]

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

Дмитрий, а можно немного подробнее чем роль наблюдателя может раздувать БД? Для него ведь никакие обработки не должны выполнятся по идее - он просто может видеть все в проекте, а в некоторых случаях вместо наблюдателя ставят Аудитором или исполнителем по умолчанию - разве это не более тяжелое решение?

Я тоже какое-то время назад обращался в ТП с таким запросом, т.к. реально это очень нужная и важная вещь.

Кейс
Проект (сайт) на поддержке. По нему постоянно ведутся работы, по нему постоянно работает целая команда разработчиков. Разработчики могут меняться время от времени. В проект подключены так-же представители клиента (кто-то с доступом в ПФ, кто-то без). Задач в проекте много - тысячи, десятки тысяч.
Разработчик делает задачу и видит кусок кода, который надо поменять, но он связан с другой задачей в ПФ (в коде ссылка на задачу или по git history определили, а может прямо в задаче ему написали комментарий со ссылкой на другую задачу - не суть), вот тут ему нужно посмотреть эту задачу, чтобы понять о чем там речь и зачем так сделали.
Решений на текущий момент вижу 2 и оба плохие
1. Разработчики каждый раз дергают руководителя-аудитора проекта, чтобы тот открыл им доступ к связанной задаче. А часть задач может быть и переоткрыто позже из чего вылезут недостатки пункта 2.
2. Делаем всех разработчиков аудиторами и начинается полный хаос.
- во первых - слишком большие права для них
- во вторых - куча ненужных уведомлений (задач много, а апдейтов по ним еще больше), как результат отвлекаем людей от работы
- в третьих - представители клиента никогда не будут разбираться кто там ответственный, кто делал эту задачу, они будут писать комментарий сразу всем (проверено, переучить не удается), кто доступен

Кейс 2
Ситуация полностью та-же, но теперь с точки зрения самого заказчика. Он и некоторые его менеджеры хотят иметь доступ и видеть все что происходит, видеть задачи, видеть отчет в реальном времени о затраченном времени, о закрытых задачах, приоритетах... - получается даем права аудитора, но это влечет за собой 2 момента
1. Они могут нечаянно или специально удалить какие-то действия, например включающие аналитики затреканного времени
2. Они во всех задачах присутствуют и их можно выбрать для уведомления - это на самом деле не такая большая проблема, но все-же не лучший вариант

У вас разве при разработке ПФ не возникает таких сложностей? Может поделитесь кейсом/инсайдом как у вас ведется разработка, как решаются подобные проблемы или как вы их обходите стороной? )))

[Котелкин Андрей]

+1

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

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

[Dmitry Goncharenko]

Дмитрий, а можно немного подробнее чем роль наблюдателя может раздувать БД?

Для того, чтобы обеспечить быстрый выбор задач, доступных для конкретного человека, нам приходится создавать таблицу, в которой в "плоском" виде хранятся сочетания "Идентификатор пользователя + Идентификатор задачи". Сейчас в этой таблице уже хранятся сочетания для каждого человека, имеющего доступ к каждой задаче в каждой роли. Например, если я являются аудитором проекта, в котором поставил задачу самому себе, то в этой таблице в связке с этой задачей у меня будет 3 записи: как аудитора проекта, постановщика и исполнителя.

Соответственно, добавляя в ПланФикс новую роль мы осознанно идем на то, чтобы для каждого проекта, содержащего роль наблюдателя, в таблицу дополнительно добавлялся набор из N записей "Этот наблюдатель + Каждая задача проекта". При этом основная нагрузка на БД ложится даже не за счет необходимости хранения этих данных, а за счет поддержания их актуальности. Ведь для каждого изменения задачи мы должны будем проверять, не привело ли оно (напрямую или вследствие запущенного этим изменением сценария) к изменению проекта, в котором расположена задача. Если привело, то мы должны:
- найти в таблице доступа все записи, содержащие сочетания "Наблюдатель старого проекта + эта задача" для каждого из наблюдателей
- удалить их
- найти, есть ли в новом проекте наблюдатели
- если есть, добавить в таблицу нужное количество записей, содержащих сочетание "Наблюдатель нового проекта + эта задача" для каждого наблюдателя, чтобы обеспечить им доступ к ней.

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

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

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

Это конечно очень сложный архитектурный момент, вы так спроектировали свою таблицу.
Возможно если бы вы выбрали другой вариант то было бы менее ресурсоемко например такой.
Поскольку количество ролей по задаче строго ограничено и добавление новых ролей происходи не часто то наличие доступа по каждой из роли можно делать в колонках таблицы.
То есть первые два поля идентификатор сотрудника, идентификатор задачи, а дальше Доступ Аудитор, Доступ Участник и т.п. Таким образом одна строка матрицы отвечает на вопрос роля сотрудника/контакта в этой задаче.
Тогда получение информации из такой таблицы, на мой взгляд упрощается.
Я конечно уже давно не программист, и реально базами данных практически не занимался (только системами которые их используют, но что-то из теории БД мне подсказывает чем меньше записей таблицах тем быстрее.

[Dmitry Goncharenko]

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