When you use a Node Access filter using the Node Relationship that isn't required, you basically make it required. Meaning, any Activity that doesn't have a nid is filtered out as the WHERE constructed by this handler (views_handler_filter_node_access.inc) forces the message to have a record in the node_access table.
Couple solutions
1.) bring back the hook_rewrite_sql(). it worked but is fragile
2.) Write a JOIN from node_access to activity on nid in hook_views_data_alter() and provide a handler to handle it
3.) use hook_views_data_alter() to replace the node_access filter with our own that is smart about the relationship (meaning that it does different things when the relationship is required or not)
Ideas?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | activity_605670.patch | 796 bytes | Scott Reynolds |
Comments
Comment #1
Scott Reynolds commentedThis is the first solution, I reverted this change http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/activity/ac...
Comment #2
Scott Reynolds commentedOk I ended up committing this. But I will leave this open for discussion
Do we assume, as this patch does, that all items with nid must be viewable by the currently logged in user. Seems to be an obvious yes.
But the result of this is that the query will always contain this stuff. Even if you only want public results (meaning the node_access is 'all' rid = 0). This is important for sites where users panic when they see their stuff in an area that is viewable by all. In those cases in the past, I have written an additional handler that removes all but the public posts. So the query looks like
"FILTER to those i have Access too AND filter only to those that are public" Now thats not the most optimum query, but I think we can leave it to MySQL (etc) to optimize it.
Comment #3
sirkitree commentedI think we need to assume that a user should have access to the node in order to view activity about it, def.
It would be nice if we only checked node_access if the activity dealt with a node, hence rewrite_sql - I think this solution is fine
Comment #4
Scott Reynolds commentedOk cool. As long as were in agreement.