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.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | og_forum_access62.patch | 5.84 KB | batje |
| #12 | accessrights.patch | 6.2 KB | batje |
| #11 | accessrights.patch | 4.15 KB | batje |
Comments
Comment #1
markfoodyburton commentedThanks 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
Comment #2
Anonymous (not verified) commented@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.
Comment #3
markfoodyburton commentedNote, 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.
Comment #4
Anonymous (not verified) commentedComment #5
rconstantine commented@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.
Comment #6
Anonymous (not verified) commentedComment #7
Anonymous (not verified) commentedIs there anyone who has reviewed this feature or would like to see it implemented in D6 ?
Thanks Paul
Comment #8
Anonymous (not verified) commented@Ryan
Would you like to review this patch and decide its fate ?
Comment #9
Anonymous (not verified) commentedAs there had been no further interest for some time i am going to close this "feature request".
Best, Paul
Comment #10
batje commentedsubscribe (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.
Comment #11
batje commentedAttached 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.
Comment #12
batje commentedSorry, this is the actual patch.
Comment #13
Anonymous (not verified) commentedGreat 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
Comment #14
batje commentedhere is the patch
Comment #15
Anonymous (not verified) commentedThanks, i'll review this today
Best, Paul
Comment #16
Anonymous (not verified) commented"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 ...
Comment #17
markfoodyburton commentedSorry 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?
Comment #18
batje commentedHi,
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?
Comment #19
Anonymous (not verified) commentedComment #20
batje commentedA 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:
Then I rebuild the access rights. And the result is:
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.
Comment #21
batje commenteda 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.
Comment #22
Anonymous (not verified) commentedHello,
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
Comment #23
sunReminder: 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.
Comment #24
Anonymous (not verified) commentedYep, ill make some time to look into this.
Thanks, Paul
Comment #25
batje commentedI 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.
Comment #26
glen201 commentedIs 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
Comment #27
vegantriathlete