kmeisthax / Forum9000

Symfony-based forum software
1 stars 0 forks source link

Seniority #3

Open kmeisthax opened 6 years ago

kmeisthax commented 6 years ago

Right now, there are two permissions involved with changing permissions and grants. Users with "grant" are allowed to add new grants to the privilege list; while users with "revoke" are allowed to add denials to the privilege list. The only limitation is that you cannot grant or revoke privileges you don't have: if you can't lock a thread, you shouldn't be able to let others lock threads, because you could then trivially obtain all permissions.

There's a problem with the revoke permission, however: anyone who has it can depose all the moderators on the forum. That's why it's separate from grants - so you could allow moderators to, say, designate approved posters on a locked forum; without allowing them to completely take over the forum. In order to fix this, we need privilege grants to have some kind of hierarchy. We choose to use the grant date to establish this hierarchy.

With seniority, users can only revoke privileges that they have and were granted after theirs. This means that moderators cannot depose other moderators instituted before they were, which reduces the damage a rogue moderator takeover can do. There's a bit of a wrinkle about this, though - grant times would be for each specific Grant, not the user's modship as a whole. This would pose some confusion for moderators trying to understand who can depose who.

For example: Let's say a user was given the ability to select approved posters (post/grant) on April 20th. After a month, on May 15th, the user was given full moderator privileges (lock/ban/revoke). You'd think they can't demod people with seniority before May 15th, but their grant privilege has seniority of April 20th, meaning that they can revoke other mods' grant privileges only.

Issue #2 also produces some weird consequences: users added to a moderator group would inherit the group's seniority, and thus could lock the entire group out of the forum. If groups are implemented before seniority, then we have an alternate solution: membership seniority. Kicking a user out of a group would require having been added to the group before their removal. This gives us the advantage of having a single seniority value for a given set of permissions. Instead of giving grant/revoke on the forum to moderators, you'd instead give invite/evict on the moderator group to itself. Grant/revoke would then only need to be given to the owner of the forum so they could determine which groups get what permissions.

Finally, if seniority is implemented, we would probably want to get rid of the grant/revoke split altogether, since it doesn't really make sense. I mean, if you grant people privileges and they abuse them, you should be able to revoke those privileges.