Je pense que l’ajout de propriétaires de groupe pourrait se faire en grande partie comme maintenant, à l’exception de l’ajout de la possibilité de @groupe ajouter comme propriétaire.
Le principal avantage est que le groupe des propriétaires aura son propre propriétaire, très probablement un ou deux membres.
Pour garder les choses claires, une vérification de la raison pourrait être qu’un seul niveau de profondeur pour la propriété
C’est-à-dire que le Groupe A possède le groupe B et est considéré comme membre des deux groupes
Maintenant, si nous ajoutons le groupe C et qu’il est possédé par le Groupe B. Le Groupe B est propriétaire du Groupe C. Alors que le Groupe A possède le Groupe B. Le Groupe A n’est considéré que comme membre du Groupe C mais n’a aucun privilège de propriété.
J’apprécie vraiment la clarification, Dan — limiter la propriété de groupe à groupe à un seul niveau de profondeur a beaucoup de sens pour la maintenabilité et pour éviter l’escalade des privilèges.
J’aime l’idée que :
Groupe A possède Groupe B → les membres de A obtiennent les droits de propriétaire sur B
Groupe B possède Groupe C → les membres de B obtiennent les droits de propriétaire sur C
Mais Groupe A n’est pas propriétaire de C — seulement transitivement un membre (pas un gestionnaire)
Cela permet d’éviter les imbrications infinies tout en prenant en charge des structures de délégation utiles.
Je suis également d’accord pour dire que limiter la profondeur de propriété via un paramètre group_ownership_nesting_level (comme l’imbrication de sous-catégories) offre de la flexibilité aux sites — peut-être par défaut à 1, mais permettre une option pour un contrôle plus approfondi si nécessaire.
Quelques questions de clarification que j’avais :
Dans votre modèle, le groupe propriétaire devrait-il apparaître comme un membre du groupe possédé dans l’interface de répertoire de groupes ? Ou l’appartenance est-elle purement basée sur les permissions ?
Si un groupe a plusieurs propriétaires (certains utilisateurs, certains groupes), comment voyez-vous la résolution des conflits ou des redondances dans l’interface ?
La propriété affecterait-elle les permissions de catégorie (par exemple, le groupe propriétaire pourrait-il gérer la catégorie liée au groupe possédé) ?
Cela ouvrirait beaucoup de flexibilité dans les forums basés sur l’éducation, l’organisation ou les projets — merci de faire avancer l’idée !
Pour cela, le groupe propriétaire de groupe devrait être vu comme des membres avec peut-être le label de propriétaire ou quelque chose comme ça… Le groupe des propriétaires, à mon humble avis, a besoin d’hériter de l’appartenance de base du groupe à des fins de permissions de catégorie et, s’il est public, de montrer tous les membres. Peut-être un peu comme la façon dont les modérateurs de catégorie peuvent être listés sur la page “À propos” du site en tant que modérateurs. Ce serait peut-être aussi simple que de lister le groupe propriétaire comme propriétaire/géré par. Ensuite, un membre pourrait simplement cliquer sur le groupe propriétaire pour voir les propriétaires dudit groupe ?
À mon humble avis, si vous utilisez un groupe comme propriétaires. Alors peut-être que ce sont soit des propriétaires membres au sein du groupe, soit gérés par un groupe. Pas un mélange des deux.
Voulez-vous dire comme les modérateurs de catégorie ? Si oui, un changement a été apporté pour permettre à plus d’un groupe de gérer une catégorie. Bien que si l’on utilise l’exemple de la question précédente. On pourrait simplement faire en sorte que le groupe des propriétaires hérite des permissions du groupe géré. Donc les permissions de catégorie et dans ce cas seraient aussi les modérateurs de catégorie. Dans les modérateurs de catégorie, cela donnerait plus de niveaux de gestion comme avec d’autres exemples. Un ensemble principal de propriétaires qui peuvent supprimer les propriétaires de niveau inférieur si nécessaire sans nécessiter l’intervention du personnel complet. Par exemple, 2 propriétaires en conflit. Le propriétaire principal du groupe de gestionnaires peut le rétrograder si nécessaire.
C’est un excellent exercice de réflexion pour affiner l’idée. Donc, beaucoup de discussions sont excellentes pour analyser l’idée.
Heliosurge sur la visibilité de la propriété et les autorisations de catégorie
Cela a du sens — j’aime l’idée que le groupe propriétaire apparaisse dans l’annuaire de groupes avec un label « Propriétaire » ou « Géré par », similaire à la façon dont les modérateurs de catégorie sont affichés.
Je pense que la distinction entre :
Membres à part entière (qui reçoivent des badges, des mentions, un flair de groupe)
Et propriétaires via un autre groupe (qui héritent des autorisations, mais pas de l’identité)
…serait utile à garder claire dans l’interface utilisateur.
Exemple de mise en page
Groupe @mentors
Membres : Alice, Bob, Charlie
Groupe propriétaire : @mentor-coordinators
Où cliquer sur le groupe propriétaire vous amène à sa liste de membres.
Et je suis d’accord — pour les besoins des autorisations de catégorie, il est élégant de traiter les groupes propriétaires comme des « membres » des groupes qu’ils possèdent (pour éviter d’avoir à dupliquer les autorisations manuellement).
Questions de suivi
L’appartenance au groupe propriétaire hériterait-elle uniquement pour les vérifications d’autorisations, ou apparaîtrait-elle également dans des éléments tels que les mentions de groupe et le flair, si le groupe possédé est public ?
Serait-il possible pour un groupe de posséder plusieurs autres groupes, ou devrait-il y avoir une règle de propriété 1:1 comme contrainte de sécurité ?
Heliosurge sur le modèle de propriété exclusive
Ah, compris — c’est une simplification utile.
Vous suggérez donc que la propriété doit être exclusive :
Soit un groupe est possédé par des utilisateurs individuels
Soit il est possédé par un groupe (qui contient les personnes ayant la propriété)
Mais vous n’autorisez pas les deux en même temps
Cela permet de garder le modèle propre et d’éviter les conflits d’interface utilisateur.
Solution de contournement hybride
Si quelqu’un voulait un hybride, il pourrait toujours créer un groupe de propriété (par exemple, @mentors-owners), inclure à la fois des propriétaires individuels et des représentants de sous-groupes, et attribuer celui-ci comme unique groupe propriétaire. Cela permet de garder les choses ordonnées sans mélanger directement les modèles de propriété.
Questions d'implémentation
Cette exclusivité doit-elle être appliquée au niveau de la base de données (par exemple, un groupe a soit un group_owner_idsoit une liste de user_owners, mais pas les deux) ?
Ou plutôt une convention au niveau de l’interface utilisateur avec un avertissement ?
Un groupe doit-il être autorisé à être possédé par plusieurs groupes (en supposant aucune imbrication) ?
Heliosurge sur l'héritage des modérateurs de catégorie et la hiérarchie des propriétaires
C’est une orientation utile, merci !
Sur l'héritage des autorisations de catégorie
Oui — je pensais à une situation où :
Le groupe B a un accès de publication/réponse/création à une catégorie (par exemple, #mentorship)
Le groupe A possède le groupe B
Donc le groupe A hérite également de l’accès à #mentorship — sans avoir besoin d’autorisations explicites au niveau de la catégorie
Cela simplifierait la gestion des accès si la structure de propriété exprime déjà la limite de confiance.
Sur la modération de catégorie
Bon à savoir que Discourse permet désormais à plusieurs groupes de modérer une catégorie.
Imagineriez-vous que le groupe propriétaire du groupe B obtienne également automatiquement le statut de modérateur de catégorie pour les catégories que le groupe B modère ?
Cela pourrait aider à mettre en œuvre un modèle de contrôle hiérarchisé — où les groupes propriétaires peuvent agir comme des « modérateurs principaux » ou des « gestionnaires de groupe », capables de :
Modérer dans le même espace
Rétrograder les propriétaires de groupe ou les sous-gérants problématiques
Questions de suivi
Les autorisations héritées s’appliqueraient-elles uniquement à l’accès/modération de catégorie ? Ou pourraient-elles également se propager à d’autres fonctionnalités liées aux groupes (par exemple, messagerie, événements) ?
Dans votre modèle hiérarchisé, le groupe « supérieur » doit-il toujours être plat — ou pourrait-il lui-même avoir des propriétaires ?
Cela semble construire un modèle de délégation très flexible — utile pour les écoles, les organisations et les communautés en ligne structurées.