Posted by miro_dietiker on November 20, 2008 at 9:37am
http://drupal.org/project/content_access
http://drupal.org/project/nodeaccess
I think there are some more access / permission UI modules but those two look for me nearly absolutely identical except content_access uses ACL for user permissions.
BTW: I see sometimes a block "Recommendation: Related projects" when accessing projects.. who is maintaining those information? Is it automatically tag based? Because in both cases each other isn't showing up.
Comments
The related projects is
The related projects is based on scraping forum discussions with the pivots modules - so as a rule, it recommends modules that might be used together (cck and views) more often than modules which are very similar.
Managed similarity list?
It would be nice to provide a (managed collaborative) similarity list per module...
Possibly this shouldn't only be based on a modules maintainer info.. providing this information regarding module popularity would allow users to decide 'right'.
Also a way would be a similarity by tag similarity.
Is there a way to provide this?
Miro, Would this initiative
Miro, Would this initiative help with what you are looking for?
http://drupal.org/node/328932
We want complementary modules to link to each other - where known
Similarity is not enhancement
As of my understanding the field "enhanced by" won't fit at all.
While a dependency is a clear thing - extensibility is the other direction. There are some package managers like dpkg that suggests further modules when you install one. But still this has nothing to do with similarity. Similarity goes typically into the other direction, meaning incompatibility.
But the field approach could be a solution.
We could add a new field similarto[] in module .info and provide a Block with "Modules claim to be similar" and sort by Popularity
In conjunction with project usage stats if e.g. Nodeaccess claims to be similar to Content Access, Nodeaccess would be listed as such with a popularity relative to Content Access of 1044/1818 = 0.55
We always should list reverse and forward associations.
http://drupal.org/project/usage
Content Access @Oct12 1,818
Nodeaccess @Oct12 1,044
Content Access should be listed on Nodeaccess too although it's possibly a one-way similarity from Nodeaccess to Content Access.
The question now is: does drupal.org/project/xxx also interprete/import the module.info file?! It would be important to have this info on the project page and not on the users installation on drupal ;-)
Could this be a good way to provide more transparency?
um...
Um, I know it's not exactly the same realm, but
That question is exactly why I thought you may have input/interest to the thread I referred to. It's all about that question. Have a look at the thread!
And the problem with the 'duplicated' modules we find in this discussion group is that they are unable or unaware of the 'is similar to' relationship. We are NOT going to get these independent efforts to add that info if they don't know that in the first place. That's a key issue. similarto[] cannot work.
So we are starting by identifying relationships that ARE clear and acknowledged ... see what can be done from there.
I see now
It's a great location to place this idea. So did i.
Hopefully it will get attention for the DO/project redesign.
Both have problems I hope to provide an alternative soon.
I reviewed both modules for a very large client project and have been following the development of both for about six months now. I found that there were stability and usability problems with both modules. As a combined package we built four modules for Drupal 6 that are based in part on the effort of the two modules.
1) Menu Access
This module provides menu level role and user access permissions
2) Menu Item Access
This module provides menu item level role and user access permissions rules
3) Node Access
This module provides node (as in any content type) role and user access permission rules
4) Admin Access
This module extends or overrides the default administration listings to properly validate both menu, system permissions, and node access rights.
Aka hides features a user can not access by role or user account.
The key thing here other then getting the modules to all work was to make the management interface identical for all permissions management. The interface design is very similar to the content access GUI but is applied in the correct location for all menus, menu items, and nodes (aka integrated into the work flow for managing each menu, menu item, and node "page, blog, event, forum post"). I hope in the coming months to release the modules into the community. But sadly this is dependent on our client and employer's discretion.
My point, the modules discussed here are very similar but both seem to fall short at meeting the needs of large enterprise organizations and educational institutions.
Robert Foley Jr
Solutions Architect
http://www.robertfoleyjr.com
"node_access"?
While I appreciate these modules and their functionality, introducing yet another module into this space named "node_access", of all things, was a really poor choice. I realize you have a naming convention going on, but "nodeaccess" is both long standing and actively maintained.
I spend a LOT of time in the forums assisting people-- helping users choose between similar modules is already difficult enough as it is without this kind of name game. When I posted in your issue queue, I thought perhaps you just didn't realize "nodeaccess" already existed-- especially since "node_access" is really the 'proper' naming convention. Finding your post in this thread means you were fully aware of the naming conflict you created. =/
Node_Access
Another one? Wow....... http://drupal.org/project/node_access