I would like to support this. My use case - I have a group of “limited” users; I want them to be able to read most categories, but write only in one, let’s call it “starting cat.”.
I can of course use existing solution (and trust levels of course), but if I want to have more fine-grained permission system, it gets hectic.
Instead of setting up permissions like this:
display: everyone
post: everyone NOT greenhorns
I have to do something like this:
display: everyone
post: Group 1
Group 2
(...and basically each and every other group...)
reply: Group a
Group b
(...and once again...)
@robmc, looks like Jeff recategorized this already. Unless I’ve misread this, your request is the same as mine (linked above, long before I joined the Discourse team). Do you mind if the topics are combined, or do you feel yours is different?
Well, our use cases are similar, but our current proposed solutions look a little different
I don’t mind combining them at all, but I think that your original proposal was to have a single category for putting members into that would stop them being in ‘everyone’ but I would prefer to have logic in the security that allowed us to use “IS NOT” (or can’t / exclude) in the same way we use “IS” (or Can) as I think this would give more flexibility
They are similar issues, but not quite the same and it is possible that a single technical solution would address both, but I’m not sure. Happy to put them together to explore it though
I’m not precious … just wanting to help make this even better for everyone
So my usecase at the time was a single category that I needed to restrict access to, but the solution is the same as you suggested: an “exclude” or “not” security permission for categories.
Having Add+Subtract moves the system into a whole range of potential conflicts requiring resolution. At the least, the order of putting in permissions will now be significant, and so there will necessitate a reorder function to move things up/down.
Otherwise, there is no way to resolve potential conflicts when a person:
is in more than one group
one group is permitted access
another group is denied access
EDIT: Or you can say Add always trumps Subtract, or vice versa. Nevertheless, it makes things very hard to understand.
Although I can understand the pain you’re going through in order to request this… I have tons and tons of groups and each category’s permissions list is like 15 long, just to do what you’re looking to do – that is, to exclude a particular group from access while opening to most others.
Since all sites are currently like yours, it might be that the solution is to have two steps / sections … the first is the INCLUSION (which is the current context, so even if the change is made nothing is affected) where you build up a total population to view this, then a second step below would be the EXCLUSION which would remove a portion of those that matched certain criteria.
There is also a need for intersection, meaning that the permission is only for users with two or more groups set.
For example, Sales & USA ==> any user having both the group Sales and USA. Then this combo should have access to USA Sales Leads category. In other words, the group is the “intersection” of a number of groups. Currently, the permission system works on the “union” of listed groups.
This will solve neatly the common headaches of setting up permission with sub-categories (where in many cases, the users permitted into the sub-categories will only be among the ones permitted into the parent category). It is necessary because, in Discourse, sub-categories do NOT inherit permissions.
J’aimerais aussi une option d’exclusion, et elle pourrait être relativement simple : permettez-nous simplement d’ajouter un groupe aux paramètres de sécurité d’une catégorie et de décocher la case “Voir”.
Actuellement, si j’ajoute un groupe aux paramètres de sécurité de la catégorie, je peux décocher les cases “Créer” et “Répondre”, mais pas la case “Voir”. Si je pouvais décocher la case “Voir”, la logique pourrait être : “si l’utilisateur appartient à un groupe qui n’a pas les permissions de Voir, alors ne laissez pas l’utilisateur voir la catégorie”.
Cela me fait me demander comment fonctionnent les permissions conflictuelles actuellement : si un utilisateur appartient au groupe A et au groupe B, et que le groupe A peut créer des sujets dans cette catégorie mais que le groupe B ne le peut pas, l’utilisateur peut-il créer un sujet dans cette catégorie ? En d’autres termes, quelle permission a la priorité ?
Je suppose que cela fonctionne actuellement comme suit : “si l’utilisateur appartient à un groupe qui a la permission X, alors accordez cette permission à l’utilisateur”, mais je ne suis pas sûr… je viens de tester et il semble que ce soit le cas.
Les autorisations sont effectivement cumulatives, il n’y a pas de conflit dans ce sens. L’autorisation héritée la plus élevée l’emporte toujours. Je peux être ajouté à un groupe qui me permet de voir une catégorie, et aussi à un autre qui me permet de contribuer.
Pourquoi auriez-vous besoin d’exclure un groupe à moins que vous n’ayez également explicitement accordé l’accès par le biais d’une autre adhésion ?
Je pense que l’exemple le plus simple serait de donner les permissions de voir, répondre et créer à tout le monde, puis d’ajouter le groupe X et de décocher voir, répondre et créer afin que tout le monde puisse voir, répondre et créer dans cette catégorie, à l’exception des membres du groupe X.
Comment cela pourrait s’appliquer à moi actuellement : J’utilise Memberful comme fournisseur SSO sur Discourse et WordPress et je veux vendre trois forfaits, deux des plus chers avec accès au forum et le plus bas sans accès. Cependant, je pense qu’ils pourraient toujours avoir accès en raison de la synchronisation des comptes entre SSO et je veux donc limiter leur accès afin qu’ils ne puissent voir aucune catégorie et peut-être juste m’envoyer des MP. Je pense que je peux le faire en ajoutant les groupes Y et Z à toutes les catégories et pas à tout le monde, et cela fonctionne parce que je n’ai pas beaucoup de groupes, mais je pense que si j’en avais beaucoup, décocher la case Voir serait plus facile.
J’aimerais également pouvoir configurer de petits groupes et les exclure de certaines catégories sur le site, tout en leur permettant de voir d’autres catégories comme les membres à part entière.
Pour utiliser la comparaison Slack ci-dessus, faites des personnes de ce petit groupe des « Invités multi-canaux : ces comptes ne peuvent accéder qu’à des canaux sélectionnés ».
En bref, j’aimerais pouvoir exclure des groupes de catégories individuelles.
Les gars - pouvez-vous vérifier la logique de ceci s’il vous plaît ?
Je pense que j’ai peut-être trouvé un moyen d’y parvenir en me basant sur les fonctionnalités existantes.
Disons que je veux que les sujets étiquetés « secret » ne soient pas visibles par un certain groupe.
N’est-il pas aussi simple que de modifier les paramètres du groupe afin que tous les sujets étiquetés « secret » soient mis en sourdine pour les membres du groupe ?
De même, si je veux qu’une catégorie ne soit pas visible par un certain groupe, n’est-il pas aussi simple que de modifier les paramètres du groupe afin que tous les sujets de cette catégorie soient mis en sourdine pour les membres du groupe ? (et d’installer également le composant de thème Masquer les catégories mises en sourdine) ?
De plus, je ne trouve aucune documentation décrivant le fonctionnement de la fonctionnalité de mise en sourdine de Discourse - quelqu’un peut-il m’aider ?
Quel est le degré de secret de ces sujets ? Lorsque vous mettez quelque chose en sourdine par défaut (pour tout le monde ou pour les membres d’un groupe), les utilisateurs peuvent toujours modifier leurs préférences pour le réactiver. De plus, les sujets mis en sourdine sont masqués dans les listes de sujets, mais pas, par exemple, dans les résultats de recherche.
