Login!
Lost password?
 

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#130 — New tree state indicating user non-privileged file/folder

Attached to Project — MODx
Opened by Jared Carlow (jaredc) - Wednesday, 23 November 2005, 07:16AM
Last edited by Ryan Thrash (rthrash) - Thursday, 25 September 2008, 09:36PM
Task Type ToDo
Category User Interface
Status Implementing
Assigned To Garry Nutting (garryn)
Operating System All
Severity Medium
Priority High
Reported Version 0.9.0
Due in Version Undecided
Due Date Undecided
Percent Complete 30%

Details

I believe a valuable new state to the document tree could be added: that is the "untouchable" state. In other words, when a user logs in to the manager who does NOT have editing rights to root level folders, within the current tree, there would be nothing to see. However, I think a valuable option (perhaps in the site config settings) would be an option to "Show full tree."

Right now there are a couple colors that designate status in the tree:
Green- published
Red- unpublished

A new color could be added - perhaps gray, or better I think, some sort of orange/yellow (which might imply "yeild"). Documents in this color will hold a spot in the tree for structures sake, but is actually not linked so it cannot be edited. An orange/yellow folder could be expanded to show contents (which may or may not be editable). This would allow a non-administrator to surf the tree to their section, without being able to hit the edit screen on any between the root and the actual pages they have access to.

I realize some may not want this option, and therefore it seems it could be a configurable option to administrators, perhaps under the "User settings" tab of sys config.

This would be a tremendously valuable addition to those of us who have content editors who have rights to large branches well below root level.
This task depends upon

This task blocks these from closing
Comment by Brett (The Man Can!) - Wednesday, 23 November 2005, 11:12AM
An option that might be better would be something like "Show uneditable parents that contain editable children in tree" instead of the "Show full tree" option. I really like hiding content that a user can't edit; If a site has a lot of content, showing non-editable content only confuses users and makes it harder for them to find what they /can/ edit.

So, if the content tree looks like this:
Folder A
--content
Folder B
--content
Folder Schools X
--Folder School Y
-- -- Content
--Folder School Z

User Y has access to edit only Folder Y and not Folder X or anything else. I don't want User Y to see Folder A or B or Z, but Folder X needs to appear in the tree. Ideally, Folder X would be grayed out and expanded by default. (Because it obviously is only being displayed for it's children, having it expanded by default seems natural.)

I agree that this would be tremendously valuable and would make content-heavy, multi-user sites (like multi-user blogging or community directories) a bit easier to manage.

Comment by Jared Carlow (jaredc) - Wednesday, 23 November 2005, 02:00PM
I agree that this alternate mode of showing ONLY the branches of the tree that are relevant to the user would be a nice way to keep the tree pruned, but still accessible. And perhaps then in config three options would be available: Full tree, allowed branches, allowed from site root (current).

On the other hand, this could potentially be processor intensive as the tree would have to create all the branches FIRST to find pages that were allowed- then backtrack to show only those branches with "leaves" (so to speak) that are editable. This goes against the dynamic nature of the tree. Not that it couldn't, or shouldn't, be done this way, but there is an obvious processing overhead that has to be considered. This would be especially true on larger sites, and would slow the performance of the tree.

Comment by Brett (The Man Can!) - Tuesday, 29 November 2005, 01:27PM
Just my thought, but it's going to take processing power either way, and I'd much rather it take the server an extra couple tenths of a second to prune the tree, rather than take tens of seconds for the browser to download and then apply javascript to a huge tree (that can't even be edited). PHP's *way* faster than javascript, so I think this might actually improve the speed of the tree.

Also, the more I think about having the nodes/branches expanded by default, the more that seems like another great step for idiot-proofing (and simplifying) the whole process for the users. Thanks to whoever is handling this! It will be a fantastic when it's implemented.

Comment by Ryan Thrash (rthrash) - Tuesday, 28 March 2006, 03:33PM
  • Field changed: Due in Version (Undecided → 0.9.2/0.9.2.1)
See this for a partial solution:
http://modxcms.com/forums/index.php/topic,2316.0/topicseen.html

Comment by Ryan Thrash (rthrash) - Sunday, 13 August 2006, 04:49PM
Deferring this for 1.0 release and new manager. Definitely needs to be done, but more appropriate at that time I feel.

Comment by Jason Coward (opengeek) - Monday, 16 April 2007, 12:10AM
  • Field changed: Status (New → Implementing)
  • Field changed: Due in Version (1.0 → 0.9.6)
  • Field changed: Percent Complete (0% → 30%)
  • Task assigned to Jason Coward (opengeek)
I have implemented a quick way to get around this in trunk for 0.9.6 RC2; you can set the setting_value to '0' for setting_name = 'tree_hide_protected' in the {prefix}system_settings table. The installer will add this system setting with a value of '1' if it does not already exist in the system_settings table.

A control for toggling this behavior will be added to the Tools -> Configuration for 0.9.6 final.

Comment by Marc (MadeMyDay) - Tuesday, 06 November 2007, 04:42AM
Any news on this?

If a user can edit a document in a folder which he can´t access, he doesn´t see the document he is allowed to edit. I attach a patch from the forum (works in 0.96 and 0.96.1), seems a bit quick and dirty. But I think it is a very important feature. Would be nice to have it configurable.
  nodes.zip