I've had a look at nodeaccess' code and ended it up in rewriting huge parts of it.
First of all restructured the UI for easier use. Now nodeaccess comes with an own tab for its settings for each content type - located at the content types settings.
Then the module can be used to have such fine grained permissions as one likes per content type. Per default the permissions aren't touched.
Then one could set custom role based permission per content type at its new access control tab. There it's possible to also activate a per node control of access - then users have the possibility to set role based permission control for each node.
Then as the last step it integrates with the ACL module, to provide per node per user access control! So to use this feature, one needs the ACL module installed.
Furthermore the code does a performance optimization when returning access records. E.g. if the configured role based permission wouldn't change anything, it doesn't return its settings as grants, but leaves one with the default grant. So as less grants as possible will be written to the node_access table.
The module does also correctly care of propagating default permissions to single nodes - also if you have per node permissions enabled and you are staying with the content type defaults for a node. Furthermore it correctly reacts on a content type renaming.
It also supports configurable grant priorities per content type - as the current module does with a global setting. However the ACL module needs an improvement to work with other priorities than 0.
What do you think, could this be the future of your module?
Currently there is no upgrade path (I think), but if you want I could write one.
patch attached..
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | nodeaccess_5_fago.tar_.gz_.odt | 11.38 KB | fago |
| #1 | nodeaccess_5.tar_.gz_.odt | 11.17 KB | fago |
| nodeaccess_4.patch | 35.36 KB | fago |
Comments
Comment #1
fagonote: to make us of the ACL module integration you should also apply this patch to ACL:
http://drupal.org/node/135684
to ease testing this module, I attach the whole updated nodeaccess module and the patched ACL module.
So the attachment is no .odt - rename it to .tar.gz and unpack it.
Comment #2
Anonymous (not verified) commentedEr, not sure what to make of this...
As for the UI, I tried out your change and I'm not a fan. That could just be me, I don't know. Personally I'd rather be able to configure everything in one page than have to go hunting around for all the different settings. Your way is probably more 'correct' in the drupal sense, but on sites I run that have over a dozen content types, it becomes somewhat of a pain to configure it all. For new users to drupal I think it is much simpler to just have a page where they can configure nodeaccess rather than have configuration pages for each content type. But ya know, if a lot of people want it done some other way I'm open to that. I've just never heard from anyone saying that the configuration is a problem and I personally think it's easier the way it is.
As for including the ACL module support, I've considered that, but I have no plans to do so. I don't see too much of an advantage to using it, and it requires me to rely on someone else's code that may or not be well maintained someday. For example, you had to patch ACL to work with the module. That doesn't speak too well, and for this module to be used by a large number of people I can't require it to patch other modules, that just gets too complex.
Other than that, I'm not entirely sure what it is that nodeaccess currently does not do that your changes do. In terms of functionality, what is it that the module should do differently?
Comment #3
Nikkol commentedI see the following error in my logs (lots of the same one)
in_array() [function.in-array]: Wrong datatype for second argument in E:\drupal-5.1\sites\all\modules\nodeaccess_5\nodeaccess.module on line 445.
Comment #4
Ricco commenteddo you use OG (organic groups) and if so, does this edit allow the node access to work with OG permissioning? I have found in the past if you use something like OG and TAC that the TAC settings override OG permissions, and many of my private groups become accessible. I am looking for some way to use a node access system, but have the OG permissioning be respected. Amy currently following and installing changes sugested by somebodysysop. He is currently documenting his changes, and I have performed his step one recommenations.
How do your changes compare to his?
Cheers! Ricco
Comment #5
fagohm, indeed. There isn't much what it does, what yours doesn't.
First of yours doesn't seem to apply the node-type settings correctly. It didn't write the proper nodeaccess records. Then it doesn't set sensible defaults. It also forgot its (user)settings, when they weren't written to the node_access table, because another module had higher grant priority.
Then I've a lot of content types, but I only want configure access for one. So I think for this use case, the UI I built is much simpler. But of course, that depends on the personal view.. Create a content type, manage its fields (cck) and just configure its access.. We could also provide both UI solutions?
I've also tried to optimize the module as much as possible.. (grant optimization, acls)
What mine is missing, is the configuration of available roles for the grant tab. But that could be added...
@ACL: of course, that dependence is only ok if the patch is applied to it. But I think that a solution will be possible as merlinofchaos does great work.
@rico: I've not tried this, but have you tried adjust the priority? That's possible with the module I'Ve posted as well as with the latest committed nodeaccess module.
@Nikkol: Indeed there was a bug. I've fixed that. Attached is again the whole module in the fixed version. Again the attachment is no .odt - rename it to .tar.gz and unpack it.
Comment #6
kevbo commentedLooks good, but what happened to the permissions you could set for the node "Author"? The old module had this. This is used for allowing the author to view/edit/delete only his node nodes.
Comment #7
Anonymous (not verified) commentedThe latest version fixes the priority issues, handles updating/deleting/adding node types and now sets the defaults on new installation to authenticated/anonmyous users view and author view/edit/delete. That should take care of the functionality issues.
The other two changes then would be the UI changes and using the ACL module. Like I said earlier, the UI changes are a preference, personally I prefer it the way it is as I think it's simpler for most people. If there were enough demand to warrant changing it, I'm open. I do plan to work on the grants page and redo the ui for adding user perms though as it kind of sucks, but it's basically unchanged from when I started working on this module.
As for the ACL module, I don't plan on moving over to it as I don't like to depend on other projects that may or may not be maintained in the future and I don't really see the point in a massive rewrite if it doesn't really gain anything in the long run.
Comment #8
fagoI've again worked over all the code and rewritten most -> http://drupal.org/project/content_access
Also I'm now co-maintainer of the acl module :)