Posted by elfur on July 31, 2009 at 2:41pm
Jump to:
| Project: | Taxonomy Access Control |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Many modules of the Access control type are marking the modules as a part of an 'Access control' package. This module should be in that category.
The importance of proper taxonomies should be well known to the Drupal community.
Comments
#1
As I said in #536636: add 'package' to the .info file , this is bad advice.
Michelle
#2
BTW, The package information in .info files is *not* a taxonomy system. See http://drupal.org/node/231036 for the proper use of package information. If we want to make the admin/build/modules page classified by taxonomy, we should do it properly and refactor the entire page. I also made a small contrib module (Module taxonomy) so people could alter the package information for the modules on their own site.
Basically, what Michelle said.
#3
Marking "won't fix" based on #1 and #2 above.
#4
I disagree with http://drupal.org/node/231036. IMO there should be an exception for 'Access control' just like for 'Development' and 'Performance and scalability'.
Access control modules have a tendency to produce unexpected/undesired results if more than one is used at the same time and the admin doesn't completely understand what he's doing. For that reason it makes a lot of sense to put them into a group of their own, so that it's obvious what is installed.
#5
@ #4: That seems reasonable to me. If someone can provide a convincing list of major access control modules that are using 'access control' as a package, and/or the doc at http://drupal.org/node/231036 comes to list this exception, I'll patch the .info. Postponing for now.
#6
See #834176-2: Unwanted pager displayed on homepage for why an "Access control" section is needed.
I've updated http://drupal.org/node/231036 — let's see what happens...
#7
Re: #6 -- you put it in the wrong part of the doc. ;) Rather than in the list, it should be with:
So MG and CA use that package. Any others?
#8
There are some other "exceptions" in the list that don't have any explanation with them. I'm not sure how much justification is needed, but extending the sentence below the list with 'and' and 'and' and 'and' somehow doesn't feel right...
ACL, Forum Access, Image Gallery Access
#9
I'm going to mark this duplicate of #538904: D8UX: Redesign Modules Page, since this is really a core issue and a question of best practices. See also: http://angrydonuts.com/on-how-to-fix-the-modules-page
In D7, access control modules can at least group their configurations at
admin/config/people, so that should improve things.#10
None of my four NA modules have their own configuration page that could go to admin/config/people.
But I sympathize with your wish to get this out of your issue queue. :-)
#11
Ah, didn't I post issues for yours? :) E.g., see #1200556: D7 IA standards: Use admin/config/people for module configuration path.
#12
No, nodeaccess isn't mine. As I said, mine don't have their own configuration page, but they blend into pages of other modules or core pages: Forum Access goes into the forum configuration, Deny Access has nothing but permissions, ACL doesn't have any GUI at all, etc.
#13
I notice that salvis has changed the Drupal.org documentation to suggest using "Access Control" packages. I think that this addition is contrary to what the documentation examples were initially trying to demonstrate, and quite a bold move considering there hasn't been a discussion resolving the 'package is not taxonomy' hurdle. He mentioned "exceptions" in post #8 but I believe he is incorrect about this and what the original author was trying to show, though I admit it isn't that clear.
The page I'm referring to is the one Dave Reid linked earlier: http://drupal.org/node/231036
I just wanted to chime in and say as someone that maintains a few node access modules, I totally disagree with using package info for "Access Control" as the module page is in it's current state.
That is a valid problem, though IMO the difficulty of getting node access modules to work together is often overstated, however putting this responsibility on the package system is an arbitrary workaround, and simply not the right answer. People may have a node access module that comes with their ecommerce system - which package do you put it in? The ecommerce system, of course, because that is the absolute by-the-book proper use of the package functionality. That ruins your plan to make it easy for users.
A module may not tout itself as a node access module, but still implements hook_node_access_records(), it isn't that cut and dry. Such modules will be mentally identified with the interfaces/projects they are related to, not with the fact that part of their functionality uses the node access api.
The Devel node access module provides excellent feedback about node access modules affecting nodes, and any troubleshooting of node access modules should be done using purpose built solutions, not by misusing the package function.
"Access Control" could also be taken as something general security/login/privacy modules might think is a good idea. Last time I looked at the Drupal.org module's page under "Content access control" the first module listed there is "Captcha". So this also runs the risk of becoming a huge mess when modules like that decide they'll put themselves in that package.
#14
EDIT: Seems like #13 was updated after initial publishing. This reply is based on seeing only the first three paragraphs.
@danielb: Do you "as someone that maintains a few node access modules" give support for your modules?
Is knowing what other node access modules are installed of interest to you?
Is ensuring that your admins know what other node access modules they have installed a concern for you?
Is alerting your users to potential conflicts between node access modules a concern for you?
As the author and maintainer of Devel Node Access (which specializes in exposing the inner workings of node access and especially conflicts among them) and a few node access modules, I cannot understand why you would want to disperse the node access modules over the Other package and 'help' the admin to lose track of them...
BTW, Forum Access has been in the "Node access" package since merlinofchaos put it there over five years ago.
OTOH, I have a hard time understanding why "Chat" would be on that list, and I don't even know what "Station" is...
#15
Overstated or not, it accounts for a significant number of support requests. Having an "Access control" package is a light-weight way to help the admins to help themselves. It may not be perfect but it helps. The guy who runs ecommerce can be expected to know about node access and DNA, but the newbie is more likely to think twice and, if he still comes for support, to be up-front and tell you that he has other NA modules running, if they're in their own package.