Jump to content

How to deny Super Users access to Setup, Modules and Roles / Permissions?


SwimToWin
 Share

Recommended Posts

In my world, Super Users / Editors should only be able to work with Pages and administer users.

Everything else is the domain of the web master. The purpose is to prevent technically inexperienced editors from destroying core elements of a site, such as fields and templates.

That leaves me with the question, how to deny Super Users access to Setup, Modules and Roles / Permissions?

PS: May I also suggest that it shall be possible to set Permission for each of the main menu items - including their sub-menu items.

image.thumb.png.b5a0ebe125e28215679683a5d54e6fb1.png

Link to comment
Share on other sites

16 minutes ago, SwimToWin said:

how to deny Super Users access to Setup, Modules and Roles / Permissions?

You cannot do that because a superuser is the "web master" in ProcessWire. Just do not give this role to anyone except yourself, create roles for others and you "are done" :)

Seriously, see this discussion, for example: https://github.com/processwire/processwire-issues/issues/371

 

  • Like 3
Link to comment
Share on other sites

It works. Thanks, much appreciated.

I also have a few reflections on the workflow in ProcessWire:

First of all - I am able to achieve the result. ProcessWire never lets me down.. :-)

However, getting there was a bit difficult due to a few things: (I say this in a positive spirit and as a constructive contribution to the ongoing development efforts)

1. It is unclear to me that the "Super User" role is in fact a "Web master" role.
1a. Recommendation to @ryan: Rename the "Super User" role to "Web master" to make it obvious that the super user is a co-administrator with permissions to work with a) contents and b) site structure.
1b. Recommendation: Create a default "editor" role with Permission to work with contents and users only. Adding an Editor should be as easy as adding a co-administrator. Why would I ever want to grant co-admin permissions to a customer? They can destroy the entire site structure by accident - in minutes).

2. I created a new "editor" role but granting Create and Edit permission is not possible on the "Edit Role" page. Why? "The page-add and page-create permissions can only be added from the template access settings and are shown here just for informational purposes." As a result, it is necessary to edit each of the relevant templates and specify role access (hard!).

2a. Edit Role page: Editor was allowed to "create pages" - but that is not enough to add pages in "sections" (/foo-section/new-page). Granting the "add children" access permission was also needed.
2b. Recommendation: Administration of each Role should be possible from the Edit Role page (/processwire/access/roles/edit/?id=1234&s=1&c=1).

I hope these observations and enhancement requests make sense and will prove usable in future development effors. And again, thank you for your quick reply and guidance.

Link to comment
Share on other sites

The superuser is like it's names suggests super. It's like the admin user you get in each other system out there. There aren't any access restrictions on that role. It's meant for the people developing the website and should not be used for content-creators. Also it wouldn't make much sense to add access restrictions to an user, which most likely has access to any configuration files as well as the database behind the website.

 

  • Like 2
Link to comment
Share on other sites

@abdus Handling modules is realm of the superuser as one can potentially break lots of things there. If you need non-superusers to edit module settings I'd create a custom process module, which does handle changing the module config in a more secure way with validation of changes and alike.

  • Like 5
Link to comment
Share on other sites

1 hour ago, SwimToWin said:

2. I created a new "editor" role but granting Create and Edit permission is not possible on the "Edit Role" page. Why? "The page-add and page-create permissions can only be added from the template access settings and are shown here just for informational purposes." As a result, it is necessary to edit each of the relevant templates and specify role access (hard!).

There is definitely room for improvement in terms of visualizing and making it easier to see an overall picture of roles and permission in effect, not to mention adjusting them.

Another thing to clear up is the guest role which should not be displayed anywhere because it is just a "placeholder" these days if I understand it correctly:

https://github.com/ryancramerdesign/ProcessWire/issues/588#issuecomment-52206316

https://github.com/processwire/processwire-issues/issues/203#issuecomment-285666212

Another nice reading is this one, showing the dilemma what dealing with roles and permissions mean:

https://processwire.com/talk/topic/1947-can-only-move-pages-if-can-edit-parent/?tab=comments#comment-18302

Roles and permissions is never an easy topic to discuss or implement;)  

Link to comment
Share on other sites

4 hours ago, SwimToWin said:

As a result, it is necessary to edit each of the relevant templates and specify role access (hard!).

You don't need to edit each template, and I don't think the permissions system is that hard once you understand that permissions can be inherited. Suppose you want your editor role to be able to edit, add and create children for all templates. You just edit the Home template, grant all the permissions to the editor role, and allow those permissions to be inherited.

 2017-10-10_130347.png.3ec251143401bd5c35c272c7be0e47d8.png

Now this applies to all pages using all templates, unless for a particular template you choose to "manage view and edit access permissions for pages using this template" and deliberately override the inherited permissions.

 

2 hours ago, szabesz said:

Another thing to clear up is the guest role which should not be displayed anywhere because it is just a "placeholder" these days if I understand it correctly

I don't think it's right that the guest role doesn't need to be displayed anywhere. Revoking view access for the guest role in the template settings is how a page may be restricted to authorised roles only.

  • Like 6
Link to comment
Share on other sites

4 hours ago, Robin S said:

I don't think it's right that the guest role doesn't need to be displayed anywhere. Revoking view access for the guest role in the template settings is how a page may be restricted to authorised roles only.

Sure, for technical reasons probably it is needed, I'm no expert in this regard, however the User lister showing guest all over can be confusing sometimes. About revoking view access and such, I can imagine the opposite; an option to revoke guess access by checking an option: "revoke guest access" instead of implicitly specifying it.

Link to comment
Share on other sites

 

13 hours ago, SwimToWin said:

As a result, it is necessary to edit each of the relevant templates and specify role access (hard!)

Generally I agree with @Robin S's comments to you about inheritance of roles - that should usually take care of things without the need to edit template's access settings. It sounds like in your case inheriting everything from the home page template down will do what you want. 

However, just in case you do ever need to make lots of change to multiple templates, this can help - it's from the AdminActions module.

screencapture-ecoreportcard-dev-admin-setup-admin-actions-options-1507625108641.thumb.png.7c79797703649369af0536f05ff6e51b.png

  • Like 4
Link to comment
Share on other sites

i think the superuser name is much better than webmaster: https://en.wikipedia.org/wiki/Superuser

and i think once you got some experience using permissions everything should be quite clear. i think my learning curve was:

  • create an editor role
  • assign page-edit permission
  • try to edit a page... why does it not work?
  • ah, i have to set the permission on the template level (meaning i can control it on a template level)
  • ah, i can inherit to all child pages
  • done

i think that's not too hard for someone wanting to work with user permissions :)

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...