Category permissions and the new permission groups

[RGJ (Richard - Communiteq)]

When adding groups to a category, the options anonymous_users and logged_in_users can be selected, but they don’t work.

[nickdb (Nick)]

Does this not require the beta feature “Granular anonymous and logged in groups permissions” to be enabled?

[RGJ (Richard - Communiteq)]

Yes, this is happening with that feature enabled, which is now the default.

[sam (Sam Saffron)]

@martin any ideas about this one?

[martin (Martin Brennan)]

Thanks for the report, will have a look

[RGJ (Richard - Communiteq)]

From your response in the other topic

@martin

so these (this and Category permissions and the new permission groups - #6 ) are more unintended side effects. I don’t intend to remove everyone yet as an option from category permissions…but over time I think it’s probably a good idea to do a fast follow up on this.

The problem is that I was thinking it would be even less clear what I should migrate everyone category permissions to, but maybe it can follow logic like you are suggesting? E.g. if I remove everyone, a migration would add these category permissions for a site:

1. Site requires login → everyone becomes logged_in_users
2. Site is public/doesn’t require login → everyone becomes logged_in_users AND anonymous_users, two separate category permissions

The more I think about this the more I worry about this.

What happens if I only add anonymous_users to a category and don’t add logged_in_users ?
What happens if I add anonymous_users while my forum is login_required ?

Also, the current technical implementation is that when category permissions are set to everyone, there is simply no entry in category_groups and read_restricted is set to false.

That is very simple and straightforward: if there are no permissions set then the permissions are determined by the global forum permissions (the login_required setting) and no further restrictions apply.

So making this change would be adding a huge amount of complexity and weird combinations would be possible (you could do anonymous users and staff )

My suggestion would be:

• remove anonymous_users as an option for category permissions altogether
• keep everyone and logged_in_users
• remove trust_level_0 as an option since it equals logged_in_users

or alternatively, but maybe less clear for less experienced admins

• remove anonymous_users and logged_in_users as an option for category permissions
• keep everyone (and TL0)

In all cases, keep everyone. And you won’t need a migration either

[martin (Martin Brennan)]

Thanks for your thoughts, this is why I didn’t want to go into category permissions too much at first with that everyone change

I think a lot of what you say here could simply be made impossible, I’ve already been working on some preliminary systems here with ACLs and a nicer permission UI on our kanban plugin that we are developing, here is an example, we intend to change the category permissions to use this eventually:

There are several rules involved here, like it’s impossible to give anonymous users Manager permissions for a kanban board and so on, and even supports mandatory permissions, like Admins can always manage a board.

@RGJ

What happens if I add anonymous_users while my forum is login_required ?

We would make it so you can’t add anonymous users when the forum is login required.

@RGJ

What happens if I only add anonymous_users to a category and don’t add logged_in_users ?

Again, another validation/restriction we can add.

@RGJ

So making this change would be adding a huge amount of complexity and weird combinations would be possible (you could do anonymous users and staff )

We could add validations/warnings for this kind of thing too.

@RGJ

Also, the current technical implementation is that when category permissions are set to everyone, there is simply no entry in category_groups and read_restricted is set to false.

This is what I want to avoid, these kind of implicit permissions that are everywhere in Discourse, rather than having logged in users + anonymous users explicitly always setup for a category if it’s public/not read restricted.

---

Anyway, for now I don’t want to get too deep into this, there’s a bit of a way to go before I deal with categories. But I do agree the OP is a bug that needs to be fixed in the interim, so I will still do this.

[RGJ (Richard - Communiteq)]

@martin

We would make it so you can’t add anonymous users when the forum is login required.

With that other issue in mind, I would personally recommend against that kind of logic. What happens when I change a forum to login required when anonymous users are already in the permissions list? And the other way around? This is going to be a nightmare, and it will be non transparent to admins.

@martin

Again, another validation/restriction we can add.

I am very wary of complexity like this.

[martin (Martin Brennan)]

Again, more good points, there is a lot to think through and this stuff is tricky. I will be for sure keeping the admin experience in mind when making changes around categories, there is a lot of history here and I don’t want anyone to be surprised. None of this will be done quickly, it will take a long time to carefully work through the different scenarios when I get to this project.

[Moin]

I wonder why the fact that you can configure stuff for anons while not for logged in users is a problem in the context of category permissions, but not in the context of permissions configured via site/plugin/theme settings. A simple example: it is now possible to make styleguide available to anonymous_users without adding logged_in_users. Does that make more sense than showing a category to anons, but not logged in users?

[martin (Martin Brennan)]

Nope doesn’t make sense, just another edge case to cover really…will add anonymous_users to disallowed_groups for that plugin. Also highly doubt there are many sites in the wild with this plugin enabled, so not too worried about this being misconfigured at the moment.

I think that’s how I would generally handle this with these type of settings. We can also make use of the mandatory_values to make sure certain groups are always selected so you can’t end up with only anonymous_users in some places. Or make use of setting validations to say “you can’t choose anonymous_users without at least one authenticated user group”, and so on.

[Moin]

@martin

Nope doesn’t make sense, just another edge case to cover really…will add anonymous_users to disallowed_groups for that plugin.

I don’t understand why this is needed. What is wrong with it being an option?

@martin

We can also make use of the mandatory_values to make sure certain groups are always selected so you can’t end up with only anonymous_users in some places. Or make use of setting validations to say “you can’t choose anonymous_users without at least one authenticated user group”, and so on.

Does that work only for site settings, or also for theme components?

[martin (Martin Brennan)]

@Moin

@martin

We can also make use of the mandatory_values to make sure certain groups are always selected so you can’t end up with only anonymous_users in some places. Or make use of setting validations to say “you can’t choose anonymous_users without at least one authenticated user group”, and so on.

Does that work only for site settings, or also for theme components?

Doesn’t work yet for theme components, but it could. Again, really getting ahead of ourselves here.