News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Error in Manage Permissions for group?

Started by PoML, October 16, 2019, 06:03:36 PM

Previous topic - Next topic

PoML

I have tried to enable a group "memberadmin" to edit profile fields under "account settings" for payments without having full access to all admin functions in the forum.
This seems to be impossible, and it looks to me to be a bug:

1) "Memberadmin" was originally set up to have granted the "Allow Forum Profile edits" and all other member profile permissions.  However, it did not give said edit permission to account settings (but allowed to delete user and posts etc).
2) Tried to make the "Memberadmin" have negative permissions and removed database admin rights and added the user to the admin group. Result was that admin group overrides any negative "disallow" permission settings.



Is there any other way to do this?

Arantor

The simplest way usually is to go to the group membership area and make users 'moderators' of the different groups that they should be able to let people join or remove people from.

Doing anything related to paid subscriptions otherwise requires full admin powers.

Also, it's not a bug; if you have someone in the admin group, they automatically have every power regardless (on the basis that as admins, they could just give themselves the powers anyway). Alternatively, give them access to 'manage membergroups' but this is a bit more power than you probably want to give out.

PoML

Thanks for the reply.
however: if it is not is bug that giving a certain access does not influence said access, then why are those settings there in the first place? as you say, admins have every access regardless.

Unfortunately, the moderator trick does not help as we do not want to link it to certain groups. It is just a field  to state which year the person last paid their club member fee.
The person that keep track of that should not have full admin access.

efk

Quote from: Arantor on October 16, 2019, 06:11:34 PM
Alternatively, give them access to 'manage membergroups' but this is a bit more power than you probably want to give out.
PoML, if you have private/hidden boards and you grant such power, then user with that access can grant himself and to all membergroups that are not under "Protected" status access to all boards on forum, so private area won't be private anymore, or one morning you might see that everyone can post everywhere, depends how much you had played with membergroups  ::)

PoML

Quote from: efk on October 20, 2019, 06:53:05 PM
Quote from: Arantor on October 16, 2019, 06:11:34 PM
Alternatively, give them access to 'manage membergroups' but this is a bit more power than you probably want to give out.
PoML, if you have private/hidden boards and you grant such power, then user with that access can grant himself and to all membergroups that are not under "Protected" status access to all boards on forum, so private area won't be private anymore, or one morning you might see that everyone can post everywhere, depends how much you had played with membergroups  ::)

Exactly. I want a more granular approach where the person updating one single hidden field in the membership profile of  all members does not get access to all and everything of technical as well as user group data.
I  wanted to grant: access for a select user to edit custom profile fields, including hidden profile fields, I do NOT want to grant full admin access.

See the snapshot from parts of the "General permissions " page for the "medlemsadmin" group attached, that to me looks like this should be possible.
However, any access rights given here for "member profile" and "Member accounts" does not seem to make any difference.


Arantor

SMF does not support granular permissions for custom fields in the way you want, and it is a non trivial change to make it support such.

PoML

Quote from: Arantor on October 21, 2019, 07:22:05 AM
SMF does not support granular permissions for custom fields in the way you want, and it is a non trivial change to make it support such.

That's fine, but then I suggest we remove the entire sections regarding this in the "Manage Permissions" that led me to believe it would have an effect to use these settings.

Several of the settings like the options to allow groups to "Edit additional profile settings" or "Edit account settings" does not seem to serve any purpose for "Any", as well as the "Administrate forum and database" seems to have no purpose if this and most other settings are really governed solely by membership of the built-in admin group instead.


Dag

Arantor

There is a difference between having admin_forum and being in group 1. Group 1 admins can always at any time do everything, see everything, etc.

The more granular permissions are for lesser groups (it's possible to have admin forum and not be able to manage permissions if I remember rightly)

I don't believe that a major change is required because it is functioning as designed, but sometimes misunderstood.

PoML

I am genuinely confused. Either there are support for granular admin type permissions or there are not.

Tests
Quote from: Arantor on October 22, 2019, 06:09:23 AM
There is a difference between having admin_forum and being in group 1. Group 1 admins can always at any time do everything, see everything, etc.

What I am trying to say is that there seems NOT to be a difference at all if you set these permissions.
Either I totally misread you, or you have not quite grasped what I say.

Setting or disabling admin_forum for anybody in group 1 has no effect, as being in group 1 overrules it.
Setting admin_forum for anybody NOT in group 1 also seems to have no effect.
Setting edit_account_settings for anybody NOT in group 1 also seems to have no effect .

It could be that I look for the wrong thing - is there anything in the documentation that I have missed?

Kindred

Quote from: PoML on October 23, 2019, 04:00:57 AM
Setting or disabling admin_forum for anybody in group 1 has no effect, as being in group 1 overrules it.
Setting admin_forum for anybody NOT in group 1 also seems to have no effect.
Setting edit_account_settings for anybody NOT in group 1 also seems to have no effect .

the first statement is correct, because -- by definition, if they are in group 1, they have all permissions. period.

you are incorrect in your last two statements

SMF is an INCLUSIVE/ADDITIVE permissions model.
You have any permission granted by ANY group you are in between allow/disallow permissions.

the exception is if you have turned on the option for DENY permissions.
A DENY permission becomes EXCLUSIVE and the user will always be denied that permission, regardless of how many groups include the permission as "allow".
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Arantor

...unless they are in group 1 which cannot be overridden by anything.

Advertisement: