Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#15 | fieldwarning.patch | 712 bytes | RobLoach |
#13 | field_permissions_876550_13.patch | 697 bytes | David_Rothstein |
#8 | field_permissions_876550.patch | 796 bytes | SebCorbin |
#3 | field_permissions_create_bug.png | 10.44 KB | Anonymous (not verified) |
Comments
Comment #1
RobLoachCan you provide exact steps to reproduce this? I'm having troubles running into this...
Comment #2
Golem07 CreditAttribution: Golem07 commentedI 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.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedFixed 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:
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedAnyone would like to check the code above please?
thanks,
Thomas
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commented1 month bump. Anyone would like to review the code above please?
thanks,
Thomas
Comment #7
SebCorbin CreditAttribution: SebCorbin commentedI have the same problem, i'll test and provide patch if this is working.
Comment #8
SebCorbin CreditAttribution: SebCorbin commentedNo 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
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedSebCorbin, ahh good point :) I thought in terms of nodes, not entities. Thanks for your help!
Comment #10
Golem07 CreditAttribution: Golem07 commented@thomastorfs and SebCorbin:
Thanks to both of you. I have applied the patch provided above and the problems seems to be solved.
Comment #11
RobLoachThe patch looks really good, is it ready to be committed?
Comment #12
David_Rothstein CreditAttribution: David_Rothstein commentedBetter 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:
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.
Comment #13
David_Rothstein CreditAttribution: David_Rothstein commentedThe above patch no longer applies to the latest 7.x-1.x code. Attached is a rerolled version that does.
Comment #14
RobLoachThanks a lot! http://drupalcode.org/project/field_permissions.git/commit/167a3aa .... Editing works with objects other than nodes now.
Comment #15
RobLoachWe'd probably need Entity API if we want the better API to check if it's a new object.
Comment #16
David_Rothstein CreditAttribution: David_Rothstein commentedThat 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 :)
Comment #17
RobLoachYou'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!
Comment #19
David_Rothstein CreditAttribution: David_Rothstein commentedLooks 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.
Comment #20
David_Rothstein CreditAttribution: David_Rothstein commentedOops. 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!
Comment #21
Azol CreditAttribution: Azol commentedAny 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
At least it works for me at the moment, but I hope for some permanent solution "non-hack" way.
Comment #23
mariacha1 CreditAttribution: mariacha1 at ThinkShout commentedD6 version is no longer supported.
Comment #24
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedFor posterity, let's put this issue back to the version it was actually fixed in.