Closed (won't fix)
Project:
System Permissions
Version:
6.x-1.0-beta1
Component:
Miscellaneous
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
23 Oct 2010 at 01:27 UTC
Updated:
9 Apr 2011 at 17:21 UTC
How is this different from Site Configuration Permissions?
Comments
Comment #1
matt2000 commentedNot much. One key difference is for config_perm, 'administer site configuration' overrides it's permissions. I think it's generally a bad idea to have more than one way to grant the same permission.
Also, config_perm does not provide the permissions for individual theme configuration.
In all honesty, there is significant overlap. This is a custom module I've used for a while, and when I decided to contribute it, I did not find config_perm in my brief search.
I will add a note to the project page to draw user's attention to the alternative.
Comment #2
tim.plunkettHave you considered submitting patches to config_perm instead of essentially forking the project?
The CVS application makes this explicitly clear: "Your new project must not duplicate the work done in existing projects. Instead consider collaborating with existing maintainers."
I am confident this would not have passed CVS review.
Comment #3
tim.plunkettOh, I didn't mean to re-open this from "won't fix". But I stand by my comment!
Comment #4
matt2000 commentedI disagree with the hard-line stance against modules with duplicate functionality. I know there are people who feel that fewer modules is better than overlapping modules; I don't. Better to share code in whatever form than to prevent people from contributing.
Anyway, this isn't a fork of config_perms, at least not literally. I didn't know it existed when I first wrote this module. I was able to make time to contribute my module which was already complete, but not to write new patches for config_perm.
In any case, I'm not sure it's a good idea for two different philosophies about overriding permissions to coexist in one module. I suppose the method could be a user-configurable option, but I prefer this module precisely because it "just works" for my use cases.
Comment #5
lpalgarvio commentednoting: at this point, as of config_perms 2.x, you can add custom paths to create new permissions.
Comment #6
tim.plunkettI don't make a habit of posting on closed threads, but I'll take advantage of LPCA just doing that:
When you signed up for a CVS account, you agreed to follow Drupal's policy on this very point. It is very clear that modules shouldn't duplicate functionality. A major downfall of the current system is that once you have CVS access, you are no longer subjected to the same review process.
Comment #7
tim.plunkettI don't make a habit of posting on closed threads, but I'll take advantage of LPCA just doing that:
When you signed up for a CVS account, you agreed to follow Drupal's policy on this very point. It is very clear that modules shouldn't duplicate functionality. A major downfall of the current system is that once you have CVS access, you are no longer subjected to the same review process.
Comment #8
matt2000 commentedJust noticing the follow-up on the closed issue.
As noted on the project description page and above, the two modules are based on a different philosophy about 'overriding' other permissions. The maintainer of conf_perm has chosen a different, incompatible approach. There is no way for us to collaborate.
An alternate project is necessary in this case, and I don't believe the contributions policy is intended to prevent that, even if there is considerable overlap in the resulting functionality.