DA and TAC with multiple node access patch?
chaldar - December 31, 2007 - 07:26
| Project: | Domain Access |
| Version: | 5.x-1.0rc2 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Do the DA and TAC modules work together using the multiple node access patch (similar to the DA and OG integration)?

#1
This issue is looking for testers.
Update: this original note is false, see comment #3.
[Note that TAC has its own patch to node_access, I believe. So tests for both cases should be run. ]
#2
--far as i know TAC doesn't patch the Drupal core, and i was using it for 7 months or so.
b
[edit. i forgot to say: Happy New Year to you, agentrickard]
#3
ben soo is correct. I confused TAC with another module that used the nodeapi 'access' patch approach.
Since TAC uses the standard node_access system, there should not be a conflict. So this is a good test of the mutliple_node_access patch, which was tested against OG.
#4
Testing.
Bad things happen to DA when node_access_rebuild() is run. It seems that the issue is related to the fact that node_access_rebuild rewrites all existing node access rules. Among other things, the domain_all grant is removed entirely.
With the Domain Content module, you can restore these, but it's still an issue.
The short answer to the original question is "No. Not unless you never delete a term or disable TAC after you install the two modules."
#5
This is, IMO, a flaw in the node_access system. node_access_rebuild() _by design_ erases the {node_access} table, which means that the node_load() that executes later in the function can no longer read the existing Domain Access rules, which were stored -- and deleted -- from the {node_access} table.
http://api.drupal.org/api/function/node_access_rebuild/5
#6
TAC also calls node_access_rebuild() when a taxonomy term is deleted, which will also destroy DA records.
<?phpfunction taxonomy_access_taxonomy($op, $type, $array = NULL) {
// ....
case 'delete': // delete everything from term_access and node_access
db_query('DELETE FROM {term_access} WHERE tid = %d',$array['tid']);
node_access_rebuild();
break;
}
?>
#7
See http://groups.drupal.org/node/7956 for discussion.
#8
If I store all the DA node_access rules in a {domain_access} table, then this integration seems to work fine.
Calling this, officially, a bug. I have new code ready to implement this.
It means I must release an rc3 now, which must be tested all over again, since I made a fairly major change to the module architecture.
#9
Upgrading to critical.
#10
The fixes have been committed to HEAD.
#11
Active in RC3. DA and TAC should play nice now. The multiple_node_access patch is needed only in the following cases:
-- If you want DA to check its grants in addition to TACs. (Drupal default is either DA or TAC).
-- If you want to use the "domain editor" functions of DA.
#12
i've just been reading through your entries concerning this issue. That's pretty amazing detecting and debugging, agentrickard, not to mention an admirable tenacity.
So i guess that's what i ran into, this node_access_rebuild() thing? It seems to've caused repercussions beyond the DA module which i can't pin down or fix, and so am moving the site to a fresh install which will have DA RC3.
Going to see for sure whether it'll coexist with SomebodySysop's OG User Role.
Finishing up the prep work; almost ready to start importing the existing content tables into it. Just beginnig to figure out which DB tables have bits of our content in them.
--This is a feckless question and i apologize beforehand: do you have recommendations on which tables i should specifically avoid importing, in order to be sure of leaving behind any problems that might've been caused by this issue?
thanks,
b
#13
I don't understand the question. From what system are you importing data tables? A previous version of Drupal?
#14
--From the same D5.6 version into a fresh installation. The old installation is giving me theme problems whereby the 4 or so different themes i use in various parts of the site all revert to the system theme once i switch on OG User Roles. Even the administration theme goes away.
The new installation, so far, with a similar but smaller set of 3rd party modules, isn't giving me this problem. Everything co-existing nicely.
#15
Well, I can't really answer the table import question. Some thoughts:
- DO NOT IMPORT
- cache_*
- variables
- DO IMPORT
- node*
- term_node
- term*
- vocabulary*
- sequences
You might be better off with a node import migration.
As for og user roles, check to see if it overwrites the $custom_theme variable anywhere -- usually this happens in hook_menu().
We should leave this issue and start new ones if you run into issues with OGUR.
#16
Terrific work! I'll try RC3.
Any number of node access modules (not just two) will get AND-ed, right?
#17
Not exactly. The patch support AND or OR logic for all node access modules. However, only DA implements it.
So, if you have 4 node access modules, your queries can be either:
NA or OG or TAC and DA
-or-
NA or OG or TAC or DA
Where the second is the current and default behavior.
#18
That was great and wonderful advice, that i shouldn't import the "variable" table.
i've put our site back together under a new install and have been proceeding with its construction. RC4 is generally nice on the site, except Domain Theme doesn't play nice with Taxonomy Theme: they both make use of $custom_theme .
i'll file a separate issue for that. i've already done so in the issue queue of Taxonomy Theme.
b
#19