SMF Development > Feature Requests

"Administrate forum and database" permission split up

<< < (2/6) > >>

emanuele:
So basically you would like a single permission for every single menu entry?

Yoshi:

--- Quote from: emanuele on April 12, 2012, 07:55:14 AM ---So basically you would like a single permission for every single menu entry?

--- End quote ---
No, for anything an admin can do. Not for every menu entry.

Just allow people to tune the permissions in precision instead of a sluggy master permission.

emanuele:
Disclaimer: I'm not trying to say the proposal is not valid, I'm discussing how it could be useful. ;)

Okay, then I can start with the short list you posted:

--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---1. Install packages.
2. Install languages.
3. Modify server settings.
--- End quote ---
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.


--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---4. Enable/disable core features.
--- End quote ---
So you would give a person the ability to enable or disable core features just "for the fun of it"?
A core feature is something important that should be part of the forum or not based on the goal of the forum, not just something that (warning: exaggeration) a moderator should be able to turn off.
I think.
Additionally have the permission to install packages without the permission of enable core features is rather useless...


--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---5. Open the Error Log.
--- End quote ---
In certain cases maybe this could help. Not sure how and why but it could I think.
Even though most likely any non-admin wouldn't be able to do anything in case of errors


--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---6. Open the Administration log.
--- End quote ---
That's called "administration" because only admin should be able to see it.


--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---7. Open the Moderation log.
--- End quote ---
?action=moderate;area=modlog
It's already a separated permission, you only find it in another location.


--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---8. Run maintenance tasks.

--- End quote ---
Within the maintenance tasks thre is also the "database" set of tasks, giving someone the permission to access this gives him the permission to 1) convert the forum to utf8 (not exactly something that should be allowed to non-admins), 2) backup the database (i.e. gives the permission to collect all the email addresses and all the PMs of any member of the forum, again something a non-admin should not be able to do)
That said, I can agree that give separate permission to perform routine, members and topics maintenance tasks to another person without giving him any other permission could be useful.

So, from your list I'd save the permission to view error logs (should the list take care of hide IPs and/or personal informations?) and to run "basic" maintenance tasks.
Additionally I would add:
* a permission to manage current theme/layout (but that would be tricky because the non-admin member should not be able to change directories and urls IMHO);
* censored words could be linked to security and moderation and given a separated permission;
* calendar administration?...maybe...even though there isn't much to do.

That's what I can think about. All the other pages seem to me pretty much related or too "important" for a stand-alone permission...

Yoshi:
I just chopped these right out of my head though.


--- Quote from: emanuele on April 12, 2012, 08:40:04 AM ---Disclaimer: I'm not trying to say the proposal is not valid, I'm discussing how it could be useful. ;)

Okay, then I can start with the short list you posted:

--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---1. Install packages.
2. Install languages.
3. Modify server settings.
--- End quote ---
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.
--- End quote ---
I think Server Settings should be separated anyway. Granting someone the permission to install packages doesn't mean they should be able to mess around with the server. They can ask the admin anyway if something fails to work.


--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---4. Enable/disable core features.
--- End quote ---
So you would give a person the ability to enable or disable core features just "for the fun of it"?
A core feature is something important that should be part of the forum or not based on the goal of the forum, not just something that (warning: exaggeration) a moderator should be able to turn off.
I think.
Additionally have the permission to install packages without the permission of enable core features is rather useless...
--- End quote ---
Yes, though some sites have things as co-admins or even a separate group for site maintainer which should be granted permission to check that stuff.


--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---5. Open the Error Log.
--- End quote ---
In certain cases maybe this could help. Not sure how and why but it could I think.
Even though most likely any non-admin wouldn't be able to do anything in case of errors
--- End quote ---
I think it'll help with checking the status of the site; not only admins should be allowed to do so.


--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---6. Open the Administration log.
--- End quote ---
That's called "administration" because only admin should be able to see it.
--- End quote ---
Again coming with the point of co-admin and site maintainer.


--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---7. Open the Moderation log.
--- End quote ---
?action=moderate;area=modlog
It's already a separated permission, you only find it in another location.
--- End quote ---
Meh, my bad ;D


--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---8. Run maintenance tasks.

--- End quote ---
Within the maintenance tasks thre is also the "database" set of tasks, giving someone the permission to access this gives him the permission to 1) convert the forum to utf8 (not exactly something that should be allowed to non-admins), 2) backup the database (i.e. gives the permission to collect all the email addresses and all the PMs of any member of the forum, again something a non-admin should not be able to do)
That said, I can agree that give separate permission to perform routine, members and topics maintenance tasks to another person without giving him any other permission could be useful.
--- End quote ---
Yes, that's what I'm thinking. Maybe even create a sub-permission like "Manage the database" or something that allows you to do the database routine.


--- Quote ---So, from your list I'd save the permission to view error logs (should the list take care of hide IPs and/or personal informations?) and to run "basic" maintenance tasks.
Additionally I would add:
* a permission to manage current theme/layout (but that would be tricky because the non-admin member should not be able to change directories and urls IMHO);
* censored words could be linked to security and moderation and given a separated permission;
* calendar administration?...maybe...even though there isn't much to do.

That's what I can think about. All the other pages seem to me pretty much related or too "important" for a stand-alone permission...

--- End quote ---
Guess I'll agree with that, though the first point doesn't need to be difficult; just do not allow access to the paths stuff.

Norv:
Fully agree with Emanuele.

I don't really see the usefulness of error logs without IPs and in fact I can think of more; nor am I sure about (immediate, i.e. 2.1) need for calendar admin.

I'd add a couple of things here.

--- Quote from: Yoshi2889 on April 12, 2012, 07:59:54 AM ---
--- Quote from: emanuele on April 12, 2012, 07:55:14 AM ---So basically you would like a single permission for every single menu entry?

--- End quote ---
No, for anything an admin can do. Not for every menu entry.

Just allow people to tune the permissions in precision instead of a sluggy master permission.

--- End quote ---

One "sluggy" master permission is there basically because just about any admin action like those either requires or implies others. They give one (or require one to have, to do the job right), *admin* permissions over the forum.


--- Quote ---
--- Quote ---
--- Quote from: Yoshi2889 on April 12, 2012, 07:51:18 AM ---1. Install packages.
2. Install languages.
3. Modify server settings.
--- End quote ---
If you allow someone to install a package he should be allowed to install a lang-pack and vice versa. In my opinion.
But to install packages then you may need to be able to modify server settings, or maybe you just need to know then (i.e. ftp password).
So I don't see any reason to separate them.
--- End quote ---
I think Server Settings should be separated anyway. Granting someone the permission to install packages doesn't mean they should be able to mess around with the server. They can ask the admin anyway if something fails to work.

--- End quote ---

One of the problems here is, "something fails to work" in package installation may put the site offline. Until they can ask the admin.
Also, they can find out the server settings anyway, since they are able to install a package which does/reads anything on forum database/files. In other words, granting someone permission to install packages means they are perfectly able to mess around with the entire forum.


I don't know what means the concept of co-admin, if it's not an admin of at least "forum and database".

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version