Lors de l’ajout de groupes à une catégorie, les options anonymous_users et logged_in_users peuvent être sélectionnées, mais elles ne fonctionnent pas.
2 « J'aime »
Cela ne nécessite-t-il pas que la fonctionnalité bêta « Autorisations granulaires pour les groupes anonymes et connectés » soit activée ?
1 « J'aime »
Oui, cela se produit lorsque cette fonctionnalité est activée, ce qui est désormais le paramètre par défaut.
3 « J'aime »
@martin une idée pour celui-ci ?
1 « J'aime »
Merci pour le signalement, je vais jeter un œil 
D’après ta réponse dans l’autre sujet
Plus j’y réfléchis, plus cela me préoccupe.
Que se passe-t-il si j’ajoute uniquement anonymous_users à une catégorie sans ajouter logged_in_users ?
Que se passe-t-il si j’ajoute anonymous_users alors que mon forum est en mode login_required (connexion requise) ?
De plus, l’implémentation technique actuelle est que lorsque les autorisations de catégorie sont réglées sur everyone, il n’y a simplement aucune entrée dans category_groups et read_restricted est réglé sur false.
C’est très simple et direct : s’il n’y a pas d’autorisations définies, celles-ci sont déterminées par les autorisations globales du forum (le paramètre login_required) et aucune restriction supplémentaire ne s’applique.
Ainsi, effectuer ce changement ajouterait une énorme quantité de complexité et permettrait des combinaisons étranges (on pourrait avoir anonymous users et staff 
)
Ma suggestion serait :
- supprimer
anonymous_usersen tant qu’option pour les autorisations de catégorie tout court - conserver
everyoneetlogged_in_users - supprimer
trust_level_0en tant qu’option puisqu’il équivaut àlogged_in_users
ou alternativement, mais peut-être moins clair pour les administrateurs moins expérimentés :
- supprimer
anonymous_usersetlogged_in_usersen tant qu’option pour les autorisations de catégorie - conserver
everyone(et TL0)
Dans tous les cas, conserve everyone. Et tu n’auras pas besoin de migration non plus 
4 « J'aime »
Merci pour vos réflexions, c’est pourquoi je ne voulais pas trop m’attarder sur les permissions de catégorie au début avec ce changement pour « tout le monde » 
Je pense que beaucoup de ce que vous dites ici pourrait simplement être rendu impossible. J’ai déjà travaillé sur certains systèmes préliminaires ici avec des ACL et une interface de permissions plus intuitive pour notre plugin kanban que nous développons. Voici un exemple : nous avons l’intention de modifier les permissions de catégorie pour utiliser cela à terme :
Plusieurs règles sont impliquées ici, comme le fait qu’il est impossible d’attribuer des permissions de gestionnaire à des utilisateurs anonymes pour un tableau kanban, et ainsi de suite. Cela prend même en charge les permissions obligatoires, comme le fait que les administrateurs peuvent toujours gérer un tableau.
Nous veillerions à ce que vous ne puissiez pas ajouter d’utilisateurs anonymes lorsque le forum nécessite une connexion.
Encore une fois, une autre validation/restriction que nous pouvons ajouter.
Nous pourrions également ajouter des validations/avertissements pour ce genre de choses.
C’est ce que je veux éviter : ce genre de permissions implicites qui sont partout dans Discourse, plutôt que d’avoir les utilisateurs connectés + les utilisateurs anonymes explicitement configurés pour une catégorie si elle est publique/non restreinte en lecture.
En tout cas, pour l’instant, je ne veux pas trop m’approfondir dans ce sujet. Il reste un peu de chemin à parcourir avant que je ne m’occupe des catégories. Mais je suis d’accord pour dire que le message initial signale un bug qui doit être corrigé entre-temps, donc je vais quand même faire cela.
1 « J'aime »
En tenant compte de cette autre question, je recommanderais personnellement de ne pas mettre en place ce type de logique. Que se passe-t-il si je passe un forum en « connexion obligatoire » alors que des utilisateurs anonymes figurent déjà dans la liste des permissions ? Et dans l’autre sens ? Cela va devenir un cauchemar, et ce ne sera pas transparent pour les administrateurs.
Je suis très méfiant face à ce genre de complexité.
2 « J'aime »
Encore une fois, d’excellents points. Il y a beaucoup de choses à prendre en compte et ce sujet est délicat. Je garderai certainement l’expérience des administrateurs à l’esprit lors des modifications concernant les catégories, car il y a beaucoup d’historique ici et je ne veux surprendre personne. Rien de tout cela ne sera fait rapidement ; cela prendra beaucoup de temps pour examiner attentivement les différents scénarios lorsque j’aborderai ce projet.
1 « J'aime »
Je me demande pourquoi le fait que vous puissiez configurer des éléments pour les utilisateurs anonymes, mais pas pour les utilisateurs connectés, pose problème dans le contexte des autorisations de catégorie, mais pas dans celui des autorisations configurées via les paramètres du site/du plugin/du thème. Un exemple simple : il est désormais possible de rendre le guide de style disponible pour les utilisateurs anonymes sans ajouter les utilisateurs connectés. Cela a-t-il plus de sens que d’afficher une catégorie aux utilisateurs anonymes, mais pas aux utilisateurs connectés ?
1 « J'aime »
Non, ça n’a pas de sens, c’est juste un autre cas limite à gérer… j’ajouterai anonymous_users à disallowed_groups pour ce plugin. Je doute aussi fortement qu’il y ait beaucoup de sites en production avec ce plugin activé, donc je ne suis pas trop inquiet pour l’instant quant à une mauvaise configuration.
Je pense que c’est ainsi que je gérerai généralement ce genre de paramètres. Nous pouvons également utiliser mandatory_values pour nous assurer que certains groupes sont toujours sélectionnés, afin d’éviter de ne se retrouver qu’avec anonymous_users dans certains endroits. Ou utiliser des validations de paramètres pour indiquer « vous ne pouvez pas choisir anonymous_users sans au moins un groupe d’utilisateurs authentifiés », et ainsi de suite.
Je ne comprends pas pourquoi c’est nécessaire. Quel est le problème à ce que ce soit une option ?
Cela fonctionne-t-il uniquement pour les paramètres du site, ou aussi pour les composants de thème ?
Cela ne fonctionne pas encore pour les composants de thème, mais ce serait possible. Encore une fois, nous nous avançons vraiment trop vite ici.