Suggestions for the manager interface and user roles

I’ve some suggestions for the manager interface and user roles.
With my sites I use to ’hack’ the user interface cause I don’t want some parts to appear if the user is not member of the administrators group.
Particularly, I dont want to show the part of the menu with buttons to create new docs or folders if I’ve set to no "allow root" in systems settings.
Those buttons are meaningless and can cause confusion in the user that try to create new document clicking on them and receive an alert saying that they don’t have permission to create new documents (this is particulary true with editors). Cause if I create editor rule giving permission to fully handle documents, they can really do it just from the tree, with the contestual menu.
I have seen with very pleasure that 0.95 version has only 1 manager layout. This make everything more simple, (cause before I had to hack 4 files if I want all layouts working as I need).
The check that is done to see if the user has permission to see the content menu is

This is correct but clicking on buttons another check (I don’t know where it is...) prevent the user to create a new document. I think that this check should be done when saving the page, not before. Maybe it should be better to check which parent document is selected on the tree and alert just if no one is selected (to prevent creating a new document in the root).
Another way should be to change the check to allow users to see or not to see that part of the menu. I’ve used this one by doing this.

I’ve created a new function (I’ve inserted it the the modx object making it part of the api)

(I have it with $this instead of $modx)

and changed to check like this



About this matter, in the version 0.95 I think that there is a little bug. I do the same things:
- create and editor role with full editing permission on documents but "allow_root" set to no.
- I always find "new document" and "new weblink" in the menu but due allow_root set to no they are not usable. Se also here I think is better to don’t show them, or make the control on the selected parent document in the tree etc etc... as I said before.
- I find another thing that I DONT have to find, the tools menu with import site and export site buttons available. Usign import site I actually create a document in the root also if I’m just a simple editor and "allow_root" is set to no.

I think that this things should be fixed, before to release the final version.

Bye

It seems that is a problem just for me.

In a website of a company with many figures working on it (editors, managers, P.R.s, admins etc) it is a problem.
I make a lot of rules and every rule must see only that part that can works with. No other things with which can mess up the website.
I’ld rely on Modx for build up solid corporate websites, but I don’t want to hack the admin interface to have it displaying as I expect it shoud do.
Maybe my impressions/suggestions are wrong, or maybe I should fill up a bug to make someone interesting on this?!

Version 0.95 is going to be released, and if the problem with the previous version was to have some buttons not working, now it’s worse cause I have the same buttons not working, and 2 voices that allow a not admin user to import external websites and create new documents in the root (also if I set "allow_root" in systems settings to no) and to export the whole website as static html.
I would like to have these voices accessible only for the website administrators or for other rules that I have explicitly given permissions to access.

Rules permissions are important and have to work. Isn’t it?

@kimu, have you tried the latest MODx 0.9.5 release candidate in this regards? If not, feel free to give it a test run and let us know the result, and if so, are these problems you are describing still present? If so, and you feel it’s a bug, please enter it into our bug tracker. But likely, if it hasn’t already been addressed for 0.9.5, it will have to be addressed for the release to follow.

Quote from: OpenGeek at Nov 13, 2006, 10:17 AM

@kimu, have you tried the latest MODx 0.9.5 release candidate in this regards? If not, feel free to give it a test run and let us know the result, and if so, are these problems you are describing still present?

Yes, I’ve tested that version too and the same problem is still present.

If so, and you feel it’s a bug, please enter it into our bug tracker.

Have I to feel it is a bug?! Or is a bug?! This is not my application. If you feel that this is the correct behaviour and exactly what you feel it has to be,for me is ok.
This is not a bug. I mean this is not something wrong in a function that returns incorrect values or something like that. This is something wrong in the design of the roles permissions and commands they have access to when login in the manager. It means that if I want to create rules that have access only to some commands I have to change myself the code of the manager ’cause at the moment they have actually access to commands that only administrators should have.
This prevent me, like anybody else, to create site based on modx where many people have access to the manager with different rules relying on the way modx manages these rules and relative permissions.
In a corporate website with many rules it means that a lot of users could potentially cause disaster in the website structure just because they have access to things that administrators were sure they couldn’t.

But, I act like a tester here, is not to me give importance or not to this matter. I can always change the manager satisfying my needs as I’m doing now. It’s not that difficoult.

If you leave it as it is, it’s up to the people (maybe not so in confidence with php) do the same. Otherwise, it means that I’m the only one who feels this like a not correct behaviour.

In the attached image you can see what my very undisciplined editor "patrick" (with access only to the Modx features section with permission of create, delete and edit documents only in that section, I though) has done with the import HTML command with the index.html file present in the /assets/files folder.

Exactly what I expected

Bye

If you find something that doesn’t work like it says it does, that’s a bug. If it doesn’t work the way you want it to, but works exactly as it claims to do, it is not a bug but a feature request (which still goes in the bugtracker, just under a different category).

The biggest problem here is that there isn’t a separate privilege for Import Site. The newest version of the menu is based on the actual privileges needed to run the routine - previously it was inconsistent. That’s what makes OpenGeek think that it may be better in 0.9.5. But it still doesn’t do any allow_root checks, because it’s not a required privilege to run the routine. And presumably the user could choose a new valid parent during the editing. It sounds like the following *are* bugs:

* A user without the ability to add documents to the root is still presented with 0 as the default when adding a new document.
* A user without the ability to add documents to the root is still able to Import a site.

The new version makes it easier to comment out menu lines, or change the privileges. Yes, it’s security by obfuscation, but removing the "wrong button" still makes it less likely to be pressed. If you open up manager/frames/menu.php, you can disable it easily:


This allow_root thing does sound like a logical addition for Import Site’s requirements.

On a related note, I believe that for workflow and idiot-control purposes, custom menus for users is ultimately the way forward. That way you’d be more aware of what they can see, and you could more easily have custom ’Add document’ links that default to the right parent.

Quote from: PaulGregory at Nov 13, 2006, 05:07 PM

The biggest problem here is that there isn’t a separate privilege for Import Site. The newest version of the menu is based on the actual privileges needed to run the routine - previously it was inconsistent. That’s what makes OpenGeek think that it may be better in 0.9.5.

With the new release, 0.9.5, is worse, cause with previous version the only problem was to have buttons "new document" and "new weblink" working only for administrators, but still visible if a "normal" user logged in the manager.
The tools menu with "import site" and "export static HTML" is a news of the 0.9.5 version. So this thing instead to improve is getting worse.

But it still doesn’t do any allow_root checks, because it’s not a required privilege to run the routine. And presumably the user could choose a new valid parent during the editing. It sounds like the following *are* bugs:

* A user without the ability to add documents to the root is still presented with 0 as the default when adding a new document.
* A user without the ability to add documents to the root is still able to Import a site.

* A user without the ability to add documents to the root is still presented with 0 as the default when adding a new document.
* A user without the ability to add document to the root can add new documents only selecting "add new document here" from the contestual menu clicking on the site tree (they cannot add new document to the root, but is not so comfortable). A user without the ability to add docuent to the root have buttons "new document" and "new weblink" visible in the menu but they aren’t usable, cause allow_root is set to no.
* A user without the ability to add documents to the root is still able to Import a site. (Just because he/she can see the tools menu)

The new version makes it easier to comment out menu lines, or change the privileges. Yes, it’s security by obfuscation, but removing the "wrong button" still makes it less likely to be pressed. If you open up manager/frames/menu.php, you can disable it easily:

if($modx->hasPermission('new_document')) {
#	$toolsmenu .= '<li><a onclick="this.blur();" href="index.php?a=95" target="main">' . $_lang["import_site"] .'</a></li>';
}

This allow_root thing does sound like a logical addition for Import Site’s requirements.

This is excatly what I’m doing. I have my own manager interface. But I’m sure that having my own interface can cause problems to me when I upgrade the whole system and is a solution I don’t like. I don’t like to have my personal fork of modx

The problem here is that "allow_root" is not a user setting (or rule setting) but a system setting. This means that is set to yes or no for everyone. If I do what you suggest:



Neither administrators can see that menu anymore.

If I check also the value of "allow_root":


is the same cause also administrators don’t have "allow_root" permission (it’s a system wide setting valid for everyone). So for make it valid I need to check if is an administrator



This could be a workaruond, but you don’t have isAdmin() function as part of the documentParser object. I’ve added it to my version of document.parser.class.inc.php and this works for me. Obviously, the modx system could have better procedures to make these controls, but I don’t know them and I haven’t enough time to make an deeper analysis of the code. If I had I’ll give my whole hack to fix this thing.

On a related note, I believe that for workflow and idiot-control purposes, custom menus for users is ultimately the way forward. That way you’d be more aware of what they can see, and you could more easily have custom ’Add document’ links that default to the right parent.

Good thing. It’ll be a feature of a next release of modx?

I tidied up a menu.php; there have been many versions of 0.9.5, I wasn’t comparing it to the 0.9.2 version because it is radically different (the file name is different, for one thing). I’m not sure who first switched the Import Site to be based on New Document rights.

Yes, admins can’t see ’Import Site’ if it’s commented out - but I don’t see how commenting out ’Import Site’ is an issue. Once you’ve set up the site, you’re unlikely to use the function again, and if you need it you can just uncomment it for a bit (having told all users not to touch the site because you were upgrading it).

This is similar to "allow_root" being a system-wide setting - once the Admin (or whoever) have set the site up, you can switch off some of the features that are aimed at new sites.

Having a custom menu.php is hardly a fork. The best thing to do is to duplicate your version so the copy won’t be overwritten, and refer to it each time you upgrade MODx to change things back to the way you like it.

Personally, I’d like "Import Site" to be a user config setting, just like there are settings for "Use the file manager" and
"Use the Backup Manager" - it seems the clearest thing to me. There needs to be a complete review of the user config settings, but this shouldn’t hold up the 0.9.5 release.

Quote from: PaulGregory at Nov 14, 2006, 05:05 AM

Yes, admins can’t see ’Import Site’ if it’s commented out - but I don’t see how commenting out ’Import Site’ is an issue....[CUT] ... you can switch off some of the features that are aimed at new sites.

Nothing wrong, but I think that is also your aim to give to the people a system easy to use, that don’t need being tweaked the code to have it clear and working.

Having a custom menu.php is hardly a fork.

Obviuosly it was a joke saying that I have a fork just for those trivial changes to the original code.

Personally, I’d like "Import Site" to be a user config setting, just like there are settings for "Use the file manager" and
"Use the Backup Manager" - it seems the clearest thing to me.

To me too.

There needs to be a complete review of the user config settings, but this shouldn’t hold up the 0.9.5 release.

As you want.