Postings in general (non OG) forum are marked private even though they are public

Quote from other issue:

Site-wide forums should not get any kind of marking because they do not have entries in the og_term table at all - which is where we keep track of publicity. In all of my tests, site-wide forums remain totally public regardless of settings from this module. What indications do you have that they are private?

Looking at my tests again... I see all site-wide forums marked with a 'public' tag. Perhaps you could elaborate on your settings and forum structure. Oh, and please open a new issue for any problems (like this one), so I can track it separately.

OK, so it looks like a visual issue, not a functional issue. Is that correct?

The condition to produce the 'private' label is isset($public_post) && $public_post->is_public == 0 && !array_key_exists($gid, $user->og_groups), where $public_post is the INNER JOINED node and ancestry tables, is_public is set to 0, meaning 'private' or unchecked, and the group (in this case 0) is not one of the current user's groups.

So the first and third arguments are likely returning a positive value, which is to be expected. However, I thought that is_public should have a 1 in it for all public posts. I'm certain that the OG audience is applied to all posts, whether in groups or not - which is how it knows which are in groups and which aren't.

I hope this helps in your noodling this out.

tfr75, what do you have the default visibility settings set for in the og admin: administer -> organic groups -> organic groups
and then under "Node authoring Visibility"? Check and make sure you don't have the default set to be private posts!

For instance, if you have it set on: Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Private.
then the default on the node authoring form will be for public to be un-checked.

Private groups in og will always override this public checkbox and make sure it's un-checked for posts in a private group.

So if you have a mix of public / private forums, you probably want to use one of the public node authoring options, i.e.

Visible within the targeted groups and on other pages

or

Visibility chosen by author/editor using a checkbox on the posting form. Checkbox defaults to Public.

So that og properly sets the public checkbox by default. Then users posting into private groups will have this public checkbox un-checked, og will ensure a post into a private group from one of the group content creation links never has the public box checked by default.

Not sure if this will help, but it might be a way to stop that from happening. I know we mix private and public groups with a default public setting and everything works properly.

That is really strange. Thanks Damien for pitching in on the support here. I assume that Damien is not having the problem and things are working as they should, just as in my own installations. You said that all posts that should be public have an is_public value of 1, which is correct.

Just to be clear, when you create a node, based on your OG audience settings, you allow the author to set the publicity of the node and the public box is checked by default. Is it also set when you edit that node, or does it somehow get unchecked? It sounds like your audience settings are correct. I wonder if you have any other OG or access control modules installed that could be upsetting things.

Check the og_term table. Browse to a site-wide forum. Note the tid in the URL. You should NOT find a corresponding entry in the og_term table, because it doesn't belong to a group. What this means is that, the containers and forums at the site-wide level can NEVER be set to be private. Which of course, is why your issue is a mystery.

To elaborate - when publicity is checked, group posts have their is_public value from og_ancestry checked as well as their forum/container's public value from the og_term table. However, site-wide forums don't have an entry in og_term, so their publicity is solely based on is_public.

Could you attach a screen shot of your og_forum settings? Could you attach a screen shot of your OG settings? Try using the Firefox plugin called Screengrab!

Did you use Screengrab? There is an option to grab the whole page, even the parts not currently on-screen so that you don't have to do multi-shots of a single page.

Did you notice that you have no selection for audience required? That could be the problem.

Wait a minute. Your screen shot shows that neither required nor optional is set. So I thought that maybe it needed some kind of setting to work right; i.e. I thought that perhaps without the radio button being chosen that OG was ignoring the setting for is_public.

To clarify what you see: with OG audience set to 'optional', you create a new forum topic at the site-wide level making sure to check the public box, but it is not labeled 'public' in the forum listing. Rather, it is listed as private. Is all of that correct? Do you realize that by making the audience 'required' users don't need to place content into a group? They can select public without selecting a group. Or am I remembering wrong?

OK. So I just adjusted my test site to use 'optional' audience and logged in as a 'regular' user. I marked the new forum topic as 'public', then submitted it. I used the breadcrumb to go back to the forum and the new post is marked as 'public', just as it should be.

So again, I am stumped.

You're right of course about the public box being disabled but checked. Sorry about that. And you're right about the requirement. I remembered wrong. So it seems that in my test, we have the same settings. Hmm.

Although I do want to get at the root of this problem, something I have done in the past to better control how/where content is placed is to require the audience then, using my mandatory groups by role module, I assign all users to a 'site-wide' or 'main' or whatever group which acts like the site-wide level since it is a closed group that all users are subscribed to. Defaulting all posts to public allows the content to be seen by visitors. I also always use my content types by group module as well to limit what content can be created in each group. That's just FYI, not a suggestion on how to deal with this issue.

Right. The public box was disabled. Hold on. Let me do it again to make sure...

The audience fieldset shows all groups to which the user is subscribed. All are unchecked. Public is checked, but disabled. I submit the new topic and...

The forum listing shows the topic as public.

Just after the check for privacy on line 470 (described in post #1) let's output the values of some variables. Add these three lines just before $rows[] = array(

drupal_set_message('<pre>public_post: ' .print_r($public_post, TRUE). '</pre>');
and
drupal_set_message('<pre>User og_groups: ' .print_r($user->og_groups, TRUE). '</pre>');
and
drupal_set_message('<pre>GID: ' .print_r($gid, TRUE). '</pre>');

That will tell us exactly why the condition for 'private' is being met.

So let's reason through the three conditions that must be met in order for the 'private' label to be applied...

First comes isset($public_post) This doesn't look set to me, but I suppose it could just be empty. Could result in TRUE or FALSE.

Next comes $public_post->is_public == 0 There is definitely no is_public member of the object. Should result in FALSE.

Last comes !array_key_exists($gid, $user->og_groups) GID 0 is definitely not one of the GIDs listed in $user->og_groups. Should result in TRUE.

Given any of these resulting in FALSE, the label should not be 'private'. I am wondering if I should test for isset($public_post->is_public) in that first condition instead of just $public_post. Care to try it out (after trying the next suggestion below)? I suppose we could be getting TRUE for the first condition if it is set but empty, as I mentioned before. Then perhaps "== 0" in the second condition might just mean "is FALSE" instead of "is zero". The first thing you could try is to change the "== 0" into "=== 0". This would force a check for a numeric value and not use 'zero equivalents'. In fact, I suspect that that will fix it. Could you try it and let me know?

I have virtually the same problem with my Drupal 5.5 + OG 5.x-5.0-rc2 + OG Forum 5.x-2.x-dev installation. Test messages are the same. I've tried your suggestion and changed the "== 0" into "=== 0". Everything works perfectly now! No wrong private labels. Does any other same condition needs to be changed to prevent some other inconsistence?

Yes, I've adder third = there. I can create topics after this fix.

Btw, I've also applied this fix to my OGF installation before: http://drupal.org/node/206064

@TfR75 - yep, that's the right spot. Can you browse all forums with this fix in place? This is only a part of a theme function and cannot affect anything else, so if you can't post to the forum of your choice, then I suspect that problem pre-existed the fix or you made some other change. Make sure you are using a fresh copy of the file and apply fix from here and as mentioned in #23 (which you did before I see). Also, what permissions does your user have and what groups do they belong to? Of course, user 1 should be able to post anywhere at any time.

@wghost81 - This is the only spot that this code exists, and as it is a theme function, no other code needs changing for consistencies. However, in the 'if' statement just before this one, there is an " == 1" that we may want to change to " === 1" if any problem with not showing any label occurs.

That surely is weird. At the moment, I can't think of anything else to look at. Maybe I'll think of something else later. My site-wide forum topics are all labeled 'public'.

@wghost81 - Are your site-wide topics labeled 'public', or not at all after the = change? And did you try the === 1 change?

Not at all, but this isn't looked like bug to me. I thought this should be normal behaviour for non-OG forums. So, again: all topics in all forums should have been marked as either private or public?

OK, I've looked into this more carefully. With no changes all topics in general forums which have an auditory assigned to them are marked properly. Topics in private OG forum are not marked at all. After adding a third '=' no marks appear at all in any forum.

Please, explain an idea of marking topics to me. Should any topics in private OG forums be marked? Or only topics in general forums?

I'll have to check, but as I recall, there are two parts to the process. But first, let me outline what happens without the public/private feature:

--Normally, all group forums are private, even if the posts in them are public, unless you are a member of that group. This means that for public posts, the user must get there some other way or know the direct URL. So some people requested that there be an option to make forums publicly browse-able.

So with that, and based on the settings in the screen shot you provided, this is how things should work:

--Regardless of an individual topic post, the forum it's in should default to auto-private if it is a group forum. This is recorded in the og_term table in the public column as a 0. Site-wide, or general forums as you call them, do not receive an entry into the og_term table.

--So first of all, users should not be able to get into group forums that they aren't a member of. I'm not sure what the admin user will see inside a forum he's not subscribed to. I think it should behave as if he's a member, right? Anyway, group forums that the user is not subscribed to should also not show up in the main group listing at www.yoursite.com/forum depending on the group's settings IIRC.

--Concerning site-wide forums, since there is no setting for public in the og_term table for that TID, the user should have access to all forums. Now that I'm thinking about it, I can't recall whether site-wide posts should be labeled, but I think they should since I use a fake GID for the site-wide "group" of forums (which is how we're able to have both site-wide and group forums working together in the first place), and the third condition in the if statement checks to see if the GID is not one that belongs to the user's subscriptions, which it isn't. So site-wide topics should have their individual node publicity governing the label.

--Concerning group forums, if the user has access to the forum, there should be no markings at all - neither public nor private markings since they are a group member and have access to all group posts at all times.

--If the user is visiting a forum of a group to which he does not belong, since you are allowing group admins to open or close their forums to outsiders, then they would see the public and private labels for those posts in those forums.

Does that answer your question? I know we aren't closer to solving this at all.

Yes, that answers my question. But shouldn't private topics be hidden from those, who aren't a member of auditory group regardless of the OG forum publicity settings? If the answer is 'yes', there should be no need in private/public markers...

PS I'm not an expert in SQL, so forgive me if I'll say something stupid, but shouldn't you be checking if the entry you are reffering to exists before any comparisions?

The whole idea with public and private markers is to show users what they are missing; i.e. they click on a 'private' topic and get the regular 'Access denied' screen since they don't have permission to see it. In this way, you could make all of your forums publicly browse-able, but at the same time could have all of your posts be private. This would be like a teaser for unsubscribed users.

I'm not sure which code you are referring to in your SQL question. In general, the install file (and in CCK's case, the field_settings hook) should setup the database correctly. If it doesn't at that time, then errors should be thrown and the problem(s) fixed immediately. To check if tables and/or columns exist before every query would add a tremendous amount of overhead by doubling (at least) the amount of SQL queries - and Drupal is already known for having an over-abundance of queries and bringing servers to their knees because of it!

I'm talking about $public_post variable. As it follows from your code, this variable should be equal 1 or 0, but debug messages say it is empty (I don't know why, may be because it doesn't exist at all). So why don't check this 'emptiness' right after db_fetch_object(...) call?

I see what you're saying. I thought you were talking about a query problem. The issue, I suppose, is that so long as the SQL query executes correctly, whether it returns records or an empty-set, a valid object is created, though as you point out, it's empty. Like I mentioned above somewhere, I wonder if switching the isset($public_post) to isset($public_post->is_public) would be enough since that tests for structure in the object.

Oh, and I just remembered (thanks to the PHP site) that as of PHP 5, objects with no properties are no longer considered empty, and I think the object is created in this case. So I think testing for the existence of a property may be the best thing to try... when I get time... unless you want to try.

On the other note, even for Omitted content types, I gotten the Access denied. Could domain module contribute to this error?

@Paul

So I didn't apply the triple =? Compare the _broken copy I sent you and see if I did anything there. Otherwise, I suppose this issue can be rolled into the other one that is related: http://drupal.org/node/244139

The issue is that the query:

SELECT oa.nid, oa.is_public FROM {node} n INNER JOIN {og_ancestry} oa ON oa.nid = n.nid WHERE n.type = 'forum' AND n.nid = %d

will return an empty result set for any topic not associated with a group. Thus, this conditional statement succeeds because $public_post is set to the return value of db_fetch_object() which in turn uses *_fetch_object() (based on db backend), which in the case of no available result row, returns FALSE:

elseif (isset($public_post) && $public_post->is_public == 0 && !array_key_exists($gid, $user->og_groups)) {

This means $public_post is set, accessing a member of a non-object ($public_post->is_public) returns null, which evaluates == 0 successfully, and $gid (0) is never found in $user->og_groups keys. There are a couple ways to fix this:

1. The solution mentioned above, using '===' instead of '==' will work, but that doesn't seem like the best option.

2. If I'm correct in understanding that any post not associated with a group is to be considered public, and any post not associated with a group will not have a row in og_ancestry, then I would instead rewrite the SQL query on line 461 to read:

$sql = "SELECT oa.nid, COALESCE(oa.is_public, 1) AS is_public FROM {node} n LEFT JOIN {og_ancestry} oa ON oa.nid = n.nid WHERE n.nid = %d";

This will tell the database to set is_public to 1 in the event that it would otherwise return NULL, which is happening in the case of non-group forum posts.

Patch for solution 2 is attached.

Thanks for the fix, Josh - your explanation of the problem was spot on and your fix worked like a charm.

I have one last issue - I don't want topics to be labeled "public" or "private" at all. Private (group) forums should simply be hidden, and everything else should be assumed to be public.

In all non-og forum containers, I see "public" on all the topics, but in og-generated forums, I currently see no tag - public or private. Does that make sense? It seems like the current behavior is inconsistent.

How can I simply keep the tags from showing?

Override theme_og_forum_topic_list. Just copy/paste it to your template.php, rename to phptemplate_og_forum_topic_list, then modify the lines that add 'public' or 'private' to the topics.

If you read through that function, you'll see that og_forum hides the public/private tags if the user is a member of the group that the topic is associated with.

It doesn't look like this fix made it into 2.2? Or am I missing something?