I think there's a bug with the "create" permission. If it is unchecked on the CCK field settings page, and "edit own" permission is checked, then I expect that the user can create the field as inherited by being able to create the node. But that is not the case. Steps to reproduce:

  • Install brand new Drupal with only CCK and Field Permissions modules.
  • Create new content type called "membership" and add text field called "Organization Name". Don't check any of the "field permissions" checkboxes.
  • Grant "create membership content" permission to authenticated users.
  • Create a test user, login, and visit the Membership node form. You will see the Organization Name field. (Here, it appears that the "create" permission is inherited properly.)
  • As administrator, go back to the Organization Name field settings, and select "Edit own Organization Name on node created by the user." Save.
  • As newly created user, revisit the "Create Membership" node form, and you will not see the Organization Name field.

Shouldn't that field appear here? Yes, on the Organization Name field settings page, if I select "Create Organization Name (edit on node creation)" and then grant authenticated users that permission, it does appear. But I thought that leaving it unchecked would cause the permission to be inherited by the node access?

Comments

Status:Active» Closed (works as designed)

I think there might still be use cases where you do not wish to inherit "create field" when "edit own field" is granted. Say you may need to allow a user to create nodes, but lock access to create certain fields while allowing them to edit those fields later. Maybe the user can "edit own node" only after other rules match.

In your scenario above, you should grant both "create field" and "edit own field". But others may still need to treat them separately.

Status:Closed (works as designed)» Active

I see your point, and thanks to this module, both use cases are easily accommodated. However, I'm speaking about the default, expected behavior, as indicated by the form instructions.

Use these options to enable role based permissions for this field. When permissions are enabled, access to this field is denied by default and explicit permissions should be granted to the proper user roles from the permissions administration page. On the other hand, when these options are disabled, field permissions are inherited from node view and/or edit permissions. In example, users allowed to view a particular node will also be able to view this field, and so on.

If an authenticated user has access to create a "membership", then, unless specifically overridden, the "create" permission should be inherited. What happens now is opposite of what the instructions suggest.

I'm setting this back to active, since, at the very least, there is a discrepancy between what the form instructions say and what actually happens.

thanks markus!

I agree with joelstein that the instructions are a bit misleading - and it would be nice if you were able to inherit defaults for different types of powers unless specifically differentiated for a specific field.

In my case I have a content type Organization. "Staff" have default power to edit any field, regardless of author. I need to give "Member" power to edit certain "own fields" but not others. So for those fields, I check permission for "edit own field".

I originally assumed that since I hadn't checked "edit regardless of author" that the "Staff" edit powers would be inherited for those fields. But it seems that this is not so and I will need to re-do the field permissions for each of these fields and update permissions for Staff role.

However, overall the module is easy to use and much appreciated!

OK - this had me stumped for a while. Glad I found this issue. I found it counterintuitive that selecting only "Edit own node type.." doesn't allow users to access that field on node creation.

So just to detail the configuration necessary for this module to work in my use case - ie. User should be able to access field A on node creation. On future editing of that node the user should not see field A.

Steps to configure:

  1. Edit content type field settings for Field A and select the Field Permission checkboxes:
  • Create...
  • Edit own...
  • go to admin/user/permissions to the section field_permissions module:
    • add Create permission for Field A for required user roles
    • do not add Edit permission for Field A

    Everything then works exactly as I require.
    Very useful module btw - thanks!