Module: Page Edit Field Permission

[ryan]

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.

[Soma]

Just tested and downloaded and installed via Modules Manager. Works great so far! Thanks for this module Ryan

[Raymond Geerts]

Great! Going to try it tomorow asap, its now 1:30 night, must sleep. Thanks for this module!

Field level access permissions FTW!

[Raymond Geerts]

Just installed it trough Module Manager too, works great as far i can see. Straight forward logic.

Going to do some more testing comming monday when im at the office.

Thanks for this.

@Soma also thanks for the Module Manager that works realy nice and easy

[Martijn Geerts]

Soma has a lot of great modules! Check his teflon admin theme to!

[bfncs]

This module is really working great, thanks a lot for your work on this, Ryan!

While using it I stumbled upon a smallish bug with uppercase chars in field names, but to fix this probably needs changes in core.

Please share your thoughts on this one.

[Nico Knoll]

Looks great, thank you!

[ryan]

While using it I stumbled upon a smallish bug with uppercase chars in field names, but to fix this probably needs changes in core.

Thanks, I sometimes forget we support uppercase chars in field names (I don't use them myself). We can't support uppercase in permission names, since they are ultimately page names. But I think I can make this case insensitive. This won't be a problem, as you can't have two fields with the same name from the DB side, of different case. Can you tell me if this update fixes it for you?

https://github.com/ryancramerdesign/PageEditFieldPermission/commit/449dee6eabd3e7adc733ae829568f1828a5d87b5

[adrian]

Ryan,

Not sure if this is the best place to ask, but I am using a front-end form that makes use of the select image/insert image modal popup. I am requiring the user be logged in for this, but I'd prefer not to have to give them edit rights (just want to keep the entire admin inaccessible to their role). Only problem is that the select image only works if I give them page edit permission. I'd love if access to this could be made available through this module (maybe tied to "page-edit-images"), or perhaps some other approach.

Thanks for any suggestions

[ryan]

That was never meant to be used on the front end. I'm impressed you actually got it to work. That module really does need to bind itself to page-edit permission just for the security of the admin. But what you might want to do is copy that modules files to your own dir in /site/modules/ and rename them, and rename the class to something like ProcessPageEditImageSelectCustom. From there, you can modify it to do what you need. 

[adrian]

Ryan,

I don't suppose you'd consider changing the permission for that module to 'image-select' or something along those lines. I could make the argument that you might want to be able to give some backend users the ability to upload files and images, but not be able to edit pages. One scenario might be giving the new high school intern the ability to upload new images for a gallery/carousel without access to anything else.

I'll make use of your suggestion to move the module and rename the class for now though.

Thanks as always! 

EDIT: I guess this would only work if you could have multiple permissions for the module (is that possible?). Either that, or is there a way to inherit 'lower level' permissions - ie the page-edit permission includes image-select permission? Maybe I don't have a full handle on all the permission/role options just yet

[ryan]

The ImageSelect module doesn't actually let you upload images. It just lets you browse, select, and resize them. It's not very useful outside of the TinyMCE context, though the plan is that we'll make it work with other editors as we add them. But because it's designed as something to be used from the Page editor, that's why the base permission for it is page-edit. The actual upload capability comes from the InputfieldFile module. 

[adrian]

Good point about what that module does - sorry I think I was a little sleepy when I posted that. 

Anyway, I have it working on the front end as I need it to, so all good.

Thanks

[petsagouris]

Unless I am missing something this module does not work for individual languages in fields that have language support. I tried doing it on my own but I have little knowledge of Processwire inner workings to make this happen. I've even tried stepping and evaluating expressions with XDebug to no avail.

Can anyone give me pointers on the following two things:

1.  Getting the $languages array inside the PageEditFieldPermissionConfig function
2.  Checking that the current field in the field traversal is actually a Language supporting one.

Furthermore I'd like to ask Ryan, if there is a reason that the PageEditFieldPermissionConfig function is placed in its own file?

I am asking because there seems to be very little need to do so, since the PageEditFieldPermission::getModuleConfigInputfields() is just requiring the file and returning the function result immediately.

edit: By achieving this, there is just one thing missing to open up the way for the translator roles and that is making the inputs viewable but disabled.

[ryan]

I haven't tried this module with languages support, but thanks for letting me know that they are not compatible.

Getting the $languages array inside the PageEditFieldPermissionConfig function

You should be able to retrieve the $languages API variable via the wire() function, i.e. wire('languages') or wire()->languages are both valid syntax. $languages is a PageArray and can be iterated. 

Checking that the current field in the field traversal is actually a Language supporting one.

Multi-language field types implement FieldtypeLanguageInterface. If you wanted to find all multi-language fields in the system, you could do this:

foreach(wire('fields') as $field) {
  if($field->type instanceof FieldtypeLanguageInterface) {
    // this is a multi-language field
  }
}

Something else to mention about multi-language fields (all of which are text-based, currently) is that their value is actually an object of type LanguagePageFieldValue, rather than a string of text. Its __toString() value is reflective of the user's current language. When outputFormatting is on (as it is on the front-end), it is converted to a string automatically. But when outputFormatting is off (as it is in the admin) the value is a LanguagesPageFieldValue object. 

There is also another type of multi-language field known as a Multi-language alternate field.These are quite a bit simpler in that they are just a regular field with any fieldtype. But they are recognized as multi-language by name convention. If you have a field named "myfield" and another named "myfield_es", and you have a language installed named "es", then "myfield_es" is assumed to be the Spanish version of "myfield", while "myfield" is assumed to be the default language version. On the front-end (outputFormatting on) ProcessWire knows to substitute one for the other when the user's language matches the field name. 

Furthermore I'd like to ask Ryan, if there is a reason that the PageEditFieldPermissionConfig function is placed in its own file?

If there is a lot of code involved in configuration of an autoload module, then I prefer to put it in a separate file so that it's not taking up any memory for the non-admin requests that don't need it. 

[owzim]

Thanks Ryan what an excellent module.

What would also be great is that if you group fields within a field group that if that group is selected to be hidden from non superusers would also hide all field within that group.

[nikoka]

This is a great module, thanks Ryan!

I find myself in the peculiar situation where I need to limit access to the title field of a specific template, you mention on the module page that this is doable, would you mind giving some pointers on how this could be done with the help of this module?

Thanks! 

[ryan]

I find myself in the peculiar situation where I need to limit access to the title field of a specific template, you mention on the module page that this is doable, would you mind giving some pointers on how this could be done with the help of this module?

 

It's been awhile since I've used this module, but I think this could be accomplished by using another role. Keep in mind a user can have any number of roles (people often assume a user can have just one role). Take the role that you want to have limited access, and give it page-edit, but not page-edit-title permission. Assign to the appropriate template. Note however that the 'title' field may not be a good one to do this with, as the field is typically required for creation of any new page. So unless the role you are talking about doesn't need to create new pages with the given template, you  may run into trouble limiting access to the title field. 

[leoric]

hi,ryan

i found a issue after my test( PW 2.4)

when i unstalled the module i still could found permissions in this page(i could checked the checkbox and saved):

Access -> Roles -> Role Name -> edit

it's looks like no uninstall clean.at last i had to deleted them in this page:

Access -> Permissions

is this a bug?

[NikNak]

Hi Ryan

I have a series of fields that I wanted to only show to superusers. I used this module to set access to a fieldsetTab group and lo and behold - the tab and all its contents were hidden from other users.

However, as I added other tabs, this behaviour stopped working - I think some glitch had made it work originally.  

Might it be an idea to enable this behaviour - ie a protected fieldsetTab or fieldset also protects any fields it contains. 

Just a thought - it would make things cleaner in the admin interface.

This is obviously v v low priority. Thanks again Ryan.

Many thanks

Nik

[Gabe]

It seems that field permissions are not working on fields in repeaters.  I'm quite new to processwire, so I could be missing something, but I've been able to get field permissions to work as expected everywhere else.  Possibly a bug?

Thanks!

[horst]

@Gabe: Welcome to the forums.

I saw that you haven't got an answer until today. This is a shame

Unfortunately I don't know the Page Edit Field Permission module. But I want to welcome you. Hopefully someone with knowledge about that module read it soon and can answer this.

[ryan]

Hi Gabe, this module wont work with fields in repeaters because repeaters render their own fields. This module hooks into ProcessPageEdit, which isn't used by repeaters. However, if you need the capability one alternative would be to use PageTable rather than repeaters, as this module should be able to affect the output of PageTable (since it uses ProcessPageEdit). 

[Gabe]

@Horst - Thanks for the welcome.  The forums have been invaluable!

That makes sense Ryan.  I've just been playing with PageTables and I think I have somewhat of a grasp on them now.  I'll definitely give that a try.  Thanks!

[einsteinsboi]

I have just installed this module and I'm using it to restrict members of a site from being able to edit certain fields which are part of their user profile page (which is a page on the tree that only they have access to edit). However, I want them to still be able to see the fields, just not be able to edit them. Is this possible?