Advanced true - @ Template SYSTEM Tab - "Disable Settings Tab" checkbox question

[Raymond Geerts]

When having set advanced to true in the config.php file of PW, then an extra tab called "SYSTEM" shows up when editing a Template.

There it is possible to set a checkbox for "Disable Settings Tab".

It would be nice to be able to have another checkbox to add the option to "Disable Settings Tab Not for Super Users".

I'm not aware of any situation where one would like to disable the settings tab for the super user, but possible there is one or more cases that im not aware of.

In my case i want to hide this settings tab to all non-super users, but have it available when im logged in as super user (admin) so that i can modify settings while developing new things. Now i have to uncheck "Disable Settings Tab" for all users so i can use it and check it again when im done editing. Then there is a chance any other non-super user that is logged in is also able to change settings from this tab on the regarded template.

[ryan]

The stuff that you see in that 'system' tab actually for development of ProcessWire itself. It's not meant for use on sites, and may be dangerous to change stuff in there. Likewise, disabling the settings tab isn't something meant for normal pages, and could potentially cause problems since it was really only meant for specific cases with types descending from Page and not Page itself.

But even if it were safe, I think it may not necessarily be a good idea because that Settings tab is intended to be hookable for other modules to add functionality if they deem it to fit better in 'settings' than 'content'. A better way to disable specific settings is to disable access to the features that are in settings, all of which are aware of user permissions (except for 'name').

For instance, if you don't want them to be able to change the parent page, then don't give the user's role access to 'page-move' permission. If you don't want the user to be able to change the template, then use the template's family settings to define what's allowed or limit the users access to just that template.

That only leaves the page's "name" as something that can be changed in the settings tab. If someone has access to edit a page, they also have access to edit the name. PW does check for access to edit "name" but the permission system doesn't implement it. Meaning it's currently setup for hooks to implement if they choose to. But this will get implemented once we have field-level permission assignments, which are on the to-do list.

[Raymond Geerts]

Thanks for explaining that, its now clear to me what the real purpous of the "Disable Settings Tab" checkbox is.

I have a user which has only the access rights to view and edit pages with certain templates.

Some pages in my site are hidden by purpous so that they do not appear in the menu displayed on the website.

When that user logs in they can unhide the page because they have access to the settings tab.

I would like to prevent that, so thats why i used the "Disable Settings Tab" checkbox for that.

Is there a different way to prevent the user from being able to unhide a certain page?

Also, but that is merely my own 'fault', i used the page name in a php switch to set certain variables and functions hardcoded. I probably should have used a different aproach for this for example the template name instead of the page name. But that is also one reason why i would like to have the settings tab not visable so the user can not change the page name.

[ryan]

I see what you mean, I was forgetting about the status settings. Also, I do the same thing with page 'name', but admittedly have never had a problem with a client changing it when they weren't supposed to. But this is all easy to overcome with a module. I think this will accomplish what you want to do. I've also tested this to confirm, so it should work out of the box. As it is now, it'll deny access to editing of name, parent, template, status for everyone except superuser. But I put in variables at the top where you can add additional templates or roles that should fall-back to the default permission checks as if the module wasn't here.

One thing I want to note is that PageEdit doesn't perform a permission check before displaying the status checkboxes. However, it does perform a check before saving them. So the user may see them, but they won't be able to change them (which is probably just as good).

Code is pasted below, but I'm also attaching the file if you prefer to download it instead:

CustomPagePermissions.module

class CustomPagePermissions extends WireData implements Module {

 public static function getModuleInfo() {
   return array(
    'title' => 'Custom Page Permissions',
    'version' => 1,
    'summary' => 'Starter/example module to enable customization to page field permissions.',
    'singular' => true,
    'autoload' => true,
   );
 }

 // names of fields that you want to deny access to      
 protected $denyFields = array('name', 'status', 'template', 'parent');

 // optionally specify names of templates that will be excluded from these permission checks
 protected $skipTemplates = array();

 // optionally specify names of user roles that will be excluded from these permission checks
 protected $skipRoles = array('superuser');

 // attach the hook
 public function init() {
   $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); 
 }

 // perform the editable() check
 public function hookPageEditable($event) {

   // if editable() already denied access, then don't continue
   if(!$event->return) return;

   // if user has one of the 'skip' roles identified above, then skip permission check
   foreach($this->skipRoles as $name) if($this->user->hasRole($name)) return;

   $page = $event->object; 
   $fieldName = $event->arguments(0);

   // if page template is one you want to skip, then we'll return
   if(in_array($page->template->name, $this->skipTemplates)) return;

   // if fieldName is one of those listed, we'll deny access 
   if(in_array($fieldName, $this->denyFields)) $event->return = false;
 }
}

[Raymond Geerts]

Ryan you are truely amazing. This should do the job exactly what i was needing. Thank you for this module!

I just was wondering if the status value is enough in the folowing line:

protected $denyFields = array('name', 'status', 'template', 'parent');

Because im still able to modify the "Hidden: Excluded from lists and searches" as a non super user

But further it works fine, the non super user can not change the name value anymore

[ryan]

Because im still able to modify the "Hidden: Excluded from lists and searches" as a non super user

Try checking one of the boxes and saving the page. While it'll let you check/uncheck, it shouldn't let you actually save it. So after hitting save, click to somewhere else and come back to the page and you should see that the value did not save. The reason for this is:

One thing I want to note is that PageEdit doesn't perform a permission check before displaying the status checkboxes. However, it does perform a check before saving them. So the user may see them, but they won't be able to change them (which is probably just as good).

[Raymond Geerts]

Ha, nice indeed. I see it does'nt save the changes there.

Thanks again Ryan for this module!

[ryan]

Raymond, I've posted another module that accomplishes this (and more) much better than the one I posted above. And this one actually would remove the 'status' field from the user's visibility as well: