Document groups and documents not in the root

I created a document group that is allowed to edit document that are BELOW/INSIDE a folder called news. The news folder is restricted for admin only but the files in that folder are assigned to the news edit group.
but because the news folder is restricted to admins only the document below are not visible in the manager for the news editors.

frontedit could be used but would be nice if te menu could still display the folder if it contains documents that are in the allowed docgroup. maybe grayedout the folder but that its stil folds out that the documents underneath are reachable.

dimmy

Quote from: Dimmy at Apr 03, 2007, 02:33 AM

would be nice if te menu could still display the folder if it contains documents that are in the allowed docgroup. maybe grayedout the folder but that its stil folds out that the documents underneath are reachable.

That would be very handy. At present, to deal with the above situation, I have to break the document tree into sections. I put news documents under ’news’ container, which itself is not published but is available to news editors. Then I have a news listing in another document, which aggregates the news, in other section of the document tree not available to news editors. The same goes for any ’atomic’ content (like articles or products), which is to be maintained by manager users.

This way I am forced to mimic the structure of the information instead of just modeling it in the document tree. I doesn’t sound to be a sound approach.

It would be ideal if user rights (profiles) could be assigned to document groups. But at least, it should be possible for users with limited rights to travel down the document tree to work with ’their’ documents.

What do others think? Or maybe you have worked out a better approach?

No, you’ve got it. This has been tossed around for quite a while now, but there just hasn’t been a good way to fix it with the current codebase.

I can recall I saw it already, but thought someone else has already come with a better solution.

To sum it up: there’s no way to make it simpler, because it’s impossible with the codebase we have at the moment? What’s the expected release for it to change - 0.9.7, 1.0?

I think Jaredc ran into a similar problem and has a fix for it, but I could be completely off base. It should be fixed regardless. View and edit permissions seem to be inextricably linked together. :/ (I don’t like that either)

Edit does not mean "edit", it’s actually more of a "view" permission; you can look and even type stuff, but not save.

Yeah- I’ve hacked this to work several times. It might take me a few minutes but let me see if I can dig something up.

Update
Okay I found it. I think.

Go to file: manager/frames/3ldr.php and replace this code (about line 92ish):

$sql = "SELECT DISTINCT sc.id, pagetitle, parent, isfolder, published, deleted, type, menuindex, hidemenu, alias, contentType, privateweb, privatemgr 

    FROM $tblsc AS sc 

    LEFT JOIN $tbldg dg on dg.document = sc.id

    WHERE (parent=$parent) 

    AND ($access) 

    ORDER BY $orderby";

With this:

$sql = "SELECT DISTINCT sc.id, pagetitle, parent, isfolder, published, deleted, type, menuindex, hidemenu, alias, contentType, privateweb, privatemgr 

    FROM $tblsc AS sc 

    LEFT JOIN $tbldg dg on dg.document = sc.id

    WHERE (parent=$parent) 

    ORDER BY $orderby";

In one of my hack attempts I actually made it a configurable option. But somehow I lost all my code on that. Doh!

FYI, there is now an equivalent work-around via a new config value to jaredc’s hack available in the official 0.9.6 RC2 release (revision 2547). I’ve added a new system_setting (will be available from Tools --> Configuration for final release) called tree_hide_protected. After upgrading, you can change the value of this system_setting from 1 (the default inserted when installing/upgrading to 0.9.6 RC2) to 0 in the {prefix}system_settings table (via phpMyAdmin), refresh the site cache manually, and put it to the test.

And for reference, the related bug report for this is at http://modxcms.com/bugs/task/130

Anyone care to finish up a properly completed update that includes a new class for those documents? That way we could show them with a locked icon and grayed out text to denote they’re untouchable?

Quote from: rthrash at Apr 16, 2007, 01:17 AM

Anyone care to finish up a properly completed update that includes a new class for those documents? That way we could show them with a locked icon and grayed out text to denote they’re untouchable?

Within the next 1 week-2 weeks I will be diving in deep RE: Web users/Security...ready to throw a lot of hopeful combinations its way, aiming to quickly allow for "granting/restricting access" to given sections throughout the site. I will be doing this on 096 RC2+, so the new configuration option sounds like it came just in time (provided the legacy behavior does not suffice.)

The new class w/ gray/lock icons sound great!