Public Audience checkbox still visible with all private group settings

I've noticed a similar issue in rc3... groups are private, audience checkboxes is de-selected and audience is required. If a user is only a member of one group, they see (and are allowed to use) the "public" checkbox for any content they create. If they are a member of more than one group, the public checkbox is not there. It shouldn't be there no matter what.

Here are my exact settings:

New groups don't appear in the groups directory. Administrators control the directory exclusively.
New groups don't appear on the registration form. Administrators control the form exclusively.
Audience checkboxes is de-selected.
Audience is required.
Visible only within the targeted groups.
New group home pages and default audience are always private.

I've switched this issue from support request to bug report and updated the version from 6.x-2.0-rc1 to rc3.

using any og contrib modules?

please try with latest code.

No, the only og-related modules I am using are og, og access control and og views integration. I've tested with 6.x-2.0 and am having the same issue. Doesn't seem to matter how many groups the test user is a member of... the public option is always there, even though the user has no roles other than "authenticated user" and group is set up with audience required and audience checkboxes de-selected. Tested by creating two brand new groups and new content within those groups. Mysterious...

Same problem here.

OG-related modules:
- Organic groups 6.x-2.0
- OG Calendar 6.x-1.0
- Content Type Administration by Organic Group 6.x-1.2
- OG Forum 6.x-2.0
- Organic Groups Mandatory Group 6.x-1.0-beta1
- OG Vocabulary 6.x-1.0
- Views 6.x-2.6
OG-config:
- Groups directory control: Group creator chooses whether her group appears in the directory. Defaults to not in directory.
- Registration form control: New groups don't appear on the registration form. Administrators control the form exclusively.
- Audience checkboxes de-activated
- Audience required: Required
OG-access-config:
- Visibility of posts: Visible only within the targeted groups.
- Private groups: Group administrator chooses whether her group homepage and audience are private or not. Defaults to private.

I too have this issue. I'm doing some research to try and see what's up.

I'm running:
Drupal 6.14
OG 6.x-2.x-dev

Hey guys... I believe I fixed it. At least, it works for me.

Anyway, here was the problem:

There was a logic error.

Line 186 was testing for the option to choose whether or not the admins wanted the users to have the choice of making the post private or public, but the conditions were wrong.

So, to fix it, just change
$vis = variable_get('og_visibility', 0) == OG_VISIBLE_BOTH ? OG_VISIBLE_GROUPONLY : OG_VISIBLE_CHOOSE_PRIVATE;

to

$vis = variable_get('og_visibility', 0) == OG_VISIBLE_GROUPONLY ? OG_VISIBLE_GROUPONLY : OG_VISIBLE_CHOOSE_PRIVATE;

I don't know how to patch, otherwise I'd just make a patch.

Anyway, I hope that solves your problems, because it solved mine! Now I just need to make a "Quota by Organic Group Post" module, and I'll be in business.

Hello,

Having same issue here, with this config:
OG-related modules:
- Organic groups 6.x-2.0
- Content Type Administration by Organic Group 6.x-1.2
- Views 6.x-3.x-dev

OG-config:
- New groups don´t appear in the directory. Only admin have control over the directory.
- Groups directory control: New groups don´t appear in the directory. Only Admin have control about them.
- Registration form control: New groups don't appear on the registration form. Administrators control the form exclusively.
- Audience checkboxes de-activated
- Audience required: Required

OG-access-config:
- Visibility of posts: Visible only within the targeted groups.
- Private groups: Group administrator chooses whether her group homepage and audience are private or not. Defaults to private.

I have tested the code in #6 and I have changed in og_access.module line 186, with these results:

- Audience check box now is hidden --> This is good!

- Views -> Here I´ve found a problem, maybe it is my fault maybe it doesn´t.

I have a "Groups: Groups" argument in my view with default php code:

// If I have the group, i´ll take it from the url

	$node_filter_giid = node_load($_GET['gids'][0]);
	if($node_filter_giid)
	return $node_filter_giid->nid;

// If I don´t have the group gids[] in the url, I will try to know what content type is and get the group from the content type

	$node_arg = node_load(arg(1));
	if($node_arg)
	{
		switch ($node_arg->type)
		{
			case 'groupnodetype':
				return $node_arg->nid;
				break;
			case 'standardgroupposttype':
				return key($node_arg->og_groups);
				break;
		}
	}
	return ''; 

This code from above was working fine BEFORE I changed the code in the line 186 in the og_access.module line 186. AFTER changing that code, I looks like the php code is not working.

Here is my little test.
Maybe someone with more experience can get deeper on it.

Thanks anyway!

That's odd. The change shouldn't affect that part of the code at all, since it's just a very localized test to see whether or not the public radio should appear.

Have you tried reverting the code back and seeing if it the behavior disappears?

Also, is the views version a typo? You wrote that you're using views 6.x-3.x-dev. Are you using the right views version, because I see the Views 3 for Drupal 7, but not for Drupal 6.

Hello,
I reverted the code, and the error still there. Probably my fault. I will try to see what happened.
Yes, I am using 6.x-3.x-dev, you can download from here:

http://drupal.org/node/467670

If I find my problem I will post it here.

Thanks for the code. It is really important for me to have that check box disabled.

Hello,
Everything works OK!
As far as I have tested, everything is working GOOD!

My comment in #7 was my fault, and now I have double tested it and it is working FINE!!

So what I have done is:
1 - Open og/modules/og_access/og_access.module file.
2 - Replace the line 186:
$vis = variable_get('og_visibility', 0) == OG_VISIBLE_BOTH ? OG_VISIBLE_GROUPONLY : OG_VISIBLE_CHOOSE_PRIVATE;

For this one:
$vis = variable_get('og_visibility', 0) == OG_VISIBLE_GROUPONLY ? OG_VISIBLE_GROUPONLY : OG_VISIBLE_CHOOSE_PRIVATE;

I think this is an important security bug!! so thank you very much for this code!

Here's the patch. I learned how to make them (it takes two seconds). This should be good to go.

No problem. It's nice to give something back. ;D

I think this is awaiting review rather than porting...

Also the comment above the changed line should probably read something like

Set visibility to the appropriate private option.

subscribing

Having this issue set at "needs work" is preventing it from being committed. The fix in #11 is clearly correct, and I think it's fair to let the module maintainer decide if the comment needs to be changed.

I have the same issue: when it will be committed?

committed, thanks.

The problem with this line...

$vis = variable_get('og_visibility', 0) == OG_VISIBLE_GROUPONLY ? OG_VISIBLE_GROUPONLY : OG_VISIBLE_CHOOSE_PRIVATE;

...is that in some cases it changes the $vis variable that was already set by this code earlier on:

if (user_access('administer organic groups')) {
  if ($vis < 2) {
    $vis = $vis == OG_VISIBLE_GROUPONLY ? OG_VISIBLE_CHOOSE_PRIVATE : OG_VISIBLE_CHOOSE_PUBLIC;
  }
}

So the result is that "OG admins always see the checkbox for making a post public." will not be true in some cases. More accurately, whenever on the "Organic groups access configuration" page the
"Visibility of posts" setting is "Visible only within the targeted groups." AND the node has been posted to at least one private group, nobody will see the public checkbox.

There is an unfixed issue for this at http://drupal.org/node/624784.

This patch fixed something but broke something else. What kind of patch should be applied that would fix something (or rather, everything) and break nothing, I don't know yet. In the og_access_alter_nongroup_form function, the pieces of code that set the $vis (visibility) variable, should be conditional taking into account that $vis may have already been set.

I'm going to continue trying to figure out what would be the correct logic that would hopefully not break any other functionality of this module or others'. Should I create a new issue or continue with this one?