I have come across an interesting scenario and would be grateful for some advice.

I have a content type with fields that can be edited by multiple roles. One 'editor' role can create new content and edit all fields, but the basic 'authenticated users' role can only edit selected fields within existing content nodes, such as the description field. I have set permissions appropriately in CCK Field Permissions and the edit content forms only expose the appropriate fields for each role. So far, so good!

Now, when a basic 'authenticated user' edits an existing content node (one which has been previously created by someone in the 'editor' role) they only have access to the appropriate fields. When they submit their changes, all content in the other (protected) fields is wiped out. I can only assume this is because the fields were completely removed from the form before it was presented to them. This scenario can be even more disruptive if one of the protected fields is set as 'Required' - the standard authenticated user cannot submit the amendment successfully as (to Drupal) the necessary 'Required' fields have not been completed!

Has anyone experienced this behaviour in the past?

Now, the fields in question are not sensitive in nature, so one solution might be to provide a 'disable' flag - i.e. make the field read only (greyed out). Alternatively, simply changing the field type to 'hidden' might be a suitable solution. Any thoughts or suggestions?

Many thanks in advance!

Comments

arthurf’s picture

arthurf commented

This is an interesting case. I think that you're getting at a level of functionality this module was never intended for as it is largely a hack- it uses form alter to remove fields.

One way around this would be to transform the removed fields into hidden fields to not upset their values. However, for the enterprising person, they could find the values in the source of the page- a solution that many people would not like? I'm not sure.

I guess I'd like to hear from more people what ought to be done for this- I imagine this problem will start cropping up rather quickly without a real cck level approach to this.

john.money’s picture

john.money commented

I would think the optimal solution would preserve the current form behavior (e.g. removing the non-perm'ed fields from the form), but then at form post-processing, merge the new form data array into the old form data array. In this way, fields which were never presented would retain their old values.

Hiding and/or disabling fields is a bad security approach. Any enterprising user with certain Firefox plugins can alter the field display at will and overcome the permission restrictions.

yched’s picture

yched commented

As a side note : the proper way to hide form elements (node edit) or node fields (node display) is to use #access = FALSE on the relevant $form or $node->content element.
CCK Field perms's current way (brute force unset) should be avoided.

arthurf’s picture

arthurf commented
Status: Active » Fixed

This is fixed in the 1.9 release

yched’s picture

yched commented

but my suggestion in #3 still stands :-)

arthurf’s picture

arthurf commented

Woops, i committed the wrong version. 1-10 should fix it.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
spazfox’s picture

spazfox
Location Olympia, WA
commented
Version: 5.x-1.8 » 5.x-1.10
Status: Closed (fixed) » Active

I don't think this is fixed, as I'm using 1.10 and having what seems to be the same issue: http://drupal.org/node/179515

btully’s picture

btully commented
Category: support » bug
Priority: Normal » Critical

This is definitely not fixed. We are having the same issue whereby fields that a user does not have edit permission for are not included in the form and when submitted those values get wiped out.

The fields in question are user reference field types, which is a select menu of user roles. If a node has a value for this field assigned, and a user who does not have edit permission for this field edits the node and submits it, this field value gets unset.

Can the author please verify and confirm that this is not the desired result?

Vidarls’s picture

Vidarls commented
Status: Active » Closed (duplicate)

duplicate with suggested solution: http://drupal.org/node/118513