Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I notice that nodeaccess inserts "zeroes" rows into node_access for every role on every node when the form is saved at admin/settings/nodeaccess. If I understand how the node_access table works... is this necessary? From my testing with various access control modules, an all-zero row has the same effect as no row at all: no privilieges are granted that role from that access realm. Doesn't drupal deny access to everything by default once the module is enabled? So there would be no reason to have thousands upon thousands of these essentially unnecessary rows in the database.
See moshe's post at http://drupal.org/node/73311.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | na_no_zeroes_rows.patch | 1.45 KB | xjm |
Comments
Comment #1
xjmI mean, of course, "zeroes" rows for all role/content type combos that have no privs.
Comment #2
xjmJust to give you an idea on the scale of the issue--say you have eight different roles, and several content types that only one of those roles can view. Say you have 500 nodes in those content types. You suddenly have 4000 rows in the database table when only 500 would have done the trick; your database table is eight times as big as it needs to be. The more roles you have, the bigger the problem.
I was able to patch the writing of "zeroes" rows by adding only two lines to my nodeaccess.module; let me see if I can figure out how to make a patch so folks can take a look at it.
Comment #3
Anonymous (not verified) commentedYou don't have to have an entry for each node, if and only if you are running just this access control module. If you run more than one, which many people do, then each access control module needs to have an entry for everything, otherwise you run into a lot of problems. This is just the way drupal works in 4.7. I personally have a site with around 7,000 nodes and more than a dozen roles and 2 access control modules. That adds up to around 120,000 entries in the table, which I have profile extensively and have yet to see any significant slowdown from. All the queries are indexed properly and there are no large sweeping queries (other than changing the settings which can take a while).
Drupal 5.0 introduces new mechanisms and will allow modules to declare which nodes they provide access control for and which they don't, so in the future this should be a non issue.
Comment #4
xjmHere's a patch.
Comment #5
xjmAh, I see... well, in my experience multiple access control modules don't work well together anyways, and the ones that did work fine for this change.
The effect I get (with TAC, nodeaccess, workflow_access, and path_access all there) is still that the rows with 0 view/update/delete have no effect on anything. nodeaccess can only grant privs ohter modules haven't granted, not take away ones they have. Patch is still there for anyone who wants to use it.
Comment #6
xjmOh, and you do have an entry for each node because the module inserts them every time you submit admin/settings/nodeaccess.
Comment #7
mantyla commentedIn fact, this remains an issue in the current D5 version, only it has become less acute. Now we have our own table, named nodeaccess, where the all-zero permissions are written. The good thing is that they are only written for the nodes that are edited per-node, the default permissions are not written in that table.
Also, the table gets some clutter from permissions given to deleted roles.
These are small issues, but just because they're not all that serious is no reason they shouldn't be fixed, when it is so easy to implement.
Comment #8
mantyla commentedThe issue is fixed in the 1.2 release - to an extent. It still doesn't react to deletion of roles, so if those roles had any manual grants in the nodeaccess table, they remain. But the all-zero permissions are gone.
The 2.0 release will deal with the rest: it does react to role deletion. It also solves the problem presented in the 1.2 version: if you remove all permissions from a node it reverts to default, since there is nothing left in the nodeaccess table to mark it as having manual grants. To fix this, at least one row is always written into nodeaccess for nodes having manual grants, and 2.0 introduces a way to switch back to default grants any time.