Granting access to nodes: Is "nodeaccess" module good for STAR?

A. Nodeaccess for administrators:

1. ACLs

  • administer nodeaccess (decide for which node types CA module should be enabled and whether an author of the node can grant permission (view/update/delete) to this node for a specific user
  • grant node permissions (which users can grant node permission for all nodes -  but only for nodes of the type that has CA module enabled)
  • grant own node permission (which users can grant node permission for their own nodes)

2. SETTINGS

2.1. General settings

Administrator can decide which roles should be listed on individual node grants. If for example "anonymous user" role is not selected then a node author cannot grant an access to his/her node for this group.
[Important for STAR]  By settings allowed rules as shown below we are sure that any user that can grant permissions to nodes will not be able to allow anonymous user to edit any nodes.

2.2. Settings for a specific node type.

(here I will use "book" type as an example).

Admin can decide if grant tab should be shown for a spefic node type and can set default access rules for this node type. See below for an example

[Important for STAR] When testing this module I found some problems with admin settings.
Go to "Problems" to get more details.

B. Nodeaccess for users:

An example of how  "grant tab" looks like.

User can grant access for single users as well as roles but only the ones that are enabled in admin settings.

C. Problems and concerns. 

  1. Information about user access granted to specific pages is lost when module settings are updated.
  2. Even if a module doesn't give a node grants priority (set in module settings) when update of the settings is performed the module overrides access grants to all nodes that belong to to other modules like e.g. organic group.
    Real example:
    The following (book) page
    drupal.star.bnl.gov/STAR/pwg/femtoscopy-hbt/papers/pion-hbt-auau-19-6-gev/figures/figure-1
    belongs to Femtoscopy OG and is not public so only members of Femtoscopy group should see it.
    But if we install "nodeaccess" module and give a view access for an anonymous user to book pages (in this case)  [go here to see how to do it], then anonymous user can see a link above.
    To fix it one has to edit this page again (just edit and press submit) and then it will solve the problem and the page won't be seen by anybody except for member of Femtoscopy group anymore.

    [Important for STAR]
      This is on of a few reasons against installing this module in STAR Drupal because it would create a big mess.  
    If one grants "view" access to anonymous user for all book pages in module settings  then even if an OG page was not public before (visible only for selected organic group(s)) it will be seen now by an anonymous user. To fix it one would have to update all existing pages (not realistic in my opinion).
    One can say: Ok, then let's not grant a "view" access for anonymous user to book pages so we won't have this problem but unfortunately it won't work either because then all pages (even the one that already exists) won't be seen by an anonymous user. To fix it is not easier than in previous case and actually there is no straightforward way to do it. We cannot simply grant "view" privileges for anonymous user to each node because we didn't include this role in  allowed roles. The only trick that can do the job in this case is to update "node' (not nodeaccess) ACLs that should override existing privs set up by "nodeaccess"
  3. Module support: [Important for STAR]
    There is still no stable version of this module for D5.X (however there was a stable version for D4.7).
    Dev version was recently update in July and no news since then. There are many support requests on drupal.org that hasn't been addressed by author(s).

  4. Nodeaccess module (as well as CA+ACL) works good when setting up a node access for a specific user (however nodeaccess has a problem with an update described here.) However, this module doesn't provide us "protected" area type of access we need.
  5. My general concern is that this module changes existing functionality and privileges given by other modules and we don't have too much control on it.

After testing this module extensively I don't think it fits our needs (although I was very impressed by its functionality at the beginning :(

Appendix. More details by authors of "nodeaccess" module: Readme.txt

Node Access Module

This module allows you to manage permissions for nodes by role and user. In other words,
it implements per node access control for users and groups. With this module, you can
restrict access to any individual node without having to use taxonomy. You can assign
permission to view, edit or delete each individual node by user or role. Once enabled,
a 'grant' tab will appear on node pages. You can click this and assign permissions for
that node.

WARNINGS!

This is a development version for drupal 5.x. It has not been tested
extensively, and the upgrade process is rather complicated. Please do not throw
it on a production system. If you really need this module ASAP, please test it
out on a development copy of your website first.

INSTALLATION:

Put the module in your drupal modules directory and enable it in admin/modules.

If you are upgrading, be sure to run update.php as several changes are
required. This attempts to migrate your previous settings to the new setup in
drupal 5. I would strongly recommend backing up your database before installing
this module...

IMPORTANT!

Once you check the enable box and submit the page, no nodes will be accessible to anyone
other than the admin user. You just set permissions on the nodeaccess settings page
(admin/settings/nodeaccess) to enable access to your site.

The settings page has a section for roles, and then a section for every node type you
have on your site.

ALLOWED ROLES:

The allowed roles section allows you to choose what roles will appear on the node grant
tab. Just check each role you want to appear. Note that you can still set defaults for
all roles as the admin user, these options just hide what is available on each node
page.

NODE TYPE SETTINGS:

For each node type on your site, you can set default role access permissions and choose
if the grant tab should be available on that page. If the show grant tab option is
not checked, the grant tab will not appear on the node page regardless of user permissions.

For each node type, you can also choose the default permissions for that type. To emulate
standard drupal permissions, you would give anonymous user and authenticated user view permissions
for each node type. Note that once this module is first enabled, no permissions are granted, so
it is important to set defaults.

The default permissions for each node type will apply to any node which does not have
permissions set, either at the time you submit the settings or when any new node is
created. For already existing nodes, the defaults will apply only to those nodes which
have not had custom permissions set on the node grants tab.

TIPS:

If you grant authenticated users edit permission, you cannot revoke that for any user
who is a member of authenticated users. For example, if you wanted all users to be able
to edit a node except for one user, you cannot do this by granted edit permission to
authenticated users, then adding the user to the node without view permissions. Drupal
doesn't let you do that.

I haven't fully explored using this with multiple access control modules in
drupal 5 yet, so YMMV.