• Jan. 30, 2022, 4:18 a.m.

    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.

  • Members 11 posts
    June 25, 2022, 11:14 a.m.

    This is just a question regarding the permission system. Where exactly are you assigning roles, and how are you creating default roles like member that have a special role? Thank you

  • June 25, 2022, 1:23 p.m.

    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.

  • Members 6 posts
    June 27, 2022, 1:25 a.m.

    This is probably not what you want.....but would it be possible to have something like:

    Group - to which can be assigned users, threads, categories

    Role - which defines permissions within the group

    This would allow separate access to different groups, and different status for individual members within different groups.

    It may not be appropriate to do that, or it may be possible within what you are doing, or it may be possible with what you are proposing...but I can't see it.

  • June 27, 2022, 1:29 a.m.

    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?

  • Members 6 posts
    June 27, 2022, 1:42 p.m.

    Thinking about it, I don't think that I can.

    As long as groups can define access (threads, categories), and can define permissions within that group.....then you can just keep adding groups that define the fine grained access and permissions required. Assuming that a user can have membership of multiple groups.

    So really the role is defined by the group, where different groups might have the same access (defined categories/threads), but different permissions (moderate, contribute, readonly, etc)?

  • June 27, 2022, 10:51 p.m.

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

  • Members 6 posts
    June 28, 2022, 3:52 p.m.

    Then I stand corrected. I don't think there is anything that can't be done that way...it's just contrary to some of my general experience with a combination of groups and roles.

  • July 3, 2022, 2:32 a.m.

    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.

  • July 11, 2022, 11:49 a.m.

    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.