I want group members to post to a group but to not have a control over the visibility of the post. By default the post should be private, but this can be over-ridden by the group admin.

If I do not use the "Group content visibility" field all posts are public, even if the group is private.

I've tried setting the default for "Group content visibility" to be private, and updated the permissions so that a member cannot update or view the field (but the group admin can). However the field still appears on the content creation page! Is this "works as designed" (if so why), or is this a bug?

When a member then edits the content the "Group content visibility" field is no longer visible.

I also have the og_create_perms enabled - I wonder if this is over-riding something.

Comments

amitaibu’s picture

Category: bug » support
Status: Active » Fixed

This is not a bug -- OG doesn't deal with permissions on content before it's creation. This is a feature request for og_create_perms.

Matt B’s picture

Thanks Amitaibu

Status: Fixed » Closed (fixed)

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

karl qin’s picture

Status: Needs review » Closed (fixed)

there is a //TODO: Add a case where the group has access field but group content doesn't.
in og_access.module on line 149
we can do this via edit og_access.module
change line 78

  elseif (isset($node->{OG_CONTENT_ACCESS_FIELD}[LANGUAGE_NONE][0]['value'])) {
    switch ($node->{OG_CONTENT_ACCESS_FIELD}[LANGUAGE_NONE][0]['value']) {

to

  else {
    $og_content_access_field = isset($node->{OG_CONTENT_ACCESS_FIELD}[LANGUAGE_NONE][0]['value'])?$node->{OG_CONTENT_ACCESS_FIELD}[LANGUAGE_NONE][0]['value']:OG_CONTENT_ACCESS_DEFAULT;
    switch ($og_content_access_field) {

karl qin’s picture

Status: Closed (fixed) » Needs review
amitaibu’s picture

Status: Closed (fixed) » Active

No patch attached

Honestly Illustrated’s picture

Component: og.module » og_access.module
Category: support » bug

A possible solution to the original question is to create a content type providing a default value for group content visibility, but not offering a form entry method with which to change it.

#4 here is no longer valid. og_access.module is significantly different in that area of the code.

However, I'm looking at a similar, different but possibly related, scenario today and Google led me here.

In a public group with group content visibility set to private, that default is not being respected at all. I've produced this with Article content type carrying its own visibility field set to "group default", and with Book content type without the visibility field attached to that content type. Both result in same behavior: the content is published publicly regardless of the group itself having its content visibility set to private.

The only recourse I currently have is to try forcing the field to be set to private by default on the content type itself; possibly creating a special content type as mentioned above.

I'm marking this as a bug since my related case seems unintended, the subject line defines it well, and the thread thus far may be useful.

Matt B’s picture

Category: bug » support

In the end I found that Taxonomy Access Control fitted my use case better than Organic Groups. I created a Vocabulary called 'visibility', with terms Private, Group1, Group2, etc. TAC then let me set permissions on which role could view content marked with each term, and which role could set which term. None of this is intended to say TAC is better than OG (or vice versa) - they are both fantastic modules that some amazing people have put time and effort into developing - it comes down to what fits your needs better!

This is not a bug with OG (see #1), so changed back to a support request.

Honestly Illustrated’s picture

Category: support » feature

Correct me if I'm wrong on any of this. I'm assessing it by behavior, without looking at much code.

I looked further and found why I think some of might misunderstand what happens. The description of the Group content visibility field: "Determine access to the group content, which may override the group settings." Without careful reading, we may not notice that this says that the field applies to content, not groups containing content. The "group settings" this refers to is the Group visibility field, "Determine access to the group."

So we give this Group content visibility field directly to a group node, mistakenly believing that it has an effect upon the content joined as members to that group... it does not. It affects the group node itself and nothing else. Only that same field, given to each individual node within the group, can affect the individual nodes within that group. It's granular to each member node, and not holistic to the whole group.

The code may not even be looking for this field to be on a group node. Now, if the group node were a member of some other group, then that field might have some affect on the group node. In that case it would apply the parent group's membership to the decision, not the child group's membership.

Maybe it's a bit ambiguous to say in #1 here, "permissions on content before it's creation", and leave it at that... but I see what that means, now. It carries an assumption that we understand what I've just described.

What I wanted from this exercise is in the same scope as Matt's original request. At the time, April 2011, og_create_perms was fresh and actively developed: possibly a good fit for the request. That project hasn't seen a release since 1.0 in Feb 2011, and I think it's two key features deserve to be rolled into OG if one of us finds time to do so. This seems quite in-line with Commons, Atrium, and generally using OG as intended.

Also, my mistake about group content visibility field points to a needed field to set globally the content visibility of an entire group's member content, while still allowing the group node itself to remain public. This gives an accessible public-facing hint, a teaser if you like, for the existence of the group.

bsarchive’s picture

Honestly Illustrated is right:
- 'Determine access to the group content, which may override the group settings' is misleading in the extreme!
- We need a field to control visibility of content posted to the group, ideally which will take immediate effect when changed, instead of requiring the content to be resaved

Finally, when the Group content visibility field is applied to a group content node (rather than a group node), what does 'Use group defaults' refer to? If I have a Group node type and a Group post node type, setting the 'Group content visibility' field to:
- 'Private' means only group members can see the post
- 'Public' means anyone can see the post
- 'Use group defaults' presumably inherits the value from the 'Group visibility' field. I think this is misleading too because group content visibility is again inheriting group visibility, which is quite a separate thing.

Additionally, if there were a new 'group content visibility' field for a group, what would happen if a content node were posted to two groups, where one group was set for private content and the other was set for public content?

bsarchive’s picture

Issue summary: View changes

Anyone?

sazevedo@ua.pt’s picture

Hi, I'm having the same problem.
I use book as the group, and I've set group visibility to private. A non-member can see the list of the subpages of the book.

I've tried to set content visibility to private in the group, but is the same. Or in the subpages, nothing seems to remove the subpages from being view by non-members.

brad.bulger’s picture

Yes, in OG 7.x-2.7, the Group content visibility field has apparently no effect on anything. Adding it to a content node in a group and setting it to Private does not hide the content from non-members. Adding it to the group node and setting it to Private does nothing.

imfaber’s picture

Do you have og_field_access enabled?
I wasn't sure what this module did until I tried to enable it and my group content started behaving correctly.

Sorry I was wrong.
It's not working as expected

jaesperanza’s picture

Indeed, setting the group content visibility to private does not seem to take effect. In my case, I have users belonging to Hotel 1, Hotel 2, and so on. We expect only users (assigned respectively to OG groups as OG members) to view only its own group content (hotel guests listing), and other similar viewing privacy settings - i.e users members of Hotel 1 Group can only view and manage its own Guests (a content type).

What worked for me though, was the additional use of the privacy settings provided by the Content Access module https://www.drupal.org/project/content_access. I've edited my Guest content type > Access Control tab > and set the View, Edit, Delete to the users' own content only. Also, while on the same page, before saving settings, under the "Advanced" setting, I've set the "Give content node grants priority" to its highest value (-10). Saved. Viola! Seems to work! I guess I just tested OG and Content access modules working hand in hand.

Hope this helps anyone having same issue.

shobhit_juyal’s picture

#9 Honestly Illustrated Credit

You are absolutely correct and thanks for the explanation. I was really stuck int the group field settings and totally ignored the "Group visibility" because I don't know how but one of my group was not accessible to non-member but others are. But after adding the Group visibility field it is working like a charm.

Thanks once again.

andrimont’s picture

Hello to all,
I followed this attention as OG still drive me nuts : in order to be very sure there were no interactions, I removed Access Control.
Then after rebuilding the permissions and also clearing the cache, I can hide the content as requested by setting private for OG group.
But if ever I make a slight change in the –let's say I change the description– of the OG group, then the access permission seems to lose effect : everyone access the node (with the setting private)…
I confirm that this OG group is set this way :

 Group content visibility: 
Private - accessible only to group members
Group visibility: 
Private - accessible only to group members

I don't understand what makes OG so unreliable.

jvieille’s picture

This module only handles the group visibility, it does nothing useful to make its content private.

I rewrote the function og_access_node_access_records() in order to get the senseful expected behaviour:
- The field group_access is attached to the group, it determines the visibility of the group itself
- The field group_content_access is also attached to the group, it determines the visibility of the content of the group.
Both fields are ignored if they exist in group contents.

The module now updates the grants of the whole content of a group whenever the group_content_access field is changed at the group level.

In my case a unique and same node type ("bundle") is used for both groups and group contents.
A given node can be at the same time a content (subgroup) and a group.
Contents are owned by a single group, only public contents can be shared, so the logic for setting the grants is simple.
To avoid og_access inconsistencies, the change of group_content_access field does not affect contents that are groups.
Other logics might be considered.

Most of the code of this module can (must) then be deleted. From the latest published version, the module stops after og_access_og_fields_info, line 227 (before the replacement of og_access_node_access_records)

function og_access_node_access_records($node) {
	if (empty($node->status)) {
    // Node is unpublished, so we don't allow every group member to see it.
		return array();
	}
	$wrapper = entity_metadata_wrapper('node', $node);

	// Verify that a group content with visibility field can't create when there
	// isn't an OG access field attached to the group entity.
	if (!empty($wrapper->{OG_CONTENT_ACCESS_FIELD}) && $wrapper->{OG_CONTENT_ACCESS_FIELD}->value() == OG_CONTENT_ACCESS_DEFAULT) {
		_og_access_verify_access_field_existence($node);
	}
	if(og_is_group('node', $node)){
		if (!empty($wrapper->{OG_ACCESS_FIELD}) && $wrapper->{OG_ACCESS_FIELD}->value()) { 
			// JV le node en question est un groupe, il a un champ og_access, et il possède une valeur, donc "1", il est privé
			$grants_record[] = array (
				'realm' => OG_ACCESS_REALM . ':' . 'node',
				'gid' => $node->nid,
				'grant_view' => 1,
				'grant_update' => 0,
				'grant_delete' => 0,
				'priority' => 0,
			);	
		}	
		$query = db_select('og_membership', 'ogm')
			->fields('ogm', array('etid', 'gid', 'group_type','entity_type'))
			->condition('gid', $node->nid, '=')
			->condition('group_type', 'node', '=')
			->condition('entity_type', 'node', '=');
		$result = $query
			->execute()
			->fetchAll();
		// Le champs OG_CONTENT_ACCESS_FIELD est défini, il est à 0 ou 2 : c'est privé
		$private = !empty($wrapper->{OG_CONTENT_ACCESS_FIELD}) && ($wrapper->{OG_CONTENT_ACCESS_FIELD}->value() == OG_CONTENT_ACCESS_DEFAULT OR $wrapper->{OG_CONTENT_ACCESS_FIELD}->value() == OG_CONTENT_ACCESS_PRIVATE);
		foreach ($result as $row) {
			$grants = array();
			$content = node_load($row->etid);
			if(!og_is_group('node', $content)){
				if($private){
					$realm = OG_ACCESS_REALM . ':' . 'node';
					$grants[] = array (
					//	'nid' =>$row->etid,
						'realm' => $realm,
						'gid' => $node->nid,
						'grant_view' => 1,
						'grant_update' => 0,
						'grant_delete' => 0,
						'priority' => 0,
					);
					// we need to update the grants dynamically, but this does not persist in case of rebuild. This handled with the condition "not a group"
					node_access_write_grants($content, $grants, $realm, $delete = TRUE);
				}
			}else{
			// recover existing grants
				node_access_acquire_grants($content, $delete = TRUE);
			}		
		}
	}
	else{
		// we need to properly handle the group contents individually so node_access cn be rebuilt
		// get group
		$groups = og_get_entity_groups('node', $node);
		if (is_array($groups) and count($groups) > 0) {
                       // we only care about the first, single group reference - this can be improved
			foreach ($groups as $group_type => $og_gids) {
				$og_id=reset($og_gids);
				if($og_id >1){
					break;
				}
			}
			$group = node_load($og_id);
			// get content_access of this group
			$group_wrapper = entity_metadata_wrapper('node', $group);
			$private = !empty($group_wrapper->{OG_CONTENT_ACCESS_FIELD}) && ($group_wrapper->{OG_CONTENT_ACCESS_FIELD}->value() == OG_CONTENT_ACCESS_DEFAULT OR $group_wrapper->{OG_CONTENT_ACCESS_FIELD}->value() == OG_CONTENT_ACCESS_PRIVATE);
			// if private, set grants
			if($private){
				$realm = OG_ACCESS_REALM . ':' . 'node';
				$grants_record[] = array (
					'realm' => $realm,
					'gid' => $group->nid,
					'grant_view' => 1,
					'grant_update' => 0,
					'grant_delete' => 0,
					'priority' => 0,
				);
				
			}
		}
	}
	return !empty($grants_record) ? $grants_record : array();
}