[SOLVED] Audience changed to public after editing forum-topic when audience is optional

Question: is it 'changed' to public, or is it given BOTH the group and public audiences? If only public, I think it would disappear from the group forum altogether, so that's how you'd check. If the public box is simply being checked without your permission without UNCHECKING the existing audience, that's something that shouldn't be too hard to track down.

Please check this and get back to me.

Okay, I'm getting to this now. I confirm the issue. It may be related to the og issue I posted here: http://drupal.org/node/177626

If so, I'll just have to include the code and instructions in the README to patch OG if Moshe won't add the change as I've written it. I understand that he isn't convinced that I've properly identified the problem and come up with the right solution, but in my installations, this is working great.

Part of the problem is my fault. I'm not sure what line it is in the released version since I've changed my copy, but if you comment out the line that reads: $form['og_nodeapi']['visible']['#access'] = 0;
you should no longer have an empty groups fieldset!

Sorry about that.

So I'll investigate this, but I suspect that the two things I just mentioned combined to cause your issue. Please attempt to apply both code changes to your install and let me know if it works. Meanwhile, if I find something else that is obviously causing this, I'll fix it and let you know.

Okay, I just tested things, and it appears that the two changes above work. I am able to create posts (the audience is shown, but not changeable, and the public box is unchecked) and then edit it (the options don't change) and can browse to the post through the forum.

So I will definitely add the above-mentioned og issue to the README and include the three lines of code that should be added and instructions on where to add it. I'm not going to include a patch as such so that this should be able to be applied to any future version of OG - i.e. line number changes won't matter. I'll also create a closed issue with expanded instructions that I'll refer to in the README.

OK. As someone else was having a different issue with OG audience being an optional thing, so I decided to try and reproduce your problem with that setting. And you're right. The checkboxes are unchecked. So now I know where to look. I suppose you have good reason to not create a faux site-wide group so that you could work around this by making audience required, but if not, that is one thing you could do for now until I track this down.

As to your comment that started "BTW", the very good reason to handle things differently is due to the fact that forums reside within groups and to allow a post of a given group forum to not be placed in that forum would jack things up. This, of course, applies only when a user browses to a group forum, not when they create a forum topic at the site-wide level and place it somewhere. However, I think the behavior of the latter is not quite as it should be and I'm sorry to say that since my own installations all have audience set to 'required', it just hasn't been a priority of mine. But I do believe I have a task/issue here in the queue as a reminder - i.e. auto set the group audience based on the forum selection.

As for the name change issue, what should happen is that the group container, which, upon group creation is given the name of the group, should have its name changed to reflect the new group name. Since tids are not changed, there should not be a problem. I thought I tested this pretty well, but if you are saying that a name change to a group changes the container name and orphans the forums, then open a new issue. However, what you describe seems to indicate that the forum names are changes, and not the container name, so that would be super-puzzling.

Looking at the code, this is what is happening. When audience is set to be required, I automatically choose the group the user is posting from and set it as the #value, rather than the #default_value. Although I agree that the UI in your case needs to have the box checked, what should happen as things now stand when you submit an edited page is - nothing. Nothing should change. The group is correctly listed in the array as the #value. You can use the devel form_inspect module to see that.

Try commenting out unset($form['og_nodeapi']['visible']['og_groups']['#default_value']); around line 1118.

And do me a favor. Before you comment out that line, edit a group forum topic, save it, and see if it is still in a) the right forum, and b) that the group context menu pulls up the right group's stuff.

BTW, can anyone tell me if there are any consequences for having both #value and #default_value set? Does one override the other? I expect that #value overrides and so simply commenting out the line I mentioned will show the correct box checked, but will not allow changes.

Another question: Until I get the auto-group-assign feature done, should we allow users to even see the audience selection during node edit? Or would it be better to hide it since a change would orphan the node from the group context, but keep it in the forum?

If you switch to a required audience for a few minutes and edit one of your forum topics, you will see that all that the user is shown is a text message telling them what the audience is set to, followed by the public box.

Right. My comment in #10 means that for your setting of an optional audience, I should conditionally apply what you did in #11, otherwise if audience is required, the code should not be commented. I'll mark this as patch needs review to remember to put this in next chance I get. Thanks for testing.

changing title to reflect outcome.

Added to my copy of the module, so this will be in the next release.