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.
Since we don't get the entity the field is attached to, we can't check if the group exists there. A possible solution would be to move the access check to form-alter() or figure out how to get the entity field is attached to.
Comment | File | Size | Author |
---|---|---|---|
#14 | 1541672-og-node-create-14.patch | 5.54 KB | amitaibu |
#12 | og_node_access_fix-1541672-12.patch | 5.21 KB | itamar |
#9 | og_node_access_fix-1541672-9.patch | 2.56 KB | itamar |
Comments
Comment #1
amitaibuIt's a tough one... Started a new branch
1541672
Comment #2
amitaibuComment #3
jrao CreditAttribution: jrao commentedIs this for the case where a group member only has update group content permission, and when he goes to edit the group content, the group disappears from primary field since he doesn't have create group content permission?
Comment #4
amitaibuExactly
Comment #5
amitaibuI don't see a simple solution for this. I'm going to look into core -- hook_options_list() should optionally get the entity the field is attached to.
Comment #6
amitaibu#1541792: Enable dynamic allowed list values function with additional context
Comment #7
jrao CreditAttribution: jrao commentedYeah, I encountered this when creating the test case, it's counter-intuitive but I guess whether it's a bug would depend on how you define the update group content permission (i.e. if it covers the case where user removes the content from this group).
Comment #8
amitaibu> it's counter-intuitive but I guess whether it's a bug would depend on how you define the update group content permission (i.e. if it covers the case where user removes the content from this group)
I agree. One can argue that we need another permission just for that. But anyway, let's hope a fix in core will be possible... :/
Comment #9
itamar CreditAttribution: itamar commentedPatch allows users with either "edit all content" or "edit own content" permission to a group to see it in the group list when editing group content.
Comment #11
amitaibuIt fails because er still isn't patched -- #1555894: Store entity information in EntityReference_SelectionHandler
Comment #12
itamar CreditAttribution: itamar commentedAdding a test to patch 9.
Tests should still fail since entityreference isn't patched yet.
Comment #14
amitaibu#1555894: Store entity information in EntityReference_SelectionHandler was committed, let's check the patch with a slight change.
Comment #16
amitaibu#14: 1541672-og-node-create-14.patch queued for re-testing.
Comment #18
amitaibuweird, all tests are passing locally for me
Comment #19
amitaibuTests are passing locally, so committed.
Comment #20
aasarava CreditAttribution: aasarava commentedWhile the patch handles the use case of a group member needing to edit group content, there's still the use case of a site admin/editor needing to edit content without being a member. It seems to me that the buildEntityFieldQuery function could be modified so that in the case of users with "edit any {node_type}" at the global level (not group level), you load a larger set of groups that the user is allowed to assign the current content type to.
At the least, you could add the current node's group back into the list, with something like the following, inserted just under the call to og_get_groups_by_user on line 168:
Thoughts?
Comment #21
amitaibu> there's still the use case of a site admin/editor needing to edit content without being a member
For that you have the "Other groups" field.
Comment #22
aasarava CreditAttribution: aasarava commentedThe problem with the "Other Groups" field method is that your primary Groups Audience field must be optional. If you have a site setup where your group content has a required+single Groups Audience field, using the Other Groups field will cause an error to be thrown.
This happens because, when you edit content in a group that you're not a member of, the required+single field will cause the first group in your list to get selected automatically. So when you submit the form, you're submitting both a value for the Groups Audience field and a value for the Other Groups field -- but OG can't push a group into the Groups Audience field because it only allows a single value.
Is there some other way to use the Other Group field that I'm overlooking? Otherwise, it seems like you really can't have a single+required Groups Audience field on group content at all.
Comment #23
amitaibuI believe a nice feature would be to un-requie the group-audience field for privileged users (i.e. adding a setting in the field settings page, somehting like -- "Unrequire field for user that can edit secondary fields).
@aasarava, care to roll a patch? :)
Comment #24
aasarava CreditAttribution: aasarava commentedI'm not very familiar with the Fields API in D7, but I can try. I see the place in OgSelectionHandler where I can add a settings field. But what's the best file & hook to use to alter the actual primary field so that it's not required?
Comment #25
amitaibuGreat.
> hook to use to alter the actual primary field so that it's not required
probably hook_field_attach_form(). However, please open a separate issue for this.
Comment #26
aasarava CreditAttribution: aasarava commentedOk, further discussion about unrequiring the audience field for privileged users has moved here:
http://drupal.org/node/1580814
Comment #27
checker CreditAttribution: checker commentedComment #28
Liliplanet CreditAttribution: Liliplanet commentedComment #29
amitaibu