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.

GitHub issue: #1527: Simplify permissions system
Pull request: #1705: New permissions framework

I've only just started working on this, but I have a pretty good idea what I want. I've ran a lot of forums on Invision Power Board/Invision Community, so I will make something very close to what they are doing.

This feature is not going to land alone. After I get the new perms system merged, I will do a limited threads rewrite to move their views away from React.js and to new permissions system. So, don't expect Misago with new permissions system to release quickly. But expect it to be a big release when it lands.

First change to the permissions system, about the admins:

Django defines two fields on user model: is_staff and is_superuser. First of those fields, is_staff, controls if user can sign in to Django admin. Second one controls if they can do everything in admin. If user is staff, but not a super user, they can only use the admin actions they have permissions to.

Misago also used those permissions for admin status. is_staff let users to sign in to Misago admin, and is_superuser controlled if user could administrate other admins, or just regular users. Super user could change other users admin status and delete admin users. Regular staff user could not.

This was changed: is_staff and is_superuser fields are now used only by the Django admin. For Misago, users have a single dedicated field: is_misago_root. Root users can sign in to Misago's admin panel and administrate all users, other admins and root admins. To make an user a regular admin, root admin can put them in the "Administrators" group. Regular admin can't add or remove users from the "Administrators" group. They also can't change sign in credentials of other administrators. This is only doable by the root admins.

User groups list in Misago Admin:

Those icons on the left are handles for drag and drop. After years of shying away from doing this, I've finally implemented this feature in the admin.

I am expecting to spend few more days working on the admin panel changes for new permissions system. After user groups I will have to add new category permission forms and categories moderators admin.

Sadly, there will be no automatic permission migration happening between 0.39 and 0.40.

Instead, your admin users will be put in the Admins group and other users will be put in the Members group. After migration you will have to review permissions for each group manually to get them in order, and create extra groups for custom ranks if you've created any. Old ranks/roles permissions will still be here in the Admin Panel as a reference to how things were setup before the update.

This sounds terrible, but I was once fucked up badly by a forum update that decided to reveal to all of the world a forum category where we were discussing handling a legal action with a company we were working with, so I'll rather have it that way.

On the flip side, this setup process will be much faster and easier to reason about than what we currently have. I have no admin forms for permission setup yet, but I will be posting a guide shortly after releasing 0.40.

I am predicting very few breaking changes like this in the future. Pretty much it will be this and a new theme system when Misago updates to Bootstrap 5 or 6.

Categories permissions will be done 100% as grids, for example:

Some of things that currently are category permissions will be moved to category options:

• Selecting posts as solutions
• Seeing only threads started by users

This is second oldest thread in the Roadmap category, created on the 30th Jan 2022. In three weeks its going to be two years old. But there's a good chance new permissions system will be merged in the main branch of Misago before this happens.

Just though its nice to point out how those foundational changes are now happening one after the other after years of stagnation :)