Add PagePermissions extension

[yaronkoren]

We have talked before about adding the UserProtect extension to Canasta:

https://www.mediawiki.org/wiki/Extension:UserProtect

It's useful, but I think its user interface is unnecessarily complicated, and its DB structure seems needlessly complex as well (and to a lesser extent, its name is confusing). Thankfully, @sanjay-thiyagarajan created the PagePermissions extension, whose code is copied in part from UserProtect, but which has a simpler UI:

https://www.mediawiki.org/wiki/Extension:PagePermissions

We're still waiting for the translation process to start on this extension, but I think this is a very workable extension already, and I think it would be great to add it Canasta.

[tosfos]

With a disclaimer that I designed UserProtect, I don't think this is less confusing. It introduces a completely new concept of "roles", which adds more complication to a wiki. Why not just use the User Groups? From what I can tell, roles and groups are essentially the same. Instead of creating the concept of a role, you could assign a user to an existing user group for only one page. That doesn't make much sense for bureaucrat-type permissions since they aren't tied to a page, but I still like it better.

There's also a major bug here: commas can be part of MediaWiki usernames by default: https://www.mediawiki.org/wiki/Manual:$wgInvalidUsernameCharacters. This may be more common than you think. Wikis can use "Lastname, Firstname" for their username schemes, especially for enterprise. UserProtect already offers autocomplete with tokens for user names so there's no need for any delimiter. Why drop that feature? It introduces this delimiter problem and is also less user-friendly.

I also don't see any problem with UserProtect in the first place, but I guess that's a matter of taste.

[yaronkoren]

That's true, "tokenized autocompletion" would be a better solution - easier to use, and would avoid problems with specific characters.

I don't know how this would work with actual user groups. The defaullt roles in PagePermissions are "reader", "editor", "manager" and "owner" - what user groups do any of those correspond to? Besides the lack of direct correspondence, I think it would just cause needless confusion, since the two things are not the same: "roles" are per page, while user groups of course are across an entire wiki.

We can talk more about the UI differences, but the first step is getting the autocompletion stuff set up - I'll let you know if/when that's done.

[yaronkoren]

Okay, PagePermissions now uses a tokens-style input for entering usernames, using similar JS code to that of UserProtect. Which fixes the problem with comma delimiters, as well as just being easier for users.

I think PagePermissions is now ready to be added to Canasta - so this would be a good time to talk about why I think its UI is preferable to that of UserProtect. To demonstrate, let me give one example scenario: there is a user who is a sysop/admin, but for a specific page, you only want them to be able to read and write that page, with no other rights. With UserProtect, here is what you would have to do:

• Add their username to "Remove rights > Move"
• Add their username to "Remove rights > Delete"
• Add their username to "Remove rights > Roll back edits"
• Add their username to "Remove rights > User protect"

With PagePermissions, on the other hand, there's just one step:

• Add their username to "Editor"

In general, I think a role-based approach is a lot easier to use than a rights-based approach - admins don't have to know about users' current rights, they don't really have to think about each individual right, and there's less typing involved.

Conversely, of course, a more explicit system like UserProtect allows for much more flexibility in setting permissions, but I think that extra flexibility is generally not needed, because most combinations would never be used.

[tosfos]

OK. I can see a use case where role-based input is easier. I still think you should use user groups for it. To answer your question, you would create new user groups that give each of them the individual rights they should have. Basically, in the same way you create new roles with those rights, you can create new user groups with those rights. Yes, usually user groups are across the wiki, but the standard Protect action will remove the rights of certain groups on specific pages. I know it's not the same thing, but there is a precedent for user groups to be applied differently on individual pages.

To be clear, I don't have any issue with this extension being added to Canasta.

[yaronkoren]

What is the benefit of structuring these roles as user groups?

[tosfos]

It's a matter of taste, I guess. To me introducing a new concept of role adds complexity, technically and conceptually. The user groups already exist as a concept so users already understand them and the rights can be administered with core functionality. For example, you can set the group rights with a core global and see group rights via special page.

[jeffw16]

Per #205, this extension needs to be seconded by a member of the community before it can be considered for inclusion. There are currently no other seconders, so it cannot be considered further for inclusion in Canasta until someone seconds this proposal.