ACLs are confusing

[abextm]

As it stands the ACL system is very confusing to most people. There are numerous issues with people not understanding what an ACL option does or that ACLs control certain behavior at all. Inheritance is poorly presented and certain rules imply others, which when combined create a very confusing experience.

• IP address leak #1780
• Text message flawed #1042
• Feature Request: Listen Permission #1352
• "Jail" channel #1315
• ACLs and Groups wiki page out of date #1265 (This is about the documentation, from 2014)
• allowhtml=true in ini needs more control #1169
• Group-Members Usability Enhancement #1502
• Creating a channel requires a registered user and a cert hash #1572

Having no way to inpsect a user's applied permissions makes debugging for the server owner/admin a long and frustrating process, often leading to many certificates with different permissions, because you can't remove your own Write ACL with an access token or even manually without getting out the SuperUser. If you don't mind having to use a different account to modify permissions (which I would consider best practice), you can't even use voice chat to figure out if what you are doing is helping.

Additionally, documentation in the "What is this" text is not incredibly easy to use or really complete. The wiki has two blog/tutorial style pages detailing some aspects of the ACL system, but is still lacking in some specifics.

This ticket is a discussion on what can be done to help mitigate this.

• Why is the SuperUser force-suppressed?
• Should we get a "ACL inspector" (perhaps in the Information... dialog)
• Do we want to change ACLs to make them more consistent with there names
• Do groups really need to be per-channel? Server-wide groups would be a lot less confusing.

[Kissaki]

Thank you for coming forward with your interest in improvement usability in this area.

Even if I don’t comment on the bigger questions, let me quickly answer what I can without much thought - from the top of my head.

Why is the SuperUser force-suppressed?

The idea is that the SuperUser account is a fallback system admin account. For example, if the server gets owned (someone else gains full control and removes your accounts control) you still have a fallback account to regain control.

If the superuser account were not force-suppressed (some) users will likely use it as a default-admin account for regular use. Force-suppression forces them to only use it in rare cases; for initial setup to give themselves admin privileges on their regular account, or other severe cases where they lose control otherwise.

With the idea that they only briefly use it to gain admin privilege on their regular account, hearing and talking is not necessary.

Of course, other use cases are presentable where this is not desirable; where an inexperienced admin needs [voice] guidance or takes his time with ACL setup and still wants to participate in ongoing voice communication.

Additionally, documentation in the "What is this" text is not incredibly easy to use or really complete.

Personally I think 'what's this' documentation should never be required to understand a concept. If that is the case either the concept is too complex (or at least lacks a simpler alternative for novice users) or presented suboptimally.

[toby63]

Even though this is probably a very controversial topic I want to add some suggestions:

1. I think the most confusing part for some people (including me) is the inheritage system.
   At this point I am not even sure if it can be disabled (as the checkbox (inherit ACLs) suggests it).
   If thats the case, the UI is still confusing and should be changed.
   Anyway, this system might seem very logical to some (or even many), but at least to some this is actually to complex.
   So I would like to have two options:

   1. An easy ACL system without inheritage (if you click add group it would simply suggest the options of a standard user).
      The order of groups in the list should be just optical (no technical function) and managed by the user.
   2. And a complex ACL system with inheritage (like it is now).

   At least on the UI level, these options should be clearly seperated.

2. Merge the tabs Groups and ACL:
   Also mostly a UI topic and an extension to the more easy acl system of point 1.
   For example: if I add a group in the groups tab, this group does not automatically show up in the acl tab.
   I would merge both tabs, so that I have a concept like this:
   You see a list of the groups and on the right side I have three buttons:

• add new group (would open window for setting group name and permissions)
• set permissions (would open window for permissions)
• manage groupmembers (would open window to add/remove users from userlist (searchable) or add user by name)

3. "Server-wide groups" (see above):
   Once again I would solve this problem with the UI.
   So the Channel groups would be (optionally) visible in the server groups list (maybe activation with a checkbox).
   They would be clearly seperated and sorted by channelname.