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
Description

Do the DA and TAC modules work together using the multiple node access patch (similar to the DA and OG integration)?

#1

agentrickard - January 2, 2008 - 15:16

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

ben soo - January 2, 2008 - 14:18

--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

agentrickard - January 2, 2008 - 15:15

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

agentrickard - January 3, 2008 - 20:27

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

agentrickard - January 3, 2008 - 19:59

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

agentrickard - January 3, 2008 - 20:01

TAC also calls node_access_rebuild() when a taxonomy term is deleted, which will also destroy DA records.

<?php
function 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

agentrickard - January 3, 2008 - 20:22

#8

agentrickard - January 3, 2008 - 21:58
Category:support request» bug report
Status:active» patch (code needs work)

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

agentrickard - January 4, 2008 - 00:06
Version:5.x-1.0rc1» 5.x-1.0rc2
Priority:normal» critical

Upgrading to critical.

#10

agentrickard - January 4, 2008 - 03:39
Status:patch (code needs work)» patch (code needs review)

The fixes have been committed to HEAD.

#11

agentrickard - January 6, 2008 - 19:57
Status:patch (code needs review)» fixed

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

ben soo - January 17, 2008 - 03:50

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

agentrickard - January 17, 2008 - 15:33

I don't understand the question. From what system are you importing data tables? A previous version of Drupal?

#14

ben soo - January 17, 2008 - 16:39

--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

agentrickard - January 17, 2008 - 18:14

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

chaldar - January 23, 2008 - 10:30

Terrific work! I'll try RC3.

Any number of node access modules (not just two) will get AND-ed, right?

#17

agentrickard - January 23, 2008 - 13:20

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

ben soo - February 1, 2008 - 21:58

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

agentrickard - February 2, 2008 - 19:23
Status:fixed» closed
 
 

Drupal is a registered trademark of Dries Buytaert.