I've started sketching out new user and permissions system for v4.

Current system was influenced by experiences from phpBB3 and also my expectation that many things that are features on other forum systems will be achieved here by extreme configurability of permission system.

In hindsight I'll rather have less powerful but easy to reason about system in v4.

Users, Ranks, Roles and Category Roles

Currently user permissions come from roles that are assigned to them directly or to their ranks.

This system is (to my knowledge) unique to Misago, and it's also confusing to reason about. Other forums have concept of users group, which in Misago is muddied by Rank ("primary group") and Role ("secondary group but not really").

In v4 I'll be dropping current system and implementing new one: Users will belong to groups. Each user will always have primary group, and will optionally belong to one or more secondary groups.

Roles will also be dropped, with permissions being specified directly on groups. If you want bunch of users have given permission, you can always create "Have given permission" hidden group and add users to it.

As for category permissions, I will be opting for simple and proven "see category, browse category, start threads, reply threads, upload files, download files" permission matrix known from forums like Invision Power Board.

Moderators

In other forums "moderator" is a special relationship between user or group of users and category or feature. Eg. user or group of users can be explicitly declared as moderators of selected category.

This is not the case in Misago, where moderator is a user that has set of permissions allowing them more power over some features than other users (eg. open/close threads, pin/unpin, edit/delete other people messages). This makes it powerful (eg. you can make moderator who can only close/open threads), but in hindsight unnecessarily complex system.

This system is hard to reason about, makes UI logic complex and also prevent us from implementing features like category's moderators list in simple way.

So in v4 I'll go proven path, where there will be few ways to make somebody a moderator:

• Explicitly set them "global moderator" flag
• Add them to group that has "global moderator" flag
• Add them to group that is added as moderator to selected categories
• Add them as moderator to selected categories

Moderator tools will not check if user has permission to use given moderator tool. Instead they will check if user is moderator through any of those paths. This will make it much easier to reason about.

There will likely be "members" group that every user will always be a member of. And permissions will be defined on groups. So if you want to grant new permission to bunch of users you will create new group thats hidden from group listings, and assign some users to this group.

In this approach group effectively becomes a role.

Can you provide an example scenario that this approach would enable that's not achievable by creating extra hidden group "Can do XYZ" and adding users to it?

User will have one primary group membership and multiple secondary memberships. So yes, group = role.

I've investigated how Invision does it with groups™ and they don't require users to belong to "members" group. I am planning to go same way for v4 just because its simpler to get implemented. ;)

I've also moved priorities around on roadmap for v4, so groups/mods/permission system will come in before basic admin for users/groups/categories. This will let me do those in two steps instead of having to do UI to return to it to add groups/permissions to it.

In spirit of simplifying permission system, I am contemplating making all permissions on/off toggles. In previous versions groups had permissions like "override attachment upload limit", in v4 there would be single attachment upload limit with groups having "can upload attachments over limit: yes/no" permission. Same would go for other features like "can skip anti-flood protection: yes/no" or "can search threads: yes/no", "can see user profiles: yes/no".

This will make permission system very easy to extend for plugins, reason about for admins and implement/maintain.