Leaderboard

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

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:

Hi there, The title just about says it all! I wondered whether anyone has been able to achieve this? I've been trying all day to configure PHPStorm but no luck far Thanks --Gary

Just found this thread and it set me off exploring to see what debugging features were possible in Vim. I've not used a proper debug environment/IDE with PHP though I used to with assembly/C/C++. I found an excellent plugin (joonty/vdebug) that, coupled with XDebug, works amazingly well and allows you to single-step, watch variables (global and local scopes), set breakpoints on lines/conditions and do evaluations - in short, all the usual suspects. I've been using it to single step through PW as it builds pages - neat!

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; } }

Since you are setting your text fields directly from $input->post variables without sanitization/validation, make sure that all of your text fields have the HTML Entities textformatter enabled. To illustrate the potential problem, try putting this into a text field that does not have an HTML Entities textformatter enabled: <script>alert('gotcha!')</script> If you get a "gotcha" alert box, then someone can basically take over the entire page and your site is vulnerable to cross-site scripting attacks. That's why it's really important to make sure any output coming from non-trusted users is always entity encoded.

You should also be able to do this: $biology_students = $pages->find("template=student, subject=/subjects/biology/, sort=title");