Sandman RSS Feed
Member
Please make it so super administrators have to be set via the config file again, and not set via the ACP.
Upvote
0
Not planned Set Super Administrators In Config File
- Thread starter Sandman RSS Feed
- Start date
Sandman RSS Feed
Member
Well that was short lived, so much for suggestions. 
For a number of years, it has become apparent that a large number of users have misunderstood the concept surrounding super administrators and administrator permissions.
What we see from a support perspective is confusion surrounding the significance of what a super administrator is and confusion surrounding the usage of administrator permissions, particularly many people not actually realising they exist. We've even seen people completely breaking their sites because they make mistakes while editing their config file.
As most power users will know, a super administrator is a user who automatically has all administrator permissions and a user who has full control over all other administrators.
If you know and understand that then that's great, but that doesn't seem to be the case even in the majority of cases.
A common situation we see is an admin creating a new admin account for themselves, not giving themselves super admin, and then creating support situations for us and add-on developers when their new admin account can't access functions within their new add-on but their old one can. It leads to the expectation that all admin accounts automatically have all permissions.
Whereas, if when creating the new admin, those controls for super admin and the permission situation is explained, it should avoid confusion in the future.
Similarly there's the potential misunderstanding that changing the permissions an administrator has actually has any effect on a super administrator. If an admin forgets or misses the indication that an administrator is a super then an admin may think they are removing permissions from an admin when they're not.
Finally, we do see mistakes being introduced within the config file itself. Whitespace above the opening <?php tag can cause issues. Invalid characters (such as
All things considered, there's many more reasons to keep it in the UI than there are to move it back to a file and as such we won't be considering a u-turn on that at this time.
What we see from a support perspective is confusion surrounding the significance of what a super administrator is and confusion surrounding the usage of administrator permissions, particularly many people not actually realising they exist. We've even seen people completely breaking their sites because they make mistakes while editing their config file.
As most power users will know, a super administrator is a user who automatically has all administrator permissions and a user who has full control over all other administrators.
If you know and understand that then that's great, but that doesn't seem to be the case even in the majority of cases.
A common situation we see is an admin creating a new admin account for themselves, not giving themselves super admin, and then creating support situations for us and add-on developers when their new admin account can't access functions within their new add-on but their old one can. It leads to the expectation that all admin accounts automatically have all permissions.
Whereas, if when creating the new admin, those controls for super admin and the permission situation is explained, it should avoid confusion in the future.
Similarly there's the potential misunderstanding that changing the permissions an administrator has actually has any effect on a super administrator. If an admin forgets or misses the indication that an administrator is a super then an admin may think they are removing permissions from an admin when they're not.
Finally, we do see mistakes being introduced within the config file itself. Whitespace above the opening <?php tag can cause issues. Invalid characters (such as
’ instead of ') can break things. And generally issues surrounding character encoding, problematic FTP clients, broken file uploads etc. are all a recipe for disaster.All things considered, there's many more reasons to keep it in the UI than there are to move it back to a file and as such we won't be considering a u-turn on that at this time.
ibnesayeed
Well-known member
While this is a great idea to put this option in the ACP, but it might be worth keeping the option in the config file too for situations when an only admin locks herself/himself out.
And, yet, in that particular example the user sorted it out by editing the database. Which is exactly what we'd recommend in lieu of the config file support, so that really seems like a moot argument.
Especially seeing as, if there's only one admin, there's not actually much you can do via the config file.
Especially seeing as, if there's only one admin, there's not actually much you can do via the config file.
ibnesayeed
Well-known member
I was actually pointing to this idea only as an alternative in situations where it might make sense:
However, I am totally cool with having less things that require a code change, because it is a lot easier to have a frozen deployment with automated CI/CD systems that way.
whynot
Well-known member
Don't be surprised.
What was good for you/us was not that good for the support.
Sandman RSS Feed
Member
Spock says, “Logic clearly dictates that the needs of the many outweigh the needs of the few"
whynot
Well-known member
You win.
As a loser I have to keep my XF 1.X
Similar threads
- Question
- Deleted member 91401
- XenForo questions and support
- Question
- Question
