I am trying to set up og_forums in a specific way:
I want anybody to be able to post to a forum, without being a member of a specific group
I want the group owner to 'set' whether posts to the group are pubic or not.

So - og_forum offers a public/private switch. This is good, but relies on the og groups targeting mechanism (and the 'public' button)

I am using the og targeting for many other things, in this case, Forum's isn't fitting in quite right.
(Actually, my specific problem in this case, is that I want non group members to publish the forum posts).

I'd rather the "public/private" switch did that for all the POSTS inside the forum container, as well as effecting the visibility of posts in the group forum listings.

In other words, I want to make forum posts opt out of the OG targeting system, but have the og_forum public/private switch work for all the posts inside a forum.

Actually - I think this behaviour would be complimentary - if an admin marks a group as private, and somebody marks a post as public within that group - as things stand right now, the post is actually visible (if you know it's node number for instance). -- worse, in some cases, for instance, like me, if you are using a view, rather than the OG_Forum listing itself - then the post is un-affected by the admin's public/private choice.... which is probably not right.

So - I _think_ the right thing to do is add some node_access control to og_forum to handle this...

I'd appreciate any comments on this idea...

Cheers

Mark.

Comments

markfoodyburton’s picture

Status: Active » Needs review

Thanks to a lot of help (e.g. merlinofchaos) thinking about this problem here is a clean solution I think.
What I dont know is how well this would play with the og targeting system (as I have said, I am opting the forum posts out of the og targeting system - so this needs to be thought through and tested) - so please review...

For me, the code works a dream...

The code just needs to be added to og_forum.module

function og_forum_disabling($set = NULL) {
  static $disabling = false;
  if ($set !== NULL) {
    $disabling = $set;
  }
  return $disabling;
}

function og_forum_node_access_records($node) {
  if (og_forum_disabling()) {
    return;
  }
  
  $grants = array();

  if ($node->type=='forum') {
    // one relm per group the node is in...
    $query = db_query("SELECT tid FROM {term_node} WHERE nid = %d",$node->nid);
    while ($tid = db_fetch_object($query)->tid) {
      if (!og_forum_is_public($tid)) {
        $gid = og_forum_gid_from_tid($tid);
        $grants[] = array(
          'realm' => 'og_forum', 
          'gid' => $gid, 
          'grant_view' => TRUE, 
          'grant_update' => FALSE, 
          'grant_delete' => FALSE,
          'priority' => 0,
          );
      } else {
        $grants[] = array(
          'realm' => 'og_forum_public', 
          'gid' => TRUE, 
          'grant_view' => TRUE, 
          'grant_update' => FALSE, 
          'grant_delete' => FALSE,
          'priority' => 0,
          );
      }
    }
    
    $grants[] = array(
      'realm' => 'og_forum_author', 
      'gid' => $node->uid, 
      'grant_view' => TRUE, 
      'grant_update' => TRUE, 
      'grant_delete' => TRUE,
      'priority' => 0,
    );
    return $grants;
  }
}
function og_forum_node_grants($account, $op) {
  $grants['og_forum']=array_keys($account->og_groups);
  $grants['og_forum_author'] = array($account->uid);
  $grants['og_forum_public'] = array(TRUE);
  return $grants;
}
Anonymous’s picture

@Ryan

Do we want to allow "anyone" to be able to post into a group forum ? I am thinking this is probably not something we would want to implement for a general audience.

markfoodyburton’s picture

Note, the code is supposed to address the more general problem once a post has been submitted of ensuring the right people can view it - given the public/private switch on the group. Sorting out public (or registered user) access is a different thing (and can be achieved without this patch I believe)

Cheers

mark.

Anonymous’s picture

Assigned: Unassigned »
rconstantine’s picture

@Paul

This is another patch to review after the D6 conversion. In reading it though, I am reminded that elsewhere someone was concerned about being able to enter in a node's URL directly and see it/interact even if we have marked it private. As all nodes should be hidden from non-members by default, this seems to be an issue with OG. Public posts should be seen by all in all circumstances.

Anonymous’s picture

Version: 5.x-2.x-dev » master
Status: Needs review » Postponed
Anonymous’s picture

Title: og_forum/node_access/public/private » [More Info] og_forum/node_access/public/private
Version: master » 6.x-1.x-dev

Is there anyone who has reviewed this feature or would like to see it implemented in D6 ?

Thanks Paul

Anonymous’s picture

@Ryan
Would you like to review this patch and decide its fate ?

Anonymous’s picture

Assigned: » Unassigned
Status: Postponed » Closed (fixed)

As there had been no further interest for some time i am going to close this "feature request".

Best, Paul

batje’s picture

subscribe (as this is a very valid request, if a group is closed, the forum and all the forum posts and all the comments to those posts should be hidden and inaccessible for anyone. with the increasing use of search, like apache_solr or other content recommendation methods, setting the right permissions becomes more important as standard navigation is not the only way anymore of finding an item.)

this will probably become relevant for us in the rather near future.

batje’s picture

Assigned: Unassigned » batje
Status: Closed (fixed) » Needs review
StatusFileSize
new4.15 KB

Attached is a .patch that is based on the code that Mark posted in #1 and extends it. It does the following:

- If a group is private, only members of the group can see the forum posts in the forum. Not just by obfuscation, but those posts will also not pop up in search results or views with 'recent forum posts' etc.
- If you make Forums public and back to private, all access rights on forum posts in the forum are reset from public to private and back.
- Comments. If you are not a member of a group, you can not post a comment on a forum post.
- The link to 'Add new Post' changes into 'Join the group to be able to post'
- The comment form on the forum post pages is changed from Read/Write to Read-only. Very very unfortunately, in this implementation, this requires a patch to core in order to work. Somehow, the comment module *always* checks the read/write setting of comment in the database. So changing access on the fly will not be picked up. Here is the bug-report: http://drupal.org/node/460596

If someone finds another way of implementing especially the last issue, feel free to make suggestions.

This patch changes the behaviour of the module pretty intensely. At the moment the patch does not make these behavioural changes optional. If you install the patch, you will have secure forum posts, and some security in comments. I think before we apply this patch, we should build in some settings that people can choose from. This version is more to gather some feedback from interested people, and the maintainers, obviously.

I had not been this deep into the drupal code so far, and i dont program php on a daily basis, so please be kind in your comments. I might learn from them.

batje’s picture

StatusFileSize
new6.2 KB

Sorry, this is the actual patch.

Anonymous’s picture

Great work. Very interesting progress.

I would say the features outlined here for private groups should be introduced and imposed as that is how a private group should work to my mind.

Anybody else have any thoughts on this ?

@batje
If you have the time would you see if your patch applies cleanly against 6.x-2.x

Best, Paul

batje’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
StatusFileSize
new5.84 KB

here is the patch

Anonymous’s picture

Assigned: batje »

Thanks, i'll review this today

Best, Paul

Anonymous’s picture

"If a group is private, only members of the group can see the forum posts in the forum. Not just by obfuscation, but those posts will also not pop up in search results or views with 'recent forum posts' etc.

Without applying the patch ..

I created a invite only / private group and it works exactly as described using OG and OG access control with only members of the group being able to see the forum container / forums and forum posts in a forum, everyone else gets access denied. Also the "New forum topics" block shows private forum posts only to members of the private group

More testing ...

markfoodyburton’s picture

Sorry for lurking.
I prefer not to have 'join the group'. For my setup (which, I can believe may be unique, I dont know) - the 'members' of the group are those that care (and may fix something for instance). The 'poster' could be a member of the group, but maybe somebody telling the group something. They should track their own posts, but they may not wish to track all posts.

In fact, in my case I really dont want people to be able to join groups.... But I do want them to be able to send to groups.

- but - maybe I missed something in the new patch?

batje’s picture

Hi,

I think i ended in total version confusion. Yes, there are a lot of similarities between my (and marks mainly) patch and group access. There are 2 main differences too:

- if you reset a group from public to private, all access-rights are reset. OG Access explicitly states it does not do that.
- in an ugly way, but still, this patch disallows people who only have read-only access to a group to post comments to forum-posts. In the end, read-only is read-only.

Perhaps we should strip out some of this patch?

Anonymous’s picture

Assigned: » Unassigned
batje’s picture

A small update.

I found a bug in the 6.x.2.x-dev version that prevents me from posting (the 'Forum' dropdown box is empty and the forum container and taxonomy terms under it disapear from both taxonomy as well as the forums), so i reverted back to 6.x.1.x-dev.

And i found something really scary:

If I create a forum post in a public forum, these are the access-rights:

node	realm	gid	view	update	delete	explained
test	og_admin	35	1	1	1	Group admins of Public Test Group may view/edit/delete this node.
test	og_subscriber	35	1	0	0	Members of Public Test Group may view this node.

Then I rebuild the access rights. And the result is:

node	realm	gid	view	update	delete	explained
test	all	0	1	0	0	All users may view this node.

That is not good. Rebuilding the accessrights should not change them. And in the configuration that i have (where the forum is set as being public), the initial accessrights are wrong. The anonymous user should have read-access to the node.

Should we work with the og people on this? Or should we implement our own accessrights, as found in my patch? To be honest, i think i favor the second. Our forumposts are not hard-core og posts. They dont necessarily have the $node->og_groups property set, and thus will behave differently.

batje’s picture

a general remark. There are so many options and combinations of them that it is very hard to debug issues. For example. my issue (http://drupal.org/node/463876 ) that says that the 'add forum post to group' link does not work only occurs when forum post is an OG group postable nodetype. This is entirely optional. I don't really get if that option is mandatory for og_forum to work or not. If so, maybe there should be a test for the condition (and we need to fix the issue). Personally, i like it more when forum posts are not og group posts. (though in that case, i need to change my code)

Also the way to make a forum public is very hard to understand. Can we simplify this in any way? Without breaking existing sites off course.

We are implementing this on a pretty big scale, so i don't mind a bit of coding.

Anonymous’s picture

Hello,

In order to make best use of my time can someone please summarize the problem reported here as a new bug using the following schema ..

Description:
Blah Blah Blah

Repeatable: Always | Sometimes

Steps to repeat:

1. Blah Blah Blah
2. Blah Blah Blah
..

Expected Results:
Blah Blah Blah

Actual Results:
Blah Blah Blah

Detail & Proposed solution:
Blah Blah Blah

and close this bug ?

Best, Paul

sun’s picture

Reminder: This is exactly the purpose of unit tests a.k.a. SimpleTests: Ensuring known functionality. Have a look at the new og_user_roles module to get an idea.

Anonymous’s picture

Yep, ill make some time to look into this.

Thanks, Paul

batje’s picture

I did too, but i wanted to spent more time.

For now, here is what i found:

- It indeed seems to work with the OG Access module. There are realms for admin access, for member access etc. These make posts private when necessary.

However.

The other way around, there is an issue. If a forumpost is supposed to be public because the forum is public, OG Access will hide it *if* the forum node-type is not an OG Postable nodetype. That is 1 line of code in the OG Access module. Funny enough, OG Forums are no nodetypes, so with this config, you can see the forum page, but its empty.

As in the installation of OG Forum it is never explained if the nodetype forum should be an OG postable nodetype, and that is indeed not necessary for OG Forum to work, this might be an issue.

glen201’s picture

Is it me, or is this OG_Forum module's security model hoplessly messed up? This issue has been open for OVER A YEAR of back and forth over the basics of this module: security - without meaningful resolution. The problem seems to lie in the fact that this is not core to OG development. It requires OG node security on top of its own security. There should be NO reason to force the Forum topic to be a OG post type (when it is, many users like me are experiencing the inability of anyone to post). This module should handle all appropriate security for the forum by itself, since forum is in core, it's going to be much more stable than integrating to a module (at least in D6).

--glen

vegantriathlete’s picture

Status: Needs review » Closed (won't fix)