Crossaccess - import/merge of access permissions
| Project: | node privacy byrole |
| Version: | 5.x-1.x-dev |
| Component: | MySQL |
| Category: | task |
| Priority: | normal |
| Assigned: | mantyla |
| Status: | closed |
Jump to:
My work on the Nodeaccess module is approaching a point where I'll be satisfied with it, and so I'm looking forward to some other projects. This particular one involves Nodeaccess and potentially several other node access modules, so I'm hoping to get some discussion here.
Fairly recently I updated the HIIT primary web server from Drupal 4.7.11 to Drupal 5.7, and while I was at it, I migrated from Simple Access, which I was never entirely satisfied with, to Nodeaccess - which didn't satisfy in other respects, but I've been able to fix that. But the migration was a bit of a mess. I can write my own SQL code, and since I only had one access group for each role in Simple Access, the operation was fairly straightforward. But for many admins, migrating between node access modules and keeping all permissions intact is a pain.
My suggestion is that a new module be created - my candidate for naming it is Crossaccess - that imports permissions from one node access module and merges them with those of another. All the module is for is to help people who for some reason need to switch to another module, perhaps due to their own module not being ported to a core version they require, a feature they want that another module has, or their module simply being abandoned and receiving no more updates.
Right now we've got four node access modules which do pretty much the same thing, with some differences in their UI and/or functionality. The ones I mean are: Node Privacy by Role, Simple Access, Content Access and Nodeaccess. All four grant access to nodes based on role membership. In Simple Access access is in fact granted to access groups to which roles belong, but it comes down to pretty much the same. Content Access can also give access to users with the ACL module, and Nodeaccess does the same natively. There are plenty more access modules such as Taxonomy Access, but they do their stuff in a different way.
I don't mean to try to steal the users from any of the other modules, in fact I think it's a good thing that we have some competition - that gives users diversity to choose from. In my vision, Nodeaccess starts to look more and more like a Swiss army knife with its configurability, but it's probably overkill for several users. I'm just of the opinion that users should have that choice, even after they've started using a module and decide they don't like it, but they don't want to give up the work they've already put into giving permissions to their nodes.
So. Thoughts, ideas, suggestions?
#1
Links to other posts in the other modules:
http://drupal.org/node/286016 << Nodeaccess
http://drupal.org/node/286022 << Content Access
http://drupal.org/node/286021 << Node Privacy by Role
http://drupal.org/node/286020 << Simple Access
#2
If you look at HEAD in npbr, I removed the files months ago. I intended to retire the module with 5.x as the last version. The problem is that when I pointed to ACL/Content Access for D6 early adopters, which is what I intended to use myself, ACL hadn't even started upgrading and then when it did, delayed for D6.3. I preferred the location and layout of the configuration forms on the ACL/Content Access combo and figured with the implied flexibility of the underlying ACL module, it was the best choice.
The other problem is that I didn't create any migration path from npbr to Content Access as you've pointed out.
Then there's a larger problem.
npbr: October 14, 2004
sa: June 18, 2005
na: September 26, 2006
ca: May 17, 2007
Those are the creation dates of each access module project page. That means someone else is probably going to create another access module this year... we're due. Excuse me while I wretch about the idea of that actually happening (crossaccess included).
I don't know anything about debtman7 and it's his only module, so please excuse me while I narrow the discussion. gordon and fago make some popular code and have been around a long time. Sometimes I wish fago worked in my office since I use so many of his modules; alas that probably won't happen.
If you research it though, something that characterizes fago and gordon as opensource people is their propensity to go out of their way to create alternatives to functional, existing projects (actions/workflow-ng/state engine, htmlarea/fckeditor/tinymce/etc, e-commerce/integration projects, and npbr/ca/sa). Some of it is frustrating while other parts are cool. I suspect it is somewhat related to bad experiences with contributing patches or just the idea of not having to collaborate when you just want to get something done on a project.
x2x scripts sometimes find their way into the tricks directory of cvs.d.o contrib (http://cvs.drupal.org/viewvc.py/drupal/contributions/tricks/). If you make a na2nbpr script and put it in there, I'll link to it on the npbr project page. I just hate to see another access module page floating around.
#3
I did do some research into the history of these modules. I know Nodeaccess is based on original code by chx - how old that is, I have no idea. Also, the only new thing Nodeaccess had relative to Simple Access was the ability to grant access to users. Content Access is a spinoff from Nodeaccess - fago presented a major rewrite of Nodeaccess to debtman7, who incorporated some of the vital bug fixes but turned down the new UI and using ACL. Soon after Nodeaccess was left on a long hiatus.
I am now a co-maintainer of Nodeaccess, and in practice the only one while debtman7 is busy moving. I have just released new D5 and D6 versions, and I am working on a major update to be released in the near future. Among other things, I will take fago's suggestion of adding new tabs to each content type, and make most admin options content type specific. I have the D5 version ready, though not yet committed to CVS.
Since I've already put much of my time and work into Nodeaccess, I have no desire to further splinter the field of role-based node access modules. I intended Crossaccess to be an admin tool, nothing more. It would be useful for migrating between node access modules, and do nothing else. Of course, such a project is fairly small, and possibly doesn't warrant being a module on its own.
#4
So after all that posting, you're not interested in consolidating features into one module, you're wanting to make a conversion script between them and then still maintain separate access modules? I think that's kinda dumb. What you're doing with NA sounds like stuff that already exists in other access modules. How about gathering around one single access module - I'm willing to make the swap to CA...
#5
To be honest, I would have liked to see some competition between these modules. "May the best module win", so to speak, and since the best module may be different for different users and purposes, I was fine with there being several choices.
As for what's new in Nodeaccess 2.0 - some of it is already in other modules, but none has it all, and some of it is completely new, as you'll find:
You can disable manual and default grants separately for each content type.
By default, everything is off, and Nodeaccess 2.0 won't do anything until you configure it do exactly what you want it to do. Manual (per-node) grants and default grants need to be separately enabled. If you wanted, you could enable only one.
Priority setting has a range of -10 to 10, it is content type specific, and it is separate for manual and default grants.
The effect of this is that you can do things like use Nodeaccess with Taxonomy Access, and set default priority in NA to -1 and manual priority to 1. As a result, if a node has NA manual grants, they override any grants from Taxonomy Access. If not, Taxonomy Access overrides NA default grants. If Taxonomy Access has no grants for that node, NA defaults are applied.
You can hide any grant type and any role, and the hidden values remain unchanged when saving.
In Simple Access you could hide grants and the roles the user was not a member of, but at least the version I used had the annoying problem that hidden grants were revoked when saving. Current Nodeaccess lets you choose which grants and roles to hide, but hidden grants are preserved. In Nodeaccess 2.0, the choice of which grants and roles to hide is content type specific.
Inheritance of node grants
This feature is content type specific, and if on, new nodes of that type will inherit the grants of their menu parent.
Fine-grained control of who may grant access to nodes, and which type of access.
I realized that it might be useful to separate the permissions to grant access to roles and users, and I did. You can now let the author, members of any role, or users with edit or delete access, manage role or user grants or both on a node. This setting is content type specific.
Ability to switch a node from default to manual and back.
This seems so basic I'm surprised it hasn't been implemented before.
Search and mass grant.
This is the function I'm most proud of. You can search for nodes based on their type, manual/default grants, the role the grants are for and the exact grant. For example, you could search for "nodes with manual grants of type story where anonymous users don't have view access". And when you get the results, you can select nodes for performing mass editing of their grants.
All of the above is already in working order for D5. What I still need to do before releasing it is to document it all, since there are a lot of admin options there to explain - now you know why I referred to my vision of Nodeaccess as a Swiss army knife. You might also agree that I'm not against consolidating features into a single module, which is exactly what I'm doing with Nodeaccess. My only worry is that the module becomes too complicated for some users to configure properly, which is why I was fine with there being simpler modules also.
#6
Which just shows how divergent our thinking is.
Why not then build a conversion engine into Nodeaccess for people to convert to it from others or include a sub-module in the Na package like nodeaccess_converter.module. I don't see the point of a separate project having to do it.