The "create" permission does not work for fields that are attached to any entity other than nodes

Can you provide exact steps to reproduce this? I'm having troubles running into this...

I am having the same issue:

In Forums to attach a file to the post I use the very same field field for the node an the comments. However, users cannot use (or see) the file field in comments unless I grant them the "edit any" permission. Those users do not have any trouble accessing the file field during node creation.

I have the same problem, i'll test and provide patch if this is working.

No sorry, in fact that wasn't my problem :/

But I want to help you anyway : doing a test on comment is not enough, it won't work on taxonomy terms for example, you have to do this for every entity type, here's a working patch, i've tested it on node and comment

@thomastorfs and SebCorbin:

Thanks to both of you. I have applied the patch provided above and the problems seems to be solved.

The patch looks really good, is it ready to be committed?

Better title - this is definitely a critical bug.

I reviewed and tested the patch and it works perfectly. Nice use of entity_extract_ids().

I did notice that with this patch, you get PHP notices like this when visiting the field config screen:

Notice: Undefined index: entity keys in entity_extract_ids() (line 7387 of /home/droth/web/drupal/includes/common.inc)

However, that's a side effect of the patch, but not the fault of the patch; it's actually a core bug (#1301522: field_ui_default_value_widget() does not pass along the entity type when it creates the default value form) so I don't think we need to worry about it here.

The above patch no longer applies to the latest 7.x-1.x code. Attached is a rerolled version that does.

Thanks a lot! http://drupalcode.org/project/field_permissions.git/commit/167a3aa .... Editing works with objects other than nodes now.

We'd probably need Entity API if we want the better API to check if it's a new object.

That mostly looks like a good improvement. I don't know if the "@" is worth it, though. Probably better to just get the core bug fixed :)

You're right... Don't like having exceptions thrown when we know it's a core bug though. Let's ignore the bug, but put a @TODO comment in there with a link to the bug itself. http://drupalcode.org/project/field_permissions.git/commitdiff/da0609d .... Thanks David!

Looks like this caused some problems (actual exceptions, not just PHP notices) when combined with other modules: #1321050: "Create" permissions don't work correctly sometimes, and "EntityMalformedException: Missing bundle property" errors can appear.

Oops. It turns out the change from empty() to !isset() in the followup commit (#15) caused this issue to regress. Create permissions are still not working for user fields.

I wrote a patch to fix this (with some tests for user fields; we didn't have any before) in the issue linked to above. It's easy to fix the user fields problem and the EntityMalformedException issue at the same time since both were caused by this one and both are in the exact same part of the code.

Anyone who is interested, please follow up at #1321050: "Create" permissions don't work correctly sometimes, and "EntityMalformedException: Missing bundle property" errors can appear - thanks!

Any chance to port this patch to 6.x branch? I stumbled across exactly the same issue with Field Permissions + VBO + Views, unable to change fields with VBO action without Create permission.
The problem is, VBO+Views do not set $node->nid value, so there is no way you can guess if actual node already exists or not.
So at the moment _field_permissions_field_edit_access() is called, you have something like this:

$node->type=>
$node->field_some_custom_name=>

both values uninitialized.
I filed the issie in VBO queue (#1574410: VBO conflicts with Field Permissions) because I believe it's the VBO failure to provide $node object with more correct information. I posted the manual "hack" for VBO that adds $node->'is_new' => FALSE so we can use it later to decide if the node exists or not.

The way I hacked Field Permissions is this (and I needed this fix urgently):
file field_access.inc

function _field_permissions_field_edit_access($field_name, $field_permissions, $account, $node) {
  // Check if user has access to edit this field on node creation.
  if (empty($node->nid) && ($node->is_new || !isset($node->is_new)) && !empty($field_permissions['create'])) {
    return user_access('create '. $field_name, $account);
  }

At least it works for me at the moment, but I hope for some permanent solution "non-hack" way.

D6 version is no longer supported.

For posterity, let's put this issue back to the version it was actually fixed in.