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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

It's a tough one... Started a new branch 1541672

amitaibu’s picture

Status: Active » Needs work
jrao’s picture

Status: Needs work » Active

Is 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?

amitaibu’s picture

Exactly

amitaibu’s picture

I 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.

amitaibu’s picture

jrao’s picture

Yeah, 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).

amitaibu’s picture

> 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... :/

itamar’s picture

Status: Active » Needs review
FileSize
2.56 KB

Patch 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.

Status: Needs review » Needs work

The last submitted patch, og_node_access_fix-1541672-9.patch, failed testing.

amitaibu’s picture

itamar’s picture

Status: Needs work » Needs review
FileSize
5.21 KB

Adding a test to patch 9.

Tests should still fail since entityreference isn't patched yet.

Status: Needs review » Needs work

The last submitted patch, og_node_access_fix-1541672-12.patch, failed testing.

amitaibu’s picture

Status: Needs work » Needs review
FileSize
5.54 KB

#1555894: Store entity information in EntityReference_SelectionHandler was committed, let's check the patch with a slight change.

Status: Needs review » Needs work

The last submitted patch, 1541672-og-node-create-14.patch, failed testing.

amitaibu’s picture

Status: Needs work » Needs review

#14: 1541672-og-node-create-14.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1541672-og-node-create-14.patch, failed testing.

amitaibu’s picture

weird, all tests are passing locally for me

amitaibu’s picture

Status: Needs work » Fixed

Tests are passing locally, so committed.

aasarava’s picture

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

    $node = $this->entity;
    $node_type = $this->instance['bundle'];
    if(user_access('edit any ' . $node_type)) {
      $user_groups[] = $node->og_group_ref[$node->language][0]['target_id'];
    }

Thoughts?

amitaibu’s picture

> 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.

aasarava’s picture

The 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.

amitaibu’s picture

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.

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

aasarava’s picture

I'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?

amitaibu’s picture

Great.

> 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.

aasarava’s picture

Ok, further discussion about unrequiring the audience field for privileged users has moved here:
http://drupal.org/node/1580814

checker’s picture

Liliplanet’s picture

Status: Fixed » Needs work
amitaibu’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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