You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Adminstrate ClientConfig based on usergroup/role #88
This would be really useful to allow some users to change company information, whilst others cannot access that but may be able to amend email settings. I've noticed in some of the MODX templates out there that quite often colorpick has been added to clientconfig, and for some users I really wouldn't want them messing about with colors!!
It would be great to restrict individual fields based on a particular User group.
Or it may be easier to have it defined by Groups in ClientConfig. For example one ClientConfig Group would only be available to those in the Administrator Group (ACL), whilst our ClientConfig Groups would be available to those in the Site Manager Group (ACL) who do not have full Permission to access various parts of the manager.
It would work something along the lines of Resource Groups - anything that is assigned that particular Group is not available to a particular User Group.
Or similar to when you assign a particular Dashboard to a User Group.
I just wanted to open a new issue with this, but found my +1 here, again ;)
Though @pepebe 's request seems also reasonable and helpful, I'm by now strongly interested in @crimsonpixel 's request: Make settings or groups/tabs visible to specific user-groups or not.
As my collection of ClientConfig settings & tabs has grown over time, I am now in need for this feature:
Some settings, like demonstrated here, are more critical and should only be editable by Admins/Managers (the Agency, not the end-user).
If you @Mark-H are not already looking/working/thinking about this, I might take a look at this ... more sooner than later. And if I do: What and where do you think this feature could be integrated best/fastest?
Activity
[-]Adminstrator access based on usergroup/role[/-][+]Adminstrate ClientConfig based on usergroup/role[/+]crimsonpixel commentedon Feb 17, 2015
This would be really useful to allow some users to change company information, whilst others cannot access that but may be able to amend email settings. I've noticed in some of the MODX templates out there that quite often colorpick has been added to clientconfig, and for some users I really wouldn't want them messing about with colors!!
Mark-H commentedon Jan 31, 2017
Just to make sure I understand this correctly..
@pepebe: you want to restrict access to the admin part of ClientConfig not just on user group, but also by the role they have in that group?
@crimsonpixel: you want to be able of restricting individual fields to certain user groups?
crimsonpixel commentedon Feb 1, 2017
It would be great to restrict individual fields based on a particular User group.
Or it may be easier to have it defined by Groups in ClientConfig. For example one ClientConfig Group would only be available to those in the Administrator Group (ACL), whilst our ClientConfig Groups would be available to those in the Site Manager Group (ACL) who do not have full Permission to access various parts of the manager.
It would work something along the lines of Resource Groups - anything that is assigned that particular Group is not available to a particular User Group.
Or similar to when you assign a particular Dashboard to a User Group.
sebastian-marinescu commentedon Jul 25, 2017
+1
sebastian-marinescu commentedon May 22, 2018
I just wanted to open a new issue with this, but found my +1 here, again ;)
Though @pepebe 's request seems also reasonable and helpful, I'm by now strongly interested in @crimsonpixel 's request: Make settings or groups/tabs visible to specific user-groups or not.
As my collection of ClientConfig settings & tabs has grown over time, I am now in need for this feature:
Some settings, like demonstrated here, are more critical and should only be editable by Admins/Managers (the Agency, not the end-user).
If you @Mark-H are not already looking/working/thinking about this, I might take a look at this ... more sooner than later. And if I do: What and where do you think this feature could be integrated best/fastest?