Users see audience checkboxes for groups they don't belong to during non-admin node edits

discussed this in the issue queue before but i don't recall any resolution. anyway ...

the core issue here is which groups to show when a non admin edits a node. do we show the author's subscriptions, the editor's subscriptions, or some hybrid? today, we show the author's. if we switch to he editors groups, we would at minimum have to add any groups that the node currently belongs to that are not in the editor's list. so in a sense, thats already an "information disclosure" problem. i guess we could just silently keep those groups checked during the edit.

one other approach is to hide the audience selector if a non admin edits other person's post. so they can edit content but not audience and public/private.

comments? this is complicated stuff.

This is very complicated. I was going to say that the audience should reflect the groups(s) of the author, but what if the editor doesn't belong to all the group(s) that the content was posted into?

I don't think you should ever be allowed to post to a group you don't belong to, even if you're just editing existing content.

So, if you conversely say that the audience should reflect the groups of the editor, then that might leave out one or more of the groups that the original author intended for the post.

If you say that the content should only be edited in the group that the editor has permission to edit, then you're talking about one version of the content in this group, and another version in other groups.

In short, I don't know what the solution should be. Interested to find out who does have a good idea.

so what about my proposal that non admins only see audience if they authored the content? IOW, we get around the whole problem by not allowing audience changes.

so what about my proposal that non admins only see audience if they authored the content? IOW, we get around the whole problem by not allowing audience changes.

This make sense to me.

i hadn't seen that module. so now i'm even more sure that we should disallow audience editing in this instance and recommend that module if sites need it.

i don't really understand your last comment, christefano. there are problems with either choice: the editors subs or the authors subs. if you do author, you risk information disclosure about that person's groups (as you know). if you do editor, you risk unknowingly dropping the post from groups where the editor is not a member. so i don't know which you feel strongly for, and how you intend to resolve the problem.

barring any more objections, i plan to remove audience in this case and then commit.

Subscribing to this issue.

We are proceeding with removal of audience editing by non admins .. I posted a few minor improvements that are desired for OG_Audience. See http://drupal.org/node/173133

That sounds like a good idea. Currently, the Audience checkboxes allow users to do some very crazy things with posts that are better left to site admins only.

so, i started implementing this but then i noticed that the Public checkbox (when enabled) now shows by itself. Without the context of the selected groups, the checkbox makes no sense. Ugh, needs more thought.

The current model is that the existence of any group home page is not a secret. Reclassifying as an important feature request.

lets address this in 5.x.5. 5.x.4 which was just released!

What is the situation in the newly released version 4.0?
Can users post into groups they do not belong to?

i am also interested to know how this is working in 5.4

subscribe

I did not deliberately fix this. Editing a node still shows the groups of the node author. I'm curious though bout other people's experiences here. I'd be quite pleased if the issue magically vanished.

I would like to propose the following solution:

1) the audience form only shows checkboxes for the groups that BOTH the author AND the current user are members of.
2) settings for groups that are not displayed in the form stay unchanged during edit.

I think that solves all the problems as users can not change content in groups they don't belong to and also they can not find out about the existence of groups they should not know about.

Sites that need more generous editing rights for audience checkboxes can use the OG Audience module.

A slight addition to my previous proposal:

We should also add checkboxes for all the groups for which the current user is the manager. With my previous proposal (as well as with the current implementation) it can happen that an author leaves a group after posting content to that group and then noone can remove the content from that group any more.

Strictly speaking, to just solve this problem we would only need to add checkboxes for those groups that are already checked and for which the current user is the manager. However I see no big problem with showing all the groups that the current user is the manager of. This will give the manager the possibility to add content to their group of which the author is not a member. This is a bit strange because then someone from outside the group can edit content inside the group, but I guess we can leave it to the group manager to decide whether this is desirable or not.

Christefano,

It seems your original bug report has a typo. You must have changed line 1550, not the line you mentioned.

For my opinon, the best solution was outlined in moshe's original post, and in delius' proposal:

Simply show only the group the editor belongs to, and settings for groups that are not shown go unchanged.

Best,

Matt

I agree with #23, ref. #1:
"hide the audience selector if a non admin edits other person's post. so they can edit content but not audience and public/private."

I did not deliberately fix this. Editing a node still shows the groups of the node author. I'm curious though bout other people's experiences here. I'd be quite pleased if the issue magically vanished.

I upgraded to og 4.1 (am running D5.3), and i still see this behavior. If a group member goes in to edit another group member's post, then group member #1 can see the other groups that the author belongs to and has the opportunity to post to these groups and to make them public. (Except if the author is an admin, then the group member cannot the audience checkboxes).

i also agree that it is best to:
"hide the audience selector if a non admin edits other person's post. so they can edit content but not audience and public/private." But only if this doesn't interfere with a similiar-related problem that i am seeing:

when a member of a group visits his group portal and then leaves the group portal to enter the public part of the site, if he goes to make a public post, the audience checkbox defaults to the last group he has visited.

so, my fear would be: that the user is not able to see the audience checkboxes and he enters the public arena to make a public post and does not know that his post is defaulting to the last group he visited, he won't know that it is being posted to that group.

if we went with #21+22, should we show '3 more groups' but not name those groups? or list non private ones but not make them editable? just trying to nail a UI ... i am also still considering removing audience AND public checkbox for non admin edits.

i am also still considering removing audience AND public checkbox for non admin edits.

Removing audience is ok, but NOT the "public" checkbox! Non-admin group members should have the option of making their group posts public. Or, at least, the administrator should have the option of deciding whether a group member should have the option to make his post public.

For that matter, the administrator should have the option of deciding whether a group member should be able to post into other groups he belongs to (in short, the behaviour we're supposed to have now). But, if I have to live with anything, it would be not allowing non-admins to post into groups other then the one they happen to be in when creating the post.

@SomebodySysop - the problem is that the Public checkbox has undefined meaning if you can't see the groups that the post is already in. You need to know where the post will show and where it won't. Maybe we should show the list of groups as read only.

"it would be not allowing non-admins to post into groups other then the one they happen to be in when creating the post". thats what unchecking 'audience checkboxes' on admim/og/og does for you on node/add. for node edit, that doesn't make sense.

"it would be not allowing non-admins to post into groups other then the one they happen to be in when creating the post". thats what unchecking 'audience checkboxes' on admim/og/og does for you on node/add. for node edit, that doesn't make sense.

Agreed. So, for node edit, don't let non-admins change the group(s) that the post currently belongs to. Just show the group(s) it's currently in, and that's it.

Although, I'd still like to see an option there to make the post "Public", even on a node edit.

Moshe, to answer you question in #26: the groups that a node belongs to are already listed on the node page (at least when using the template that comes with og) and so I see no harm showing them also on the node editing form but with non-editable checkboxes where appropriate.

ok, so there is some consensus here. my notes:

* we switch to showing the current user's subscriptions, not author's
* subscribed groups not in that list are either shown to editor in a read only form element (if he *could* access that group) or hidden if he could not.
* we'll need a way form element for persisting these read only/non-viewable groups. these groups should be put back in the $node->og_groups array during og_nodeapi(submit).
* in order to determine if editor can see these additional groups, use a query like db_rewrite_sql(SELECT nid FROM node WHERE nid IN ([additional_nids])). any nids that fall out are private or otherwise inaccessible to the editor

Fixed more or less as described in #30. I distinguish between My subscribed groups and Other groups when the editor sees groups of which he is not a member. In that case, we use an optgroup in the Audience form element.

Please test and report back your findings. You may reopen this issue if bugs arise.

groups.drupal.org has been updated to run the latest og which has this fix in it. Folks can take a peek by browsing to http://groups.drupal.org/node/7982 and clicking on the edit tab. If you don't see that tab, you need to join the CCK or 'Profiles as node' group. See the subscribe link in the right hand block. Once on the edit form, scroll down to the Audience select and you will your groups instead of the author's. As long as you don't belong to both of the CCK and Profiles as nodes groups, you should see the new optgroup in the Audience select. I think it looks rather spiffy.

-moshe

Moshe, I just went to the node http://groups.drupal.org/node/7982. I saw the two groups that I was not a member of in the "Other groups" section in the drop-down selector. But I was still allowed to de-select them. Is that intended? Should I be able to remove content from groups I do not belong to? Or is what I select for those groups on the form just ignored when I save it? I didn't want to try because I didn't want to mess with Michelle's page.

@gustav - i pondered that very question for a while. You can in fact remove that post from those groups. I decided upon the behavior you see because if one has the ability to edit the content, then one can change the meaning of the post and some existing groups may no longer be an appropriate audience.