Hi,

I have an installation with Wysiwyg, CK Editor 4 and among other modules Field Permissions 7.x-1.0-beta2 (although I do not think field permissions is the cause for the problem).

Two roles:
- admin: may use full html format
- editor: may use extended html format (basically a slightly more restricted format)

If I create content as admin I automatically get the most open input format that this role can use, in my case full html. Admin saves content in a field (the field has no permission settings from field permissions) and the format is stored under _format in the field table.

If an editor now edits the node, any field that is stored with a format higher than what he has access to will be disabled and will read "This field has been disabled because you do not have sufficient permissions to edit it.".

I don't think this is the intended behaviour as it blocks any lower level role from editing fields although the permissions (apart from editor permissions) should grant them access. I believe the intended behaviour should be to allow access to the field, but apply the different filters... This might remove additional markup that for example the full editor allows (such as certain html tags), but still give access.

Or is this intended?

Thanks, J.

Comments

twod’s picture

twod
Primary language Swedish
Location Sweden
commented
Status: Active » Closed (works as designed)

This is indeed the intended behavior as of Drupal 7, and it's done by Core without Wysiwyg having a say in the matter. Drupal 6 (CCK) would simply block access to the entire node if a user did not have permissions to edit a field.

If a user does not have permission to use the format used to save content with, they do not automatically have permission to alter that content since that would require them to [temporary?] have permission to use that format, which could be a major security problem, or -as you already suggested - the content gets automatically altered to work with the new format.

It is however impossible to automatically and correctly apply a different format to content when editing since there is no way to tell how different formats actually treat the content once rendered, what parts of the contents are sensitive and should not be exposed to anyone with less privileges, or even what "less" privileges means.

Content is always stored exactly as the user entered it into the database, Drupal Core never messes with that. It needs to have the original input in order to be able to correctly show unaltered contents to the user when editing, and re-apply filters when re-rendering contents. If the format associated with a piece of content was allowed to be changed by anyone without explicit permissions to use it, the unfiltered contents could expose intimate details only needed before rendering something.

The clientside editors do not have a say in this and don't know anything more about a format [or its filters] than its internal name.

Issues related to this have recently been brought up during the development of Drupal 8, which will have a better framework for dealing with clientside editors, as well as a "categorization" of filters applied to contents. This is needed since Drupal 8 will allow for "inline-editing" of contents (no need to go to an Edit tab, just click on a paragraph to edit it). To facilitate inline-editing - which is basically done by turning on an element's contentEditable attribute to get access to the raw [rendered] HTML - Drupal 8 has information on whether the effects of a content filter is "reversible" or not. That will still not allow one to switch between formats automatically, since different formats may have completely different use cases, but it does allow for better control of whether contents need to be re-rendered into an "editable" version for inline-editing. Just a heads-up in case you see this discussed somewhere in the D8 queues.

jelo’s picture

jelo commented

Thanks for extensive explanation TwoD. I think I was confused because somewhere in the settings I was asked to specify the order of text formats and which role gets which format by default. Unfortunately, I am unable to locate that setting right now. It was something like role IDs: 5 > 4> 2 > 1.

That setting kind of suggested to me that there is some kind of fall back from highest allowed to lowest allowed. My assumption then was that it will downgrade like this. But what you describe makes sense. I am not sure how many other admins ran into this issue unprepared and at that setting it might be helpful to specify that users with lower level input formats will not be able to edit fields of higher level input formats.

Cheers, J.