Forum topic sometimes created as private even though created in public forum

Similar to my patch for #1168000: Non group member posting into a public forum - taxonomy failure, I found a spot to allow for an unconfigured public:

-			WHERE n.type = 'forum' AND oap.og_public = 1 AND tn.tid = %d";
+			WHERE n.type = 'forum' AND (oap.og_public = NULL OR oap.og_public = 1) AND tn.tid = %d";

og_forum_resurrection: og_forum.module: line 484: og_forum_nodeapi()

Submitted patch has bug fixes for both this issue and #1168000: Non group member posting into a public forum - taxonomy failure.

Have tested and new posts to private forums are still private.

(FYI - Does not fix old forum topics, only newly created ones after fix is applied.)

Am thinking this patch is probably not correct.

It worked in testing, but now it is not, these og forums seem annoyingly random for me this way.

I've spent a fair amount of time ripping apart the code and SQL to figure this out.

The "elseif ($node->type == 'forum') {" section of og_forum_nodeapi() (line 460+) is pretty dizzying in its complexity, but one thing I am noticing is that og_access_post.og_public deals with a binary true false, and the og_term.public is a quadstate based on the constants defined in the beginning of the file, 0&1 meaning private, 2&3 public.

One disturbing thing to me is that PUBLIC_BY_GROUP_OWNER is not use anywhere in the file, and thats my most common use case. Although I do see in two places comparisons to PRIVATE_BY_GROUP_OWNER which sort of counts.

Personally I am not at all used to setting publicity on a forum topic, in most forum environments the forum container is what dictates the visibility and when the container changes the topics should follow.

At this point somewhat tempted to boil this module down to handle my use case, since the PUBLIC_AUTO and PRIVATE_DEFAULTs are confusing the hell out of me with no benefit (to me), whatsoever.

Still working on this.

I've come up with some SQL that I am using to audit and fix my DB (fix with on caveat and a question).

; View Publicity exceptions for those post that should be public
SELECT DISTINCT oap.nid AS nid, tn.tid as tid, oap.og_public AS public_post, ot.public as public_forum
 FROM og_access_post AS oap 
 JOIN (term_node AS tn, og_term AS ot)
 ON (oap.nid = tn.nid AND tn.tid = ot.tid)
 WHERE ot.public > 1 AND oap.og_public is FALSE

; View Publicity exceptions for those post that should be private
SELECT DISTINCT oap.nid AS nid, tn.tid as tid, oap.og_public AS public_post, ot.public as public_forum
 FROM og_access_post AS oap 
 JOIN (term_node AS tn, og_term AS ot)
 ON (oap.nid = tn.nid AND tn.tid = ot.tid)
 WHERE ot.public < 2 AND oap.og_public is TRUE

; To reset publicity on all forums posts according to their forum's current publicity settings.
UPDATE og_access_post, term_node, og_term
 SET og_access_post.og_public = TRUE
 WHERE og_access_post.nid = term_node.nid AND term_node.tid = og_term.tid AND og_term.public > 1;
UPDATE og_access_post, term_node, og_term
 SET og_access_post.og_public = FALSE
 WHERE og_access_post.nid = term_node.nid AND term_node.tid = og_term.tid AND og_term.public < 2;

After executing the fix code the forum topics still have the wrong visibility, BUT if do an edit then save they are corrected. How do kick Drupal in to re-evalling the visibility without edit the 200+ topics that need to be fixed?

The above audit code above in #3 fails to take into account that term_node is a versioned link table. The vid in term_node stands for "version id", not "vocabulary id" as one might expect in a taxonomy related table. So you need to do a few gyrations to get the latest version (namely joining the table to itself after grabbing the max for the nid).

Proper audit join is:

SELECT oap.nid as topic_nid, ot.nid as group_nid, tn.tid as
tid, oap.og_public AS public_post, ot.public as public_forum
FROM term_node AS tn
JOIN (
  SELECT nid, MAX(vid) AS vid
  FROM term_node AS t
  GROUP BY nid) AS tn2 ON (tn.nid = tn2.nid AND tn.vid = tn2.vid)
JOIN og_access_post AS oap ON (tn.nid=oap.nid)
JOIN (og_term AS ot) ON (ot.tid = tn.tid ) 

With either of these two where clauses:

; View Publicity exceptions for those post that should be public
WHERE ot.public > 1 AND oap.og_public is FALSE

; View Publicity exceptions for those post that should be private
WHERE ot.public < 2 AND oap.og_public is TRUE 

Oh if anyone wants to instruct me on cleaner SQL, please feel free :)

So to fix this bug for myself, I've added some code to og_forums.module:starting line 777: og_forum_form_alter():

        // this 'value' element persists the audience value during submit process
        $form['og_nodeapi']['invisible']['og_groups'] = array('#type' => 'value', '#value' => $groups);
        // lines above for context -- new code below
        if (arg(1)=="add") {
          // this will keep "Public" checkbox selected,
          //  if this is a public forum we are creating a new topic in.
          //  If we are here, arg3 is tid of the forum we are creating the topic in.
          $form['og_nodeapi']['visible']['og_public'] = array(
            '#type' => 'checkbox',
            '#title' => t("Public"),
            '#default_value' => og_forum_is_public(arg(3)),
            '#description' => t('Show this post to everyone, or only to members of the groups checked above. Posts without any groups are always <em>public</em>.'),
            '#weight' => 2,
          );
        }

I don't think this covers all cases yet, but what it does is properly default the public checkbox.

I think you need to enable the checkbox for this to work.

- Pro

So I am still using the above update code.

I did get a few problems in cases where the forum topics had been moved from a private forum to public and vice-versa, due to the term_node versioning, I could probably fix, but I only had three cases which came up in the audit code, and I fixed by hand.

Used the Rebuild permissions: admin/content/node-settings "Post Settings" after SQL execute to get this to stick.

- Pro