What the patch does

I have a use case where I would rather the "group_content_access" field live on the group node, and not the content that is associated with that node. The patch included will check the related group to see if the field "group_content_access" is set to 'OG_CONTENT_ACCESS_PRIVATE'--- and if so mark the content as private. This check will only occur if the 'group_content_access' is not present or set to 'OG_CONTENT_ACCESS_DEFAULT' on the group content node, and if the 'group_access' field on the group node is set to public.

Use Case

I have a site where the privacy of the content within the group is paramount. We want the group itself to be discoverable publicly, and users be able to request access to join-- but not see any content until the moderators approve access. The security is such that we would rather the users, even administrators, never have the ability to make the content visible to the rest of the site--- under any circumstances. We did consider the work-around where we remove the field, and set the value ourselves in code--- but that seems unsustainable (especially if we want to make a group private after it was public for a time). Not to mention, I have to imagine I am not the only one who might have this use case.

What to confirm

The one last piece to this patch that should be checked by somebody who has a better knowledge of Organic Groups is to ensure there will not be wider security implications. I do not imagine there will be, as this will only be checked if all other security fields pass as "public", thereby not affecting any current implementations of the module. If needed, I can also take a stab at adding in a simpletest for this, although I am not as experienced with them-- so rather confirm this is something that can be added first.

Similar issues

While searching for information on this issue, I also fell upon a few other issues that are similar to this one.

#1429672: can group content inherit access from group node?
Similar, but for 7.x-1.x, and has a different use case. Rather not hijack (although might be able to close after this one is)

#1418106: TODO: Add a case where the group has access field but group content doesn't.
This set into motion the ability to do this, but instead of working off the "group_access" field, this will also include the "group_content_access" field.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

Status: Needs review » Closed (won't fix)

Adding the group content field on the group itself seems like it might cause confusion.
For your specific use case, you could hook_field_access() the group content access field, and make sure to set the default value to private.

Please re-open if you think I miss the point.

iamcarrico’s picture

Status: Closed (won't fix) » Needs review

Well, you can already add the group content field onto the group itself, and there is no clear indication that you should not do that. In fact, the language on that field doesn't make it clear either. The currently functionality of og allows for confusion on what this field is capable of doing. Since you can already add the field, I suggest we add the functionality that goes along with the field.

For your suggestion, hook_field_access() won't allow for the control administrators need. If an administrator decides to make a group's content "private", then each node will need to be changed individually--- instead of those nodes inheriting the access of the node.

The only ways around using the current group content field would require either (a) creating a new field that can be optionally added to the group to control the content-access, or (b) altering the current group privacy to have three choices (public, private, secret)--- where the "secret" would work like private does currently, and "private" would allow the group node to be seen--- but the content not to. Of course, such a change for either would take a drastic change in og behavior and would not be a good idea for the D7 version.

If you feel that this is still an invalid use-case--- feel free to close this again, I will not protest. But I do think it is confusing that you can add the group content access field, without it doing anything expected.

dsuguy’s picture

I'm with ChinggizKhan it makes sense and I've been searching for a week for a solution to do exactly that. I had decided to abandon OG and figure something else out until I ran across this patch. This would make OG so much more flexible and have the ability to work for everyone.

If the group is public and the content visibility field is set on the group then all the content inherits that.

I don't really see the point of having Groups where the content is public or EVERYTHING is private. Adding this ability, in my opinion, allows for the wider use case of a public group with the content always being private without the author of the content having to select that option or the administrator having to write an additional module with a hook to do it.

jojonaloha’s picture

I think this would conflict with a subgroups type use-case. I'm not actually using this on a project, but assume a setup like:

Parent Group

  • group_access = public: Group is visible to all users
  • Subgroup
    • group_content_access = private: Subgroup is only visible to members of Parent Group
    • group_access = public: In order for non-members of Subgroup to see the group.
    • Subgroup content
      • group_content_access = default: any member of Parent Group can see the content

Based on my understanding of the description of this issue, this would change the above scenario so that the group_content_access field on the Subgroup would mean that the Subgroup content would be private. It would also mean that the Subgroup would not be private to the Parent Group, but public.

I haven't tested any of this, but thought I'd put it out there as something to consider.

markdc’s picture

When I first started using OG, I had assumed that group_content_access was a field for the group contend node. I have such a use case for this — and it goes without saying — that an administrator would want to control content privacy of his group, and not leave that up to the authors, who may be the general public and know nothing about OG permissions.

Subscribing.