Can author create a field while not being allowed to edit the field?

It's most likely not working due to #965126: Better documentation on how to use Field Permissions

I have the very same problem (or rather, the same need to have fields which are automatically created but not editable by the author). It seems like it could be a very useful feature, think for example giving submitted content an internal code, or advancement status decided by admins.

subscribe

One way to achieve something like this (although it doesn't look like the most efficient way, for sure) is by setting up one extra role (with the attendant requirements of setting permissions all over again) and using the rules module to move the original author to this new role after creating the content. The rule that modifies the user role should be set up to get triggered upon submission of the newly created content. The new role for the author could be almost identical to the first role, with only the permission to edit certain fields (or entire content) removed, as needed.

hm, i'm not sure if i understood the problem completely:

I solve this kind of problem with a refereced node: User A edits a node with fields form a referenced node, that only User B can edit.

So i can show fieldvalues on a node a user can not edit.

This applies to:
version = "7.x-1.0-beta2"
core = "7.x"
project = "field_permissions"
datestamp = "1327510549"

IMHO, I think the problem is that the definitions of these two permissions are not precise enough:
#1) Edit own value for field X
#2) Edit anyone's value for field X

In #2, the word 'anyone' includes the author, therefore, it is impossible to give a user the permission to edit someone else's field ***without giving them the permission to edit their own field*** in their own content.

In other words: anyone means ***anyone*** including the current user.

Now, I have modified the definition like this:
#1) Edit own value for field X
#2) Edit anyone ***ELSE***'s value for field X

The old #2 permission (Edit anyone permission) is achieved by enabling the two new permissions.

To achieve this I modified the code in field_permissions.module as follows:

/**
 * Implementation of hook_field_access('edit').
 */
function _field_permissions_field_edit_access($field_name, $entity_type, $entity, $account) {
  ...
  ...
  ...

  // Check if user has access to edit this field in any entity.
  if (user_access('edit ' . $field_name, $account)) {
    // The user has <Edit anyone's value for field X> permission
    // We make sure the field is not actually owned by them to enforce the new rule:
    // <Edit anyone ***ELSE***'s value for field X>
     if (!_field_permissions_entity_is_owned_by_account($entity, $account)) {
       return true;
     }
  }
  
  // If the user has permission to edit entities that they own, return TRUE if
  // they own this entity or FALSE if they don't.
  if (user_access('edit own ' . $field_name, $account)) {
    return _field_permissions_entity_is_owned_by_account($entity, $account);
  }

  return FALSE;
}

This is briefly tested, so I will not claim robustness.

Please check this out, and tell me if this works for you...

This works for me.

D6 version is no longer supported.