MODx Bug/Feature Tracker and Feature Requests
Welcome to the MODx CMS Tracker. Please choose the appropriate project from the drop down menu and provide as much information as possible regarding your server environment and browser. Thanks!
FS#600 — Permission for Modules menu item inconsistent because of QuickEdit
Attached to Project —
MODx
Opened by David Molliere (davidm) - Wednesday, 25 October 2006, 06:15AM
Last edited by Paul Gregory (PaulGregory) - Tuesday, 21 November 2006, 02:32PM
Opened by David Molliere (davidm) - Wednesday, 25 October 2006, 06:15AM
Last edited by Paul Gregory (PaulGregory) - Tuesday, 21 November 2006, 02:32PM
| Task Type | Bug Report |
|---|---|
| Category | Core Distribution |
| Status | Unconfirmed |
| Assigned To | No-one |
| Operating System | All |
| Severity | Low |
|---|---|
| Priority | Normal |
| Reported Version | 0.9.5 beta5 |
| Due in Version | 0.9.7 |
| Due Date | Undecided |
| Percent Complete |
|
Details
The Module menu item in the manager is currently configured to allow users with module execution privilege to execute all modules :In manager/frames/menu.php line 264-265 :
<?php if($modx->hasPermission('exec_module')) { ?>
<li id="limenu9"><a href="#menu9" onclick="new NavToggle(this); return false;"><?php echo $_lang["modules"]; ?></a>
For users to be able to run quickedit, I have to set the permission to execute a module. But I don't want those users (just plain basic editors) to be able to execute every module (especially DocManager).
I think (if possible) that QuickEdit should have a permission of its own.
This task depends upon
This task blocks these from closing
Just an idea (read: very sketchy idea):
As you say, roles could be assigned on a per-module basis as opposed to having a 'one-size fits all' setting. This way, each module would receive its own custom permissions. (this kinda indicates that a new permission would be needed to give certain roles the ability to change localised module permissions)
Also, there could be globally enforced permissions (eg. the Admin role can exec a module and it can't be changed/adjusted at the module level - this functionality could be added in the 'Manager Permissions' section) and local permissions (eg. roles that can be added/removed for individual modules -this could be added as an extra tab when creating/editing a module). The advantage of this is that ownership of modules could be rolled out to certain roles without having to give them access to the main Manager Permissions section.
In the above concept, you could assign the module permissions quite easily when creating a new role, but override it as and when necessary.
Probably one to thrash out as part of the upcoming permissions review ... :)
http://modxcms.com/forums/index.php/topic,8221.msg58545.html#msg58545
And, sorry for the joke, but you mean "trash out" not "thrash out" ;) as in Ryan Thrash :P
Nah, I did actually mean 'thrash', see: http://www.allwords.com/word-thrash%20something%20out.html
Apparently it's a phrasal verb :p (useless brain fodder, lol)
Anyway, back on topic, I seen the posts about the permissions but what I'm thinking is to drill the permissions down another level and aim for resource-specific assignments. It's out of scope for 0.9.5, just a subject I'm pondering about at the moment.
It's simply unintuitive to require 'Run module' permission to have access to QuickEdit and this creates a gotcha which I think most people beginning with MODx will encounter.
My proposal is to duplicate the 'Run module' checkbox in the Roles admin section, and put it under 'Content Management' as 'Run module (required for QuickEdit access)'.
I don't know how easy that would be to implement but it's got to be easier than overhauling the security model. And starting out with MODx would be that bit easier, now.
(net value = $0.02 approx)