cck perms prevents field defaults from being written

I'm a little unclear on the "create <field>" permission. It doesn't seem right that in a structured db (as opposed to a freeform db) that some fields would not be created. And a field with default values should, as Peter points out, be created with a new node even if the user doesn't have edit permissions.

Bug or no, it gets to be a bit more complicated in doing the form handling. I think that in this kind of case, the way to solve it would be to convert the form element to hidden and allow the data to get submitted.

subscribing.
I had already written a similar issue for drupal 5 at the cck project, see http://drupal.org/node/130423.
No response there either, is here anybody doing something to fix this?

Subscribing. I'd like to be able to lock default field values for certain roles (like "currently logged in user" for example).

Been looking at the code a bit and have an idea, but didn't actually code anything:

What if, instead of setting #access to false for fields the user must not edit we convert them to a hidden field?

$field['#type'] = 'hidden';
$field['#value'] = $field['#default_value'];

should do the trick to preserve the default values, no?

of course for all properties of a field if there's more than one ...

PS: I've only been looking at the drupal-5 branch, so can't talk for the 4.7 version

Is there any update on when this issue will be resolved? I really need to be able to keep the defaults on a field that users can't change (it's a Viewfield, see here), and I don't have much time left to find a solution. If anyone has a quick and dirty hack that they used to solve this problem, please share it!

I'm having exactly the same issue. I have content that should always show the same view (with %nid as an argument) and users shouldnt be able to adjust that. Unfortunately default values dont get saved if the field isnt visible.

I think the general concensus for now is to change the field type to hidden. This is problematic because we're now giving (*smart*) users the ability to see (and possibly manipulate) values that are supposed to never be seen. What they can/will/could do with them remains to be seen. That being said, I'll just post my changes for people to hack in, rather than posting a patch per-se.

I solved this by adding the following function to cck_field_perms.module

function _cfp_disable_nested_elements(&$form){
    foreach ((array)$form as $name=>$item){
        if(isset($form[$name]['#type']))
        {
            $form[$name]['#type']='hidden';
            if(is_array($item['#default_value']))
                $form[$name]['#value'] = $item['#default_value'][0];
            else
                $form[$name]['#value'] = $item['#default_value'];
        }
        elseif (is_array($form)){
            _cfp_disable_nested_elements($form[$name]);
        }
    }
}

Then i made the following change(somwhere around line 145)

if($disallowed[$name]){
   if (!(user_access(_cfp_content_to_readable($type, $name, $verb)))){
//     unset($form[$name]);
     _cfp_disable_nested_elements($form[$name]);
        }
      }

The long & short of what this does is it uses the existing code to identify the element that shouldnt be shown. Then, instead of unseting it to get rid of the field(s), it recurses through that portion of the form to find any fields that exist in that scope (viewfield has 2 for example), which it then sets to type:hidden. Then values are populated with the default value (element 0 if the defaults are an array).

Hope this helps!
-Chris

o & ps: if this happens to get taken into account in a release, can someone let me know!? Thanks!!

1. smart users can't outsmart us by changing the values of hidden fields, the drupal form api doesn't allow that
2. there is another low-level widget type in the forms api: 'value' - maybe a better choice for what we want here

You may want to look at this patch: http://drupal.org/node/186914#comment-659964

Subscribing, I really need this too.

I'm not quite sure how I feel about default values not being written if you don't have access to the field.
But I do have a workaround:
- If you use the computed_field module (that does not have a field) you can program it to give itself a default value if $field['foo' ] (accesscontrolled) is not set. An if $field['foo'] is set the computed field can just copy the value to itself.

I think that controlling access to edit / create a certain field is best done with a new widget for that field.
The attached module is a rough module with no flexibility that checks if a user has the correct permission to create and edit a field.
It works at the form-API level: If the user does not have the permission, the field is never even rendered and thus it can not overwrite previously saved data.

I suppose a better way to do it would be to change the element type to 'value' instead to keep default values.

The modular approach of CCK makes this approach quite attractive, but I have not yet looked into a way of integrating it with the configure field form. It should be possible though.

I put some more thought and effort into this and I came up with the following:

I changed

if (! user_access(_cfp_content_to_readable($type, $disallowed_field, $verb))) { 
  $form[$disallowed_field]['#access'] = false; 
}

to

if (! user_access(_cfp_content_to_readable($type, $disallowed_field, $verb))) { 
  $form[$disallowed_field]['#type'] = 'value';          
}

This way the field itself is hidden, but any value is preserved.

I've attaced the edited .module. If someone could be bothered to do some testing It would be very much appreciated

I managed to get round this problem by defining a workflow-ng action on "Content has been created", with a condition that "Content has type" of the CCK content type involved and custom PHP code to set the value, e.g. I wanted to pass a value through via the URL in the third argument

$stuff_value=arg(3);
$node->field_stuff[0][value] = $stuff_value;
return array('node' => $node);

Now, whether one considers the fact that workflow-ng ignores the CCK field perms as a bug or a feature is a different question and I guess that behaviour might change in the future, but it solved my immediate problem and might help you too...

i did this with jquery, maybe it helps you, too.

drupal_add_js('
 $(document).ready(function() {
$(\'#ID_OF_INPUTFIELD\').attr("disabled", true);
})
','inline');

greetings

Andreas B.

Vidar, I have successffuly tested your fix with a node reference CCK field. (http://drupal.org/node/118513#comment-735843)
=> It works if using the 'autocomplete Text Field' widget, but _not_ for the 'Select List' widget.

The use case I tested is: the user has no rights on this field (neither edit, nor view), and edits the node. The field must stay unchanged (for information, it was auto-initialized at node creation and only an admin can see and update it afterwards).

I tried few updates to make it work using the 'Select list' widget, but without any success, and I can live with the 'autocomplete text field' so I did not insist...

For information, here is the error message I get when the widget is 'Select list', and when trying to submit the node changes (the submit fails):
[name of the 'hidden' field] : This post can't be referenced.

Could this be because a select list item can only have the values in the #options array, and when a field is changed into #type = 'value' the #options array is discarded?

This solution worked for me as well. Thanks!

Subscribing...
Looking for clean solution.

subscribing...but in the meantime, i went with the workflow-ng workaround. :)

+1 to fixing the defaults bug

subscribing

Vidar, your Sollution from post # 17 doesn't work work for me with date field.

No, you can't take an issue created for a totally different project *and* a totally different version of Drupal and move it here. We did *not* integrate the D5 CCK Field Permissions code, we added a new, totally different, permissions module. There is absolutely none of the D5 CCK Field Permissions code in CCK. None.

If you have an issue about something you're seeing in the CCK D6 permissions module, create a new issue about how *that* is behaving. An issue with examples from completely different code is totally confusing to everyone involved.

Note: as a request for CCK, this is a duplicate of #334945: Save default value when user has no permission to edit the field