Bad behaviour bumping an ancient topic but I couldn’t find a newer one. Feel free to enlighten me.
I’m using the forum for a lot of odd things these days.
I tend to create read only categories for private purposes with only one access user (keeping it simple for everyone that don’t want to create an actual account). At times a user creates an account and will also be allowed write rights. Except I apparently need to have a category_xyz_see and category_xyz_write group to make this happen. Well, that’s just work.
Somehow it seems weird you can only add groups under security but a user which after all just is another object as well cannot be added.
Didn’t try the invite approach (behind SSO even if it’s probably fixed by now).
Except I use these specially created users that can access private categories.
The reasoning for this is people really don’t want to create yet another account “somewhere” these days. So for information that is short-lived, months or max two years, I either use a login that has read-access to the public areas on the site or a specific login which access to a closed category.
This approach seems to bring more readers and some convert to actual users if they find other interesting stuff on the site.
Having a required login keeps the site clean.
Only writing this as a use case scenario of how someone uses his Discourse, nothing more. As a developer I usually get interested when people do things I didn’t envision.
But since this can be solved by adding another group with different rights where you add the needed users it’s no biggie.
If you think about it, the definition of a PM is a topic with individual access control. They appear in different places in the UI, but having both would be super confusing.
I think this is an interesting idea. We have generally been seeking parity to users for groups. This is the first time I think I have seen the reverse.
for very small sites or for categories intended just for a handful of people I could see it as very useful and expedient to be able to put usernames into the category security fields alongside group names. But obviously once you start adding lots of usernames it becomes unwieldy.
I think I disagree with Stephen here, from a programmer’s point of view at least. Whether you have a user or group is irrelevant, both are objects. As I see it, they both map on top of each other and can have overlaps.
Would it be confusing in the UI, maybe. Maybe not. We don’t need to show the overlap and a user also existing in a group is irrelevant (up to the system to figure it out).
I also came across the restriction that a subcategory has to have access on the parent category level. Which makes sense kinda. I guess I could turn the whole thing around but in this particular case it would feel backwards.
I’ll show the actual use case again, much easier to explain the why’s. I might not know all the proper english words here but I think people will get the gist.
A person died and a lot of people are in the estate.
Created a read-only user for easier access (added that user to a “See group”).
Some people already on the site were also added to the group (so they won’t have to logout and switch accounts).
The top category contains common information, burial etc.
One subcategory contains money information (which is still unclear, so not released to everyone until all issues resolved). Adding a trusted man here (which could be outside the estate) doesn’t mean he would need (or even should have) access to the top category.
I’m certain I could come up with a good way to handle it with a bit of thinking. But basically being allowed to add single users into any level would solve it more beautifully (and logically).
And, all this is almost achievable using extra groups so probably not worth the effort.
The concepts of groups and categories are baked into discourse and touch many things, so I am not sure there is going to be appetite for changing this. It would be a massive change.
That said, I agree this has always been an area that makes discourse seem complicated to set up and manage, even when compared with legacy systems like yahoo groups or mailing lists.
We do have some special groups already that get special handling, eg trust levels, everyone, and moderator/admin. Maybe we could also allow creation of special groups used just for category access behind the scenes, directly from the category security settings? Something like:
For category foo:
provide UI for selecting users and giving them access to see, reply and create
when users are selected, create foo_see, foo_reply, foo_create groups and add users to them
provide UI for removing users and changing their access to see, reply and create
if category moderation is enabled, also allow users to be specified as category moderator and create a foo_moderator group for it.
foo access groups are not visible from the /groups page or suggested with @ in the composer
foo access groups are tied to specific foo category and cannot be used for accessing other categories
subcategories of foo can automatically be given access to foo instead of the current circular error handling, which is confusing
What I like about this is we could also expose UI when looking at a category to see the names of everybody with access to the category, and which people have see, reply and create access. I’ve always felt that this has been a gap. Right now the only programmatic info we provide is the indicating a category is secure - we don’t know who has access.
By putting this functionality within the category settings, we are also simplifying how categories and groups are created… this opens the door to letting more users create and manage secure categories. There could even be a foo_owner group for people who are allowed to manage access for the category along with site admins.
I am not sure how this might look and there may also not be appetite for a change like this, but we always welcome brainstorming and new ideas, preferably with mockups!
Interesting. Still feels a bit convoluted though (maybe because built on top of what exists and thus a must).
Groups feels bloated already (always getting lost of who belongs to what - yupp, bad naming, I know). So a foo type approach should maybe mainly be visible from the category. At least a checkbox whether to show those in groups by default.
Too bad Discourse is built with tools I’m totally unfamiliar with. At best I might create utilities that accesses the database directly. Which other people seem to do much better with their scripts anyway. Oh well, maybe when I retire .
indicating a category is secure - we don’t know who has access.
.