Mauvaise conduite en déterrant un ancien sujet, mais je n’ai pas pu en trouver un plus récent. N’hésitez pas à m’éclairer.
J’utilise le forum pour beaucoup de choses étranges ces jours-ci.
J’ai tendance à créer des catégories en lecture seule à des fins privées avec un seul utilisateur ayant accès (pour simplifier les choses pour tous ceux qui ne veulent pas créer de compte). Parfois, un utilisateur crée un compte et se voit également accorder des droits d’écriture. Sauf que j’ai apparemment besoin d’un groupe category_xyz_see et category_xyz_write pour que cela se produise. Eh bien, c’est juste du travail.
Il semble étrange que l’on ne puisse ajouter des groupes qu’à la rubrique sécurité, mais qu’un utilisateur, qui est après tout un autre objet, ne puisse pas être ajouté.
Je n’ai pas essayé l’approche par invitation (derrière le SSO, même si c’est probablement résolu maintenant).
Sauf que j’utilise ces utilisateurs spécialement créés qui peuvent accéder à des catégories privées.
La raison est que les gens ne veulent vraiment pas créer un autre compte « quelque part » de nos jours. Donc, pour les informations éphémères, quelques mois ou au maximum deux ans, j’utilise soit un identifiant qui a un accès en lecture aux zones publiques du site, soit un identifiant spécifique qui a accès à une catégorie fermée.
Cette approche semble attirer plus de lecteurs et certains se convertissent en utilisateurs réels s’ils trouvent d’autres contenus intéressants sur le site.
Avoir une connexion obligatoire maintient le site propre.
Je n’écris ceci que comme un scénario d’utilisation de la façon dont quelqu’un utilise son Discourse, rien de plus. En tant que développeur, je m’intéresse généralement lorsque les gens font des choses que je n’avais pas envisagées.
Mais comme cela peut être résolu en ajoutant un autre groupe avec des droits différents où vous ajoutez les utilisateurs nécessaires, ce n’est pas grave.
Si l’on y réfléchit, la définition d’un PM est un sujet avec un contrôle d’accès individuel. Ils apparaissent à différents endroits de l’interface utilisateur, mais avoir les deux serait très déroutant.
Je pense que c’est une idée intéressante. Nous avons généralement cherché la parité pour les utilisateurs au sein des groupes. C’est la première fois, je crois, que je vois l’inverse.
Pour de très petits sites ou pour des catégories destinées à une poignée de personnes, je pourrais trouver très utile et expédient de pouvoir placer des noms d’utilisateur dans les champs de sécurité de catégorie aux côtés des noms de groupe. Mais évidemment, dès que vous commencez à ajouter beaucoup de noms d’utilisateur, cela devient ingérable.
Je pense que je ne suis pas d’accord avec Stephen ici, du moins d’un point de vue de programmeur. Que vous ayez un utilisateur ou un groupe est sans importance, ce sont tous deux des objets. Comme je le vois, ils se superposent et peuvent avoir des chevauchements.
Serait-ce déroutant dans l’interface utilisateur, peut-être. Peut-être pas. Nous n’avons pas besoin de montrer le chevauchement et qu’un utilisateur existe également dans un groupe est sans importance (c’est au système de le comprendre).
J’ai également rencontré la restriction selon laquelle une sous-catégorie doit avoir accès au niveau de la catégorie parente. Ce qui a du sens, en quelque sorte. Je suppose que je pourrais tout retourner, mais dans ce cas particulier, cela semblerait illogique.
Je vais montrer le cas d’utilisation réel à nouveau, c’est beaucoup plus facile d’expliquer le pourquoi. Je ne connais peut-être pas tous les mots anglais appropriés, mais je pense que les gens comprendront l’essentiel.
Une personne est décédée et beaucoup de personnes font partie de la succession.
Création d’un utilisateur en lecture seule pour un accès plus facile (ajout de cet utilisateur à un groupe « Voir »).
Certaines personnes déjà sur le site ont également été ajoutées au groupe (afin qu’elles n’aient pas à se déconnecter et à changer de compte).
La catégorie supérieure contient des informations communes, les funérailles, etc.
Une sous-catégorie contient des informations financières (qui ne sont toujours pas claires, donc non diffusées à tout le monde tant que tous les problèmes ne sont pas résolus). Ajouter un homme de confiance ici (qui pourrait être extérieur à la succession) ne signifie pas qu’il aurait besoin (ou même devrait avoir) accès à la catégorie supérieure.
Je suis certain que je pourrais trouver une bonne façon de gérer cela avec un peu de réflexion. Mais fondamentalement, être autorisé à ajouter des utilisateurs individuels à n’importe quel niveau résoudrait le problème de manière plus élégante (et logique).
De plus, tout cela est presque réalisable en utilisant des groupes supplémentaires, donc cela ne vaut probablement pas la peine.
Les concepts de groupes et de catégories sont intégrés à Discourse et touchent de nombreux aspects, je ne suis donc pas sûr qu’il y ait une volonté de changer cela. Ce serait un changement énorme.
Cela dit, je suis d’accord pour dire que cela a toujours été un domaine qui rend Discourse compliqué à configurer et à gérer, même par rapport à des systèmes plus anciens comme Yahoo Groups ou les listes de diffusion.
Nous avons déjà des groupes spéciaux qui bénéficient d’un traitement spécial, par exemple les trust levels, everyone, et moderator/admin. Pourrions-nous également autoriser la création de groupes spéciaux utilisés uniquement pour l’accès aux catégories en coulisses, directement à partir des paramètres de sécurité de la catégorie ? Quelque chose comme :
Pour la catégorie foo :
Fournir une interface utilisateur pour sélectionner les utilisateurs et leur donner accès pour voir, répondre et créer
Lorsque les utilisateurs sont sélectionnés, créer les groupes foo_see, foo_reply, foo_create et y ajouter les utilisateurs
Fournir une interface utilisateur pour supprimer les utilisateurs et modifier leur accès pour voir, répondre et créer
Si la modération de la catégorie est activée, permettre également de spécifier des utilisateurs comme modérateurs de catégorie et créer un groupe foo_moderator pour cela.
Les groupes d’accès foo ne sont pas visibles depuis la page /groups ni suggérés avec @ dans le compositeur
Les groupes d’accès foo sont liés à une catégorie foo spécifique et ne peuvent pas être utilisés pour accéder à d’autres catégories
Les sous-catégories de foo peuvent automatiquement recevoir l’accès à foo au lieu de la gestion d’erreurs circulaire actuelle, qui est déroutante.
Ce que j’aime dans cette approche, c’est que nous pourrions également exposer une interface utilisateur lors de la visualisation d’une catégorie pour voir les noms de toutes les personnes ayant accès à la catégorie, et quelles personnes ont un accès pour voir, répondre et créer. J’ai toujours pensé que c’était une lacune. Actuellement, la seule information programmatique que nous fournissons est le indiquant qu’une catégorie est sécurisée - nous ne savons pas qui y a accès.
En plaçant cette fonctionnalité dans les paramètres de la catégorie, nous simplifions également la création de catégories et de groupes. Cela ouvre la porte à permettre à plus d’utilisateurs de créer et de gérer des catégories sécurisées. Il pourrait même y avoir un groupe foo_owner pour les personnes autorisées à gérer l’accès à la catégorie, aux côtés des administrateurs du site.
Je ne suis pas sûr de ce à quoi cela pourrait ressembler et il se peut qu’il n’y ait pas non plus de volonté pour un tel changement, mais nous sommes toujours ouverts au brainstorming et aux nouvelles idées, de préférence avec des maquettes !
Intéressant. Ça semble toujours un peu compliqué cependant (peut-être parce que construit sur ce qui existe et donc une nécessité).
Les groupes semblent déjà surchargés (on se perd toujours à savoir qui appartient à quoi - oui, mauvaise dénomination, je sais). Donc une approche de type “foo” devrait peut-être être principalement visible depuis la catégorie. Au moins une case à cocher pour savoir s’il faut afficher ceux-ci dans les groupes par défaut.
Dommage que Discourse soit construit avec des outils que je ne connais pas du tout. Au mieux, je pourrais créer des utilitaires qui accèdent directement à la base de données. Ce que d’autres personnes semblent faire beaucoup mieux avec leurs scripts de toute façon. Oh well, peut-être quand je prendrai ma retraite :).
indiquant qu’une catégorie est sécurisée - nous ne savons pas qui y a accès.