When I grant "Create" permission to a role for a comment field, the role can not create the field. "edit own" also is not enough. but when I grant “Edit any” permission to the role, then it can create the field.

Members fund testing for the Drupal project. Drupal Association Learn more


RobLoach’s picture

Status: Active » Postponed (maintainer needs more info)

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

Golem07’s picture

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.

Anonymous’s picture

Status: Postponed (maintainer needs more info) » Active
10.44 KB

I bumped into the same issue today when creating an extra comment field for attachments: The users with all permissions for that field except the "edit any"-permission cannot create it. As a consequence these users cannot see the field either.

I added an attachment to show the permissions for the field that shows this issue.

Anonymous’s picture

Fixed it in field_access.inc. Field permissions presumed the fields are from a node. Therefor the node should not yet exist. In the case of comments the node already exists. Therefor I added an extra conditional parameter.

Adapt the function in field_access.inc at line 60 to:

 * Implementation of hook_field_access('edit').
function _field_permissions_field_edit_access($field_name, $field_permissions, $obj_type, $object, $account) {
  // Check if user has access to edit this field on object creation.
  if (($obj_type == 'comment' || empty($object->nid)) && !empty($field_permissions['create'])) {
    return user_access('create '. $field_name, $account);

  // Check if user has access to edit this field in any object.
  if (!empty($field_permissions['edit']) && user_access('edit '. $field_name, $account)) {
    return TRUE;

  // If 'edit own' permission has been enabled for this field, then we can
  // check if the user has the right permission, and ownership of the object.
  if (!empty($field_permissions['edit own']) && user_access('edit own '. $field_name, $account) && $object->uid == $account->uid) {
    return TRUE;

  return FALSE;
Anonymous’s picture

Status: Active » Needs review

Anyone would like to check the code above please?



Anonymous’s picture

1 month bump. Anyone would like to review the code above please?



SebCorbin’s picture

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

SebCorbin’s picture

Status: Needs review » Patch (to be ported)
796 bytes

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

Anonymous’s picture

SebCorbin, ahh good point :) I thought in terms of nodes, not entities. Thanks for your help!

Golem07’s picture

@thomastorfs and SebCorbin:

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

RobLoach’s picture

Status: Patch (to be ported) » Needs review

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

David_Rothstein’s picture

Title: It is necessary to grant “Edit any” permission to a user to be able to create a comment field » The "create" permission does not work for fields that are attached to any entity other than nodes
Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

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.

David_Rothstein’s picture

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

RobLoach’s picture

Status: Reviewed & tested by the community » Fixed

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

RobLoach’s picture

Priority: Critical » Normal
Status: Fixed » Needs review
712 bytes

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

David_Rothstein’s picture

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 :)

RobLoach’s picture

Status: Needs review » 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!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

David_Rothstein’s picture

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.

David_Rothstein’s picture

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!

Azol’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Closed (fixed) » Patch (to be ported)

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:


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.

  • RobLoach committed 167a3aa on 8.x-1.x
    #876550 by SebCorbin, David_Rothstein | abbasmousavi: Fix for objects...
  • RobLoach committed da0609d on 8.x-1.x
    Issue #876550 by Rob Loach: Ignore the Drupal core thrown exception with...
mariacha1’s picture

Issue summary: View changes
Status: Patch (to be ported) » Closed (won't fix)

D6 version is no longer supported.

David_Rothstein’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Closed (won't fix) » Closed (fixed)

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