feat(permission): add the no one permission

[luceos]

One thing that has been very frustrating while developing extensions is that you cannot easily create a feature that you would like to allow disabling through the permission grid. Some solutions I've seen is allowing admins to choose the tags something should be active in or by simply creating toggles in the settings page; but neither of these solutions allow the fine grained control the permission allows.

This Proof of Concept PR is a question, whether I'm the only one running into this limitation for Flarum.

It does:

• introduce a fake permission, similar to Guest
• removes the whole permission entry from the db when selected
• restores the permission visually on the frontend

It still has to:

• confirm admins also cannot use the permission if selected User\Access\Gate::90
• not break v1.x functionality or be moved to v2.0
• appeal to core and community
• identify whether introducing this permission will cause some permissions that would have been previously adopted from the top level "view" permission to become "no one" thereafter

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

Required changes:

• Related documentation PR: (Remove if irrelevant)
• Related core extension PRs: (Remove if irrelevant)

[SychO9]

The use case is definitely valid, but the introduction of a no one permission imho complicates the already complicated permission system.

The permission UI grid already has a concept of settings (see edit post permission which is a setting) so imo, the best way of solving this, is to keep such a toggle on the backend as a setting value to turn on/off said feature. And on the UI grid, add support for the permission dropdown to be linked to a specified setting to turn off X permission, the dropdown item could then be labeled no one or such.

[luceos]

so imo, the best way of solving this, is to keep such a toggle on the backend as a setting value to turn on/off said feature.

I think that the setting option is very complicated for something so easily supported and I still believe this would make sense for 2.0+. For now I'll use your suggestion 👍 thanks.

[SychO9]

It shouldn't be if we adapt the permission dropdown to turn off/on the setting with a no one item. I'm only thinking out loud though, not giving any concrete solutions.

I think since we also have the issue of setting permissions on the UI (like the post edit permission) not being applicable per tag, cause it's not an actual permission,

we should brainstorm changes to the permissions system/UI taking into consideration all issues, so that we can find a consistent approach to everything.

[garygreen]

This is something I ran into yesterday! E.g. for the Tags plugin I want to globally disable the permission "Bypass tag requirements" permission because I don't want even admins to be able to bypass those tag requirements.

I can see the rationale behind why admins are currently forced to be allowed to do everything, like a superuser - although admins have the ability to edit all permissions, it's useful to reduce visibility of features that aren't necessary or shouldn't be easily accessed by admins.

Notice how it's greyed out/disabled, so it's impossible to remove all permissions

This PR implementation does seem complicated. Perhaps we can simplify the process by providing a more intuitive solution. For example, we could make it possible to untoggle all permissions in the dropdown. So when "Admins" is clicked on the above, all the groups will appear deselected and show an empty icon indicating that it's not assigned to anyone.

[garygreen]

Just thinking about this a bit more - technically the current "admin" group is a "superuser" who is able to do ANYTHING and that cannot be changed. It seems permissions are hardcoded to always allow actions from admins, so it could be tricky changing that paradigm now.

So to work around this, you could add e.g. a "Managers"/Executives/Directors etc group and switch your current admins to use that group. This provides the ability to disable features/permissions you don't need.

That's possible to do right now, so maybe this isn't needed. Though it would be cleaner to be able to simply unassign all groups from a permission.

[luceos]

So when "Admins" is clicked on the above, all the groups will appear deselected and show an empty icon indicating that it's not assigned to anyone.

This is actually happening behind the scenes. Unlike the current behavior, when you choose No One it will remove all permissions in the background. The frontend now simply shows No One in case no groups are assigned to the permission. My implementation might not be the cleanest :)

I also have been thinking more and my opinion remains that we need this. The fact that a super admin exists that can use features they might not even want to use but are forced to see and probably even use, doesn't make Flarum really friendly. I think we should opt to add this solution or come up with a better version of something similar. But force allowing Admins to do anything through the Gate should be a thing of the past soon.