Я думаю, что добавление владельцев групп можно реализовать в основном так же, как сейчас, но с возможностью @group добавлять в качестве владельца.
Основное преимущество заключается в том, что у группы владельцев будет свой собственный владелец, скорее всего, один или два участника.
Чтобы сохранить чистоту структуры, можно ввести проверку на разумность: владение должно быть не глубже одного уровня.
Например: Группа A владеет Группой B и считается участником обеих групп.
Теперь, если мы добавим Группу C, которой владеет Группа B. Группа B является владельцем Группы C. При этом Группа A владеет Группой B. Группа A считается только участником Группы C, но не имеет прав владельца.
Или для более строгих ограничений: группа может владеть только одной группой или быть владеемой только одной группой. То есть, если A владеет B, то A не может быть владеемой другой группой и не может владеть другой группой. Хотя, возможно, возможность владеть более чем одной группой будет работать с оговоркой: группы-владельцы не могут быть владеемы другой группой. Возможно, по крайней мере, без использования настройки сайта, аналогичной уровню вложенности подкатегорий.
Очень благодарен за уточнение, Дэн — ограничение владения группами одним уровнем в глубину действительно имеет смысл с точки зрения поддерживаемости и предотвращения накопления избыточных привилегий.
Мне нравится идея, согласно которой:
Группа A владеет группой B → участники группы A получают права владельца на группу B
Группа B владеет группой C → участники группы B получают права владельца на группу C
Но группа Aне является владельцем группы C — она лишь транзитивно является участником (но не управляющим)
Это помогает избежать бесконечного вложения, сохраняя при этом возможность построения полезных структур делегирования.
Также согласен, что ограничение глубины владения через настройку group_ownership_nesting_level (аналогично вложенности подкатегорий) даёт сайтам гибкость — возможно, по умолчанию установить значение 1, но предоставить возможность включения более глубокого управления при необходимости.
У меня есть несколько уточняющих вопросов:
В вашей модели должна ли владеющая группа отображаться как участник владеемой группы в интерфейсе каталога групп? Или членство определяется исключительно на основе прав доступа?
Если у группы несколько владельцев (некоторые пользователи, некоторые группы), как вы видите решение конфликтов или дублирования в интерфейсе?
Влияет ли владение на права доступа к категориям (например, может ли группа-владелец управлять категорией, связанной с владеемой группой)?
Это откроет множество возможностей для образовательных, корпоративных или проектных форумов — спасибо за развитие этой идеи!
В этом случае группа-владелец должна отображаться как участник, возможно, с меткой «владелец» или аналогичной. На мой взгляд, группе владельцев необходимо наследовать базовое членство в группе для целей прав доступа к категориям, а если группа публична — показывать всех участников. Возможно, это будет похоже на то, как модераторы категорий могут быть перечислены на странице «О сайте» в качестве модераторов. Возможно, это так же просто, как указать группу владельцев как «Владелец» или «Управляемая группой». Тогда любой участник сможет просто кликнуть на группу владельцев, чтобы увидеть владельцев указанной группы?
На мой взгляд, если вы используете группу в качестве владельцев, то это либо участники-владельцы внутри группы, либо группа-управляющая. Не смесь обоих вариантов.
Вы имеете в виду, как модераторы категорий? Если да, то было внесено изменение, позволяющее более чем одной группе управлять категорией. Однако, если использовать пример из предыдущего вопроса, можно просто сделать так, чтобы группа владельцев наследовала права управляемой группы. То есть права доступа к категории и в данном случае также права модераторов категории. В разделе модераторов категории это обеспечит дополнительные уровни управления, как в других примерах. Основной набор владельцев, которые при необходимости могут отстранять владельцев нижнего уровня без вмешательства всего персонала. Например, два владельца в конфликте. Главный владелец группы менеджеров может понизить в должности при необходимости.
Это отличное упражнение для проработки идеи. Поэтому обсуждение очень полезно для детальной проработки концепции.
Heliosurge о видимости владельца и правах доступа к категориям
Это имеет смысл — мне нравится идея отображения группы владельца в каталоге групп с меткой «Владелец» или «Управление группой», аналогично тому, как отображаются модераторы категорий.
Я считаю, что различие между:
Полноправными участниками (которые получают бейджи, упоминания, значки группы)
И владельцами через другую группу (которые наследуют права, но не идентичность)
…было бы полезно четко отразить в интерфейсе.
Пример макета
Группа @mentors
Участники: Алиса, Боб, Чарли
Группа владельца: @mentor-coordinators
При нажатии на группу владельца вы переходите к списку её участников.
И я согласен — для целей прав доступа к категориям элегантно рассматривать группы владельцев как «участников» владеемых ими групп (чтобы избежать необходимости вручную дублировать права доступа).
Уточняющие вопросы
Видите ли вы наследование членства в группе-владельце только для проверок прав доступа или также отображение в таких вещах, как упоминания групп и значки, если владеемая группа публична?
Возможно ли, чтобы одна группа владела несколькими другими группами, или должно существовать правило 1:1 как ограничение безопасности?
Heliosurge об эксклюзивной модели владения
А, понял — это полезное упрощение.
Итак, вы предлагаете, чтобы владение было эксклюзивным:
Либо группа принадлежит отдельным пользователям
Либо она принадлежит группе (которая содержит людей, обладающих правами владельца)
Но вы не разрешаете оба варианта одновременно
Это определенно делает модель чистой и избегает конфликтов в интерфейсе.
Гибридное решение
Если кто-то захочет гибридный вариант, он всегда может создать группу владения (например, @mentors-owners), включить в неё как отдельных владельцев, так и представителей подгрупп, и назначить её единственной группой владельца. Это сохраняет порядок без прямого смешивания моделей владения.
Вопросы реализации
Должна ли эта эксклюзивность обеспечиваться на уровне базы данных (например, у группы есть либо group_owner_id, либо список user_owners, но не оба сразу)?
Или это скорее конвенция на уровне интерфейса с предупреждением?
Должна ли группе разрешаться владение более чем одной группой (при условии отсутствия вложенности)?
Heliosurge о наследовании прав модератора категории и иерархии владельцев
Это полезное направление, спасибо!
О наследовании прав доступа к категориям
Да — я представлял ситуацию, когда:
Группа B имеет доступ к публикации/ответу/созданию в категории (например, #mentorship)
Группа A владеет группой B
Таким образом, Группа A наследует доступ к #mentorship — без необходимости явных прав доступа на уровне категории
Это упростило бы управление доступом, если структура владения уже выражает границу доверия.
О модерации категорий
Хорошо знать, что Discourse теперь позволяет нескольким группам модерировать категорию.
Предполагаете ли вы, что группа-владелец группы B также автоматически получает статус модератора категории для категорий, которые модерит группа B?
Это могло бы помочь реализовать модель многоуровневого контроля, где группы-владельцы могут выступать в роли «главных модераторов» или «хранителей групп», способных:
Модерировать в том же пространстве
Понижать в должности проблемных владельцев групп или суб-менеджеров
Уточняющие вопросы
Будут ли наследуемые права применяться только к доступу/модерации категорий? Или они также могут распространяться на другие функции, связанные с группами (например, сообщения, события)?
В вашей многоуровневой модели должна ли «верхняя» группа всегда быть плоской — или она сама может иметь владельцев?
Это кажется шагом к созданию действительно гибкой модели делегирования — полезной для школ, организаций и структурированных онлайн-сообществ.