Skip to main content ↑ ↓
Topic: Admin role (Read 3401 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Admin role

I'm pretty sure I discussed this before, but I can't find the topic, maybe it was on a PM or something, well, not a big issue. :P

Yes, I know, admin can do anything. No, it's not always and not entirely true.
If the server is setup properly, an "admin" cannot install mods unless he knows the ftp details for example. So, it's not black-or-white, but there are some shades of grey in between.

I think it would be nice to have a... "second level" admin group defined at install time (pretty much like global moderator is).
That's something easy to do, just tweak the install, so it can be done even at the last moment before the release. O:-)

I was wondering: what kind of permissions should be given to such a group?
I suppose manage members (registrations/bans), manage permissions. What else?
It should also be a protected group I think, so that only admins and other "co-admins" (let's call it like that for the moment) could assign it.
And finally... what would be a good name?

This exercise is good also because if there is to split some permissions we can track them down for the next version. ;D
Bugs creator.
Features destroyer.
Template killer.

Re: Admin role

Reply #1 –

Perhaps just more detailed admin permissions would be better than creating grouped roles that some sites will never need. The first thing I usually do as an admin is delete a lot of defaults in a board install, including the Global Mod group. I'd have to do the same with this new admin group.

Splitting and allowing more fine control of admin permissions might be the way to allow admins to create their own "sub-admin" group and allot them the permissions they want, rather than what Elk thinks are necessary.

Re: Admin role

Reply #2 –

You are an experienced user.
Most of the people I have in mind would just put anyone into the admin group, and then regret the fact.

I don't see it as "Elk thinks for you", I see my suggestion more like "hey, you can do that, no need to give away full admin rights".
Of course one can then tune the groups the way he likes.

I think the vast majority of the scripts out there comes with pre-defined stuff just to make it easier for people approaching the script the first time not get lost in a tons of permissions (and you should know the permissions admin panel is not exactly "friendly").
Bugs creator.
Features destroyer.
Template killer.

Re: Admin role

Reply #3 –

I know other software( not naming names) has a super admin and only one of then unless you edit the config.php. This super admin has access to everything both in the ACP and server side if needed. You can the have admins but they won't have the access that the super admin would have. Not sure if that helps

Re: Admin role

Reply #4 –

Quote from: emanuele – You are an experienced user.
Most of the people I have in mind would just put anyone into the admin group, and then regret the fact.

I don't see it as "Elk thinks for you", I see my suggestion more like "hey, you can do that, no need to give away full admin rights".
Of course one can then tune the groups the way he likes.

I think the vast majority of the scripts out there comes with pre-defined stuff just to make it easier for people approaching the script the first time not get lost in a tons of permissions (and you should know the permissions admin panel is not exactly "friendly").

A fair assessment, I just hate the super admin/sub admin division when the opposite occurs. Inevitably, some admin will create the site, and make a more experienced user the admin with lesser permissions. It's just as frustrating being that user, and not being able to do what you need (and consequently not getting the main admin to understand what's going on and what needs to change) than it is for an admin to give out too much permission.

Re: Admin role

Reply #5 –

In that case you can then edit the config and make user X a super admin as well. So in what you are saying @Eliana Tamerin  doesn't happen.

Re: Admin role

Reply #6 –

Quote from: Allan – In that case you can then edit the config and make user X a super admin as well. So in what you are saying @Eliana Tamerin  doesn't happen.

It can and it does, for the exact same reason as emanuele wants to create this new admin role. Because your average board admin isn't smart enough to understand permissions.

Re: Admin role

Reply #7 –

Quote from: emanuele – I think it would be nice to have a... "second level" admin group defined at install time (pretty much like global moderator is).
[...]
It should also be a protected group I think, so that only admins and other "co-admins" (let's call it like that for the moment) could assign it.
And finally... what would be a good name?
That's exactly what I did on a SMF forum. I'm a Mod and the admin (non-tech guy) has given me the passwd for a full-admin account. Not liking this, I made a protected, invisible group based on "Maintenance" profile to which users able/willing to help could be assigned temporarily. A default group (maybe "Technical Support" or something similar) would be great! I just called it "Tech" since "Geeksters" seemed too cheesy (not that it would show on the boards, anyway...).


Quote from: emanuele – I was wondering: what kind of permissions should be given to such a group?
I suppose manage members (registrations/bans), manage permissions. What else?
Maybe manage the forum structure? Like Categories/Boards, Portal etc since that's not that trivial.
Also, Addons/Themes because there might be in the future ones that are not that well coded and the risk of corrupting a forum with a bad install/uninstall is great. Which points to the idea of some kind of local database backup (on the server itself, in a protected folder, so that security-sensible info and/or private content in the database would not be accessible) to which the Tech should be given permission to manage but not download/edit.
Last Edit: January 18, 2015, 05:31:59 am by hugbear

Re: Admin role

Reply #8 –

I would hand out soft delete and non admin status removal permissions to 3 rd parties in case of need.
 

Re: Admin role

Reply #9 –

Quote from: hugbear – Maybe manage the forum structure? Like Categories/Boards, Portal etc since that's not that trivial.
Makes sense.

Quote from: hugbear – Also, Addons/Themes because there might be in the future ones that are not that well coded and the risk of corrupting a forum with a bad install/uninstall is great.
That would be... depends.
With the current definition of install/uninstall, I wouldn't give out that permission: install a package means basically mess with the file system (copy files, modify files, etc.) and under certain circumstances break badly the forum[1]. With the enable/disable definition I'm working on for Elk 1.1, this may be feasible: the "sys-admin" installs (i.e. uploads and unzip) the package, then enable or disable it is just a matter of toggling a value in the database, so it's relatively safe and it shouldn't break anything.

Quote from: hugbear – Which points to the idea of some kind of local database backup (on the server itself, in a protected folder, so that security-sensible info and/or private content in the database would not be accessible)
Yes, that would be cool, except the majority of hosts[2] doesn't give access to non-web-accessible directories and/or the admin doesn't know what web-accessible means at all or doesn't care. And this would really be bad for security and privacy[3]
1 For example if file ownership is wrong, or if the admin doesn't pay attention to an error, etc.↵
2 At least in my limited experience.↵
3 Heck, this is the main reason I don't really give much importance to the SQLite implementation, because SQLite uses as database a file and from my experience, this file is frequently (always) stored in the forum root, making it accessible to anyone, with the only "protection" of a randomized name.↵
Bugs creator.
Features destroyer.
Template killer.