Hi,
Nice module. It was funny to read on your README that you built the module for a sort of a development projects site and I was doing that exact thing.
I am also playing with the subscription module (http://drupal.org/node/29868) so developers can be notified or subscribe to both project and issues as well as comments on those nodes. I was wondering how the subscription module will plug with your access table and I found some problems. I did something which I want to share with you, but also ask you if you can think of something different. I was trying to learn how you module work, and for what I can say it just modify some queries to prevent nodes be retrieved from the DB.
So to explain better what I need to do, I would like the developers to subscribe to comments and project nodes and issues and be notified of new content post on the site, but only the content they have access to see, right now, access given by your module.
My main problem is that the subscription module does not give much attention to the node access settings. I was looking for a way to retrieve the access for a specific user on a specific node in order to make a modification to the subscription module that would work if your module was enabled and configured and also work without you as usual and I couldn't think of a specific way. I found your node_grants() hook but I am not sure if that enough to do what I want, and i saw that you rewrite hook uses the global $user, which is not what I need, as the site is notifying the rest of the users with the $user set to the user posting the content. I tried replacing the global $user with the new account I want to notify and then execute node_load (If I don't understand wrong, node_load will be rewritten with your hook_db_rewrite_sql function and return no node if its a protected node with no user terms, Am I right?). But that didn't work as expected and anyway I don't like that specific way of doing it.
So right now I ended doing up the following:
/* helper function for getting the access of a specific node for a specific user */
function _tac_lite_node_access($op, $nid, $uid) {
$user = user_load(array('uid' => $uid));
// the vocabularies containing protected info.
$vids = variable_get('tac_lite_categories', array(0));
// the terms this user is allowed to see
$tids = _tac_lite_user_tids($user);
$primary_table = 'tn';
$join = "LEFT JOIN {term_data} catd ON $primary_table.tid = catd.tid";
$where = "$primary_table.tid IN (". implode(', ', $tids) .") OR catd.vid NOT IN (". implode(',', $vids) .")";
$count = db_result(db_query("SELECT count(*) FROM {node} n LEFT JOIN {term_node} tn ON n.nid = tn.nid $join WHERE $where"));
if ( $count ) {
return TRUE;
} else {
return FALSE;
}
}
Which gives me an access boolean for a node for a specific user id, and I am executing it on my subscription module within an if ( module_exist() ) clause.
I just wanted to share this thoughts with you, check if you think there is a better think to do to the subscription module for doing this, mainly a modification that would be worth to submit to the module maintainer.
Thank you, I hope I was clear enough.
a.=
Comments
Comment #1
hanoiiSome fixes over my own code :)
Comment #2
Dave Cohen commentedIn my opinion, this is a problem with the subscription module. It's showing nodes to users who are not normally allowed to see them. And that's true regardless of which access control module is used (tac_lite is one of several). I recommend you submit an issue to that module. They might be able to fix the problem by using db_rewrite_sql, or devising their own query against the node_access table.
The drawback to that, and also to your solution, is that each subscription event now requires many database queries. At least one to learn the users grants and another to learn whether they can view the node. So its a lot of overhead if your site has many users. Perhaps the subscription module could get around this with a clever join in subscription_is_subscribed().
If your current solution works, that's great for drupal 4.7, but bear in mind that the tac_lite database schema could change at some point. That might break your queries. It's generally a bad idea to call functions from other modules if they begin with an underscore '_'.
Comment #3
Dave Cohen commentedClosing due to inactivity.