Всем привет.

Вопрос по #confluence. Имеете ли вы какую-нибудь ролевую модель для разграничения прав доступа сотрудников до различных статей в конфлюенс? По каким показателям вы строили эту модель? Как налажен процесс выдачи новых доступов?

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

Как бы вы решили (или уже решили) эту задачу с ролями?)

Всем привет.

Вопрос по #confluence. Имеете ли вы какую-нибудь ролевую модель для разграничения прав доступа сотрудников до различных статей в конфлюенс? По каким показателям вы строили эту модель? Как налажен процесс выдачи новых доступов?

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

Как бы вы решили (или уже решили) эту задачу с ролями?)

Можете ещё посмотреть в сторону Comala Workflows, если нужно иметь список подписантов.

У Confluence политика доступа нестандартная для закрытых ресурсов: allow all. То есть всем всё разрешено, а закрытие как вынужденная мера. Эта политика безопасности подходит для открытых вики-сайтов.
Вам же явно хочется deny all, когда запрещено всё, если не разрешено явно. Это правильный подход, но, увы, когда база задумана ровно наоборот, трудно будет реализовать.

Поясню почему. Велик риск случайно открыть что-то. А если всё закрыть, наследование будет работать неправильно. Если закрыть корень, открыв дочернее, доступ к дочерним будет работать невесть как.

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

Можно по отделам блоки писать. Например, то, что нужно знать поддержке - в отдельном блоке или даже пространстве. На каждый проект можно свое пространство завести. И несколько ролей, типа support_junior, support_senior. И с другими аналогично. Хотя закрывать много инфо для чтения это кажется немного недружелюбной практикой

Касательно ролей, мы отказались от readonly роли. Вся история изменений хранится, все пользователи авторизованы под AD, так что если кто-то начнет творить фигню, с ним (или его менеджером) можно поговорить лично и откатить проблемные вещи. Но не всем подойдет, вероятно.

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

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

Хороший подход. Тонкий момент здесь -- если вы используете Comala Workflows с жёсткой фиксацией подписания. Тогда при каждом редактировании согласование сбрасывается, и... всем участникам подписания нужно заново утверждать документ.

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