I'm studing that interesting module on a enterprise site which requires a more rich permission environment than the usual drupal's by role. I've realized nodeaccess installs a new nodeaccess table (considering current core node_install). I've even seen that it has the same fields. I'm a wrong or is it a reason?

Comments

Anonymous’s picture

Anonymous (not verified) commented

This module needs it's own table because other node access modules can tell drupal that they have made widespread changes and drupal needs to rebuild it's node access table. Drupal then asks all the access control modules what their grants are. In short, this module needs to be able to tell drupal at any time what the permissions on any node are, and the only way to do that is to store that information in it's own table. This didn't have to happen before drupal 5, but the api changes in 5 made this necessary. In order to minimize the use of space, I only store any grants that are different from the defaults, so any nodes that have the default permissions defined on the admin page aren't using up extra table space.

jorditr’s picture

jorditr commented

Ok, thanks.

jorditr’s picture

jorditr commented

BTW, that would be that way for nodeaccess to coexist with for example tac_lite? Aparently tac_lite uses default drupal's node_access table. I'm asking all that before install them just in case both modules conflict and can ruin my installation :-)

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (fixed)

drupal manages the node_access table. Access control modules simply tell drupal what permissiosn they have for a node, how it's handled after that and stored in the node_access table are up to drupal.