Jump to content

Field permissions issue when combined with visibility


alexcapes
 Share

Recommended Posts

Hi,

I'm utilizing the new field level access controls that arrived with 2.6.2 on a new site.

I've found however if I apply access controls to a field to 'view' that has visibilty set to a 'only show if' conditional statement, then the field does not display any content at all.

So my example is:

  • A translator role has only 'view' access to a field called 'content_type'  (note: both 'Access toggles' are ticked to allow viewing of field and API access)
  • There are different fields viewable based on the value of 'content_type' for example there's a image field accessible only if 'gallery' is selected as content type.
  • Even if 'gallery' is selected by superuser, the translator role cannot see or interact with the image field.

Am I missing something here - or is this a bug in the new access controls?

Link to comment
Share on other sites

No access setting on that field at all. The visibilty is set to 'content_type=4' (where '4' is 'gallery').

I tried explicity setting access to 'edit' for the translator role on the gallery field, however still does not show up for the translator (even though 'Gallery' is selected in the 'content_type' options field)

Link to comment
Share on other sites

When a field is only made viewable (whether by permissions or by the field's visibility setting), only its content is rendered in the document, not its form field. When it comes to visibility, field dependencies are a front-end/javascript task, so it needs that form field see what the value is. It doesn't work in your case because the field you are using for your dependency physically doesn't exist in the form (since it is not editable).

In order to support this dependency scenario, we may need to add an option to allow rendering of the <input> rather than just the contents, similar to what we do for language field permissions. The user would still be able to change it (and affect the dependencies that way, though only on the front-end), but any changes they make to non-editable fields wouldn't be saved. 

  • Like 1
Link to comment
Share on other sites

When a field is only made viewable (whether by permissions or by the field's visibility setting), only its content is rendered in the document, not its form field. When it comes to visibility, field dependencies are a front-end/javascript task, so it needs that form field see what the value is. It doesn't work in your case because the field you are using for your dependency physically doesn't exist in the form (since it is not editable).

In order to support this dependency scenario, we may need to add an option to allow rendering of the <input> rather than just the contents, similar to what we do for language field permissions. The user would still be able to change it (and affect the dependencies that way, though only on the front-end), but any changes they make to non-editable fields wouldn't be saved. 

Thanks for explanation of what's going on here Ryan.

I do think it would be very useful to have the option for allowing rendering of the input without changes having any effect and thus keeping the ability to control the visibilty of fields based on that field.

  • Like 1
Link to comment
Share on other sites

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...