Posted by matteo on October 19, 2004 at 10:16pm
For a site I'm building, I would need to have a private forum (opened only to certain roles) and a public one, open to all users.
How can I accomplish this without duplicating forum.module ??
Do you have any ideas working on Drupal 4.5 ??
Thanks a lot
Matteo
Comments
try groups persmissions
groups.module could be of help here.
find it here: http://drupal.org/project/groups
And if this solved you problem, would you be so kind to report back that it helped? This will help others whom are looking for the same solution.
[Ber | Drupal Services webschuur.com]
---
My Blog and Portfolio
Does it work?
Groups.module's project page still says it doesn't work, and there seem to have been only minor changes since July.
Does the CVS version of groups.module work with the 4.5 release?
I last tried it with 4.4 and experienced problems that led me to use term_access instead.
I'm now trying perms_by_role.module. My only issue is that in some cases and on some sites, I want users to be able to self-select some roles, but not others; this seems based on the "edit users" permission, and not actually related to the perms module itself, but user.module.
One unique forum with node_access enabled works fine
the solution I'm working on is based on having the standard forum module and node_access implemented by a specific security module, derived by node_access_example.module.
I attach it to this post, hoping this can help.
Every forum topic can be private or public.
Roles are given 'access private content' permission. That's all !!
If you have that permission you see the proper nodes, otherwise you don't see them.
At the moment this is fine for me...
Matteo
CODE FOLLOWS:
<?php
<?php
// $Id: node_access_security.module,v 1.4 2004/10/24 21:18:57 matteo Exp $
/**
* @file
* This is an security illustrating how to restrict access to nodes based on some
* criterion associated with the user.
*
* Database definition:
* @code
* DELETE FROM node_access;
* INSERT INTO node_access (nid, gid, realm, grant_view, grant_update,
* grant_delete) VALUES (0, 1, 'security', 1, 0, 0)
* @endcode
*
* This SQL needs to be run before the module will work properly. The installer
* system will probably perform this work in the future. The first line removes
* any existing grants, including (most importantly) the universal grant
* installed by default that gives read access to every node for everyone. The
* second line grants read access to every node for users with the "access
* private content" permission; in the scheme we're defining here, each node
* will either be private (in which case it can always be read by anyone with
* that permission) or public (in which case it can be read by everyone). We'll
* take care of public nodes in node_access_security_nodeapi().
*/
/**
* Implementation of hook_help().
*/
function node_access_security_help($section) {
switch ($section) {
case 'admin/modules#description':
return t('An security illustrating how to restrict access to nodes based on some criterion associated with the user.');
}
}
/**
* Implementation of hook_perm().
*
* In this security, we will use a simple permission to determine whether a user
* has access to "private" content. This permission is defined here.
*/
function node_access_security_perm() {
return array('access private content');
}
/**
* Implementation of hook_node_grants().
*
* Since we are restricting access based on a permission, we need to check that
* permission and return the appropriate result.
*
*/
function node_access_security_node_grants($account, $op) {
$grants = array();
//print user_access('access private content', $account); exit;
if (user_access('access private content', $account)) {
$grants[] = 1;
}
if (user_access('access content', $account)) {
$grants[] = 0;
}
//print_r($account->roles); exit;
return array('security' => $grants);
}
/**
* Implementation of hook_nodeapi().
*
* Most of a node access module's work will be done via this hook. Several
* values of $op will require responses:
*
* - "form admin", "form pre", and/or "form post":
* The module will need to provide some mechanism for the access rights of a
* node to be managed. Some sort of form element on the node editing form is
* a typical means to accomplish this.
* - "delete", "insert", and "update":
* The module must take care of updating the node_access table appropriately
* when nodes are modified, probably using the form element mentioned above.
* Only the realm(s) handled by the module should be affected, so that multiple
* node access modules can peacefully coexist.
* - "validate":
* Depending on the user interface provided in the node form, the selection
* may need to be verified and validated here.
* - "settings":
* Modules may wish to provide default grants per node type using this hook.
*/
function node_access_security_nodeapi(&$node, $op, $arg = 0) {
switch ($op) {
case 'form pre':
// We present the selection for who can view the node in the administrative
// block, so users with the "administer nodes" permission can view and edit
// the settings.
if (!isset($node->access_security)) {
// Load the grants from the database.
$result = db_query('SELECT na.gid FROM {node_access} na WHERE na.nid = %d AND na.realm = \'security\' AND na.grant_view = 1', $node->nid);
$grant = db_fetch_object($result);
if ($grant && $grant->gid == 0) {
// The "public" grant was set.
$node->access_security = 0;
}
else {
$node->access_security = 1;
}
}
$output = form_checkbox(t('Private access (only registered users can view this post)'), 'access_security', 1, $node->access_security);
return $output;
case 'delete':
// When a node is deleted, delete any relevant grants.
db_query('DELETE FROM {node_access} WHERE nid = %d AND realm = \'security\'', $node->nid);
break;
case 'insert':
case 'update':
// Clear out any existing grants for the node, and set new ones.
db_query('DELETE FROM {node_access} WHERE nid = %d AND realm = \'security\'', $node->nid);
$node->access_security = isset($node->access_security) ? $node->access_security : 0;
if ($node->access_security == 0) {
// If the node is public, we need to grant access to everyone.
db_query('INSERT INTO {node_access} (nid, gid, realm, grant_view, grant_update, grant_delete) VALUES (%d, %d, \'security\', %d, %d, %d)', $node->nid, 0, 1, 0, 0);
}
break;
}
}
?>
?]
Matteo
Re: One unique forum with node_access enabled works fine
Thanks for this! I will try it out right away.
Regards,
Czar
A partial solution with node_privacy_byrole module
I'm trying now node_privacy_byrole module, which is perfectly integrated with
4.5 (uses node_access), and this works with every kind of node, including forum, but this forces user to specify which roles will view or will update a node.
I did not try to use groups module since it forces you to apply fixes to the core, and it is not 4.5 ready.
Wher can I find perms_by_role.module ? I would like to give a try to it...
Matteo
Matteo
Not Working here
I downloaded node_privacy_byrole module and tried using it,but it is NOT showing any effect in my case.
I have 3 roles.
-Editor
-Reviewer
-Publisher
I am trying to use this for PAGE module.My initial settings are,
create pages-----Editor
edit own pages---Editor
and I unchecked above both permissions for Reviewer and Publisher because I don't want Reviewer or Publisher to VIEW or EDIT the page unless it is EDITed by EDITOR.After that EDITOR will allow EDIT permission for REVIEWER and after that REVIEWER will allow permission for PUBLISHER.Means it should flow like EDITOR->REVIEWER->PUBLISHER.
When I create a page for first time,I am checking VIEW and EDIT permissions only for EDITOR.In theory,this page is supposed to be VISIBLE and EDITABLE only to EDITOR but in PRACTICE,when I login as different users and go to left_menu->content-> ,the page is in the list of REVIEWER and PUBLISHERs also.
It is not showing any effect,please let me kno where am I going wrong.
It is urgent.
Found some modules under jonbob sandbox...
I found some modules related to permissions under jonbob sandbox.
Has someone used them on 4.5 ??
Matteo
Matteo
made for 4.5
They were made for 4.5, the node access api didn't exist before that.
--
If you have a problem, please search before posting a question.
How to use nodeperm_taxonomy ??
To solve my problem, I think that nodeperm_taxonomy could be fine for me, but I did not understand how it works.
Can anyone explain to me how it must be used ??
Thanks
Matteo
Matteo
Some problems with nodeperm_taxonomy
I'm now playting with nodeperm_taxonomy.module, which works very fine.
I created a taxonomy name 'Access Level' with 'Public' and 'Private' as terms.
I works fine for everything apart from:
weblink,
which is not fully compliant with 4.5 node_access mechanism (I opened an issue on this)
forum,
it works fine when inserting a topic, while update of a node does not update the access level (it always rememebers the access level used when inserting the topic).
Should I open an issue on this, or is it a forum design not to have more than one taxonomy ??
thanks to all..
Matteo
Matteo
Thanks for the node_privacy_byrole module
Does what I need for now, which is have public/private areas accessible.
Great.
Now just need a similar feature for attachments, that they can be put
into sub-dirs of files/, rather than just all at the top where they can clash and be accesses by anyone.
Have a quick solution for this also...
I'm happy to know it worked for you.
About file permissions, see this article.
This is a simple hack to upload.module that keeps uploaded files in synch with node_access permissions.
If one one is private, also its uploaded files are so.
It requires 'private' as download method to guarantee security.
You have all files in one dir, but its donwload is possible only through Drupal node_access permissions.
Matteo
Matteo
node privacy by role
it sounds like some folks in this thread are happy with node_privacy_byrole, but I have found that it just doesn't work. To wit:
First I tried to turn access to a public page on via node_privacy_byrole:
node_privacy_by_role indicates that anonymous users can view the node, but with "access content" off, access is denied to anonymous users.
So then I tried it the other way, turning off access to a private page via node_privacy_by_role:
node_privacy_byrole indicates that anonymous users cannot view the node, but with "access content" on, anyone can read the page.
At various points I've thought that I just didn't get it, but now I am lost. One or the other should work, or the module isn't giving anyone any privacy. I'll submit a support request, but I am hoping that someone in the community has the secret answer for me.
thanks,
-amanda
Amanda Bee
I'm hoping someone finds a
I'm hoping someone finds a good fix for this too, not having the ability to have certain forums be private (available only to a given role) is my only real complaint with the forum module.
===
YearlyKos Convention | The Blue Fund
use taxonomy_access
A forum is a taxonomy term... To set permissions on terms use taxonomy_access module.
I use it to have some forums visible only to some roles. I had to fix some things in forum.module (fix post/reply counts) and taxonomy.module (hide restricted forums from view), but basically it works.
Popular content block still shows everything
While an anonymous user is not able to view the contents of a restricted forum, the Popular Content block is still showing the links to the restricted forum entries. When I click on them (as anonymous user), I get an access denied message, but I would prefer that it not be visible in the first place.
Is it possible to control visibility of hidden content that is currently showing up in the Popular Content block (Today's, All Time, Last Viewed)?
really
Looks like Popular Content block has an issue - it should not show hidden content. See http://drupal.org/node/20391 for a fix (for Drupal 4.6).
Could make a fix for 4.5 if you need that, too.
But how does it work?
I have it intalled but I can not seem to find where you set the forums to public or private.
Fixes to forum and taxonomy modules for private forums
To menesis :
I am interested in your fixes to the forum.module and taxonomy.module. Can you release your version of the forum and taxonomy modules somewhere for download. I'm using Drupal version 4.6.3 . Thanks.
private terms for 4.6
Please see privateterms module in my sandbox. This is very simple but -- supposedly -- very fast solution. You may choose some terms which are private, and needs access private term permission to view. The nodes attached to these terms are also need this perm. Beware, the nodes attached to the children of these terms are not constrained. To help this, the admin UI selects the children of the selected terms, too.
Alas, you need patch taxonomy.module with taxonomy_privateterms.patch. However, the patch is so small that you can do it by hand with a text editor: delete the lines marked by - (there are two) and copy the + marked lines to their place, just delete the plus signs.
Let me know what do you think of it.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Not up to 4.6 yet
I'm using 4.5.2 - not sure if I should upgrade to 4.6 yet because of some of the 4.5.2 modules I'm using, but I will be looking to use it as soon as the modules I'm using make it to 4.6. Thanks a bunch.
private terms for 4.6 - OK now what
chx
I applied your patch and loaded your module. I selected the forum that I wanted private.
Now what?
private terms for 4.6
No worky worky.
Possibly because I am using 4.61.
This is the error I get when no one is logged in:
user error: Unknown column 'nameofdatabase' in 'on clause'
query: SELECT n.nid, n.title, n.type, n.status, n.moderate, e.event_start FROM node n LEFT JOIN term_node tn ON n.nid=tn.nid LEFT JOIN term_private tp ON tn.tid=tp.tid INNER JOIN event e USING (nid) WHERE (tp.tid IS NULL) AND n.status = 1 AND n.moderate = 0 AND e.event_start >= 1119047809 ORDER BY e.event_start LIMIT 0, 0 in /home/nameofwebsitedirectory/public_html/includes/database.mysql.inc on line 66.
Fixes to forum and taxonomy modules for private forums
To menesis :
I am interested in your fixes to the forum.module and taxonomy.module. Can you release your version of the forum and taxonomy modules somewhere for download. I'm using Drupal version 4.6.3 . Thanks.
private forums - yes please
I wanted to just reinforce the need for this feature - if indeed the feature does not exist - or alternatively get a clearer idea of how to make it work if it does exist.
Can I just briefly explain the context (sorry to make the post so long but my own experience is that it helps to know this kind of stuff):
Me: I'm setting up a site with the help of a mentor (Ian Dickson - thanks Ian); I have no previous experience of drupal, php, mysql or very much of anything (except COBOL 20 years ago).
My site: is for a "community of practice" of empty property practitioners, mostly in local government, to help exchange experience and provide a library of resources. There is an Executive.
Types of user:
There are basically 2 categories of "member" -
- full members who pay and should have access to the information resource
- associate members whose local authorities won't pay - so they only get access to the forums, calendar etc (there ain't a lot else)
Privacy Needs:
a) forums for members of the site, need to be private from anonymous users;
b) the forum for the executive also need to be private
(currently each of the above has its own yahoogroup)
c) while access to the info resource needs to be restricted to full members, we do not need separate forums for full members separate from other members
The problem/ideal solution
Ideally, access would be restricted at the level of forum and container. What is too exposed is for people posting to have to remember to check off a box saying "restrict this to a certain group or role", in the knowledge that if they don't their post would be public. That would be a conversation-killer. They need to feel that by posting to a particular forum by definition the post is only accessible to people eligible to participate in that forum.
BUT there seems to be no way of restricting access at the level of forum/container.
Ideally too, the site would support both "groups" (eg the executive, regional groups), a la og module, and "roles", a la simple_access module.
Solutions so far
Keeping the public out is easy, ie by allowing no content to be accessible to anonymous. But it is not an ideal solution because that also prevents them seeing pages such as the "About NAEPP" page I had created: which in turn means I'm having to construct a separate website outside of the drupal site to handle the early stage of enquiries. If I were confident that the forums were private I would have let anonymous users into the site to scout around.
Originally we started with og (organic groups). This took us most of the way but involved creating what are slightly fictitious groups such as "full member", "associate member" that actually don't really exist as groups.
I then discovered simple_access and that is what we are now using to restrict access to the information library ie set up full member and associate member roles and when adding any info resource restrict to full members only. This is easy as library content is only added by administrators and the discipline of restricting content can be part of their job. In short, simple_access does just what it says on on the tin and I'm happy with it.
But in the process I had to let go of the idea of private forums and therefore dropped og even though it came close. Ultimately - because of the way you can navigate around the drupal site moving in and out of the "group" - I did not feel that og gave us the degree of certainty I needed on privacy of posts to forums. og was top-heavy for just restricting access to the information library although it did give us the ability to do that.
What I haven't tried is taxonomy_access, the use of which is hinted at in one or two comments in this thread and elsewhere as a way of restricting access to forums and containers. If you think this might be the solution then please let me know.
Bottom line though is my posters just need to be able to post - they musn't be in the position of having to think "I must just remember to set this check-box to guarantee no one outside this forum can see what I've said".
Apologies again for the long post.
David G
Good Point
I think possibly that we might want to suggest said changes/ideas for the simpleaccess module.
Perhaps instead of many people coming up with some great ideas, we could support a good module and make it better. I know that the access system might be a good solution for a "one size fits all" solution - or at least a module that people may configure to do various things for controlling access.
I am not wild about patching the taxonomy.module since I would prefer to leave the core modules alone.
-
Shane Birley
Vicious Bunny Creative
http://www.vbcreative.com
---
Shane Birley
Left Right Minds
http://www.leftrightminds.com
taxonomy_access
Even sorrier about the long post now I can't seem to edit it!
Bottom line is that taxonomy_access does do the job, as advertised higher up the thread.
David G
True Taxonomy_access does the job
But, I would prefer to find a solution that doesn't force people to patch their taxonomy module.
---
Shane Birley
Vicious Bunny Creative
http://www.vbcreative.com
---
Shane Birley
Left Right Minds
http://www.leftrightminds.com
also
conflicts with node access by privacy
Yes, that is an
Yes, that is an understatement. The combination of the two modules can create a real mess in the node_access table. Took me quite a while to figure out the problem and then fix it.
Both modules' descriptions should mention that they should NOT be used together.
Regards
Todd
Vaules