Is filemanager_path customisable at a user-by-user level?

Ah there`s our answer- will await next release! My solution has been to make the path to clients file a system setting and expand whenever I did wider access, not ideal but works in short term

It’s working for me, but on investigation, it’s not working perfectly, I’m seeing a couple of bugs. For one thing, my user is a member of a different user group than the admin, and, although that user group has admin access privileges for mgr and for its own context, it does not have access to the web context. I tried adding that user to the admin group, and he is then able to see all files even with filemanager_path set correctly.

The second bug is that, when the user is not a member of the admin group, when the file tree first loads it is completely empty. If I go to a resource and click on an image TV to open the browser, the file tree populates and shows only the correct subdirectory and its contents. After that, the normal file tree populates and works just fine. Since the primary function of this user is to add images, I had simply never tried looking at the file tree before opening the browser from an image TV before.

So it’s working for my specific purpose, but in general it’s not working correctly. Sorry for the confusion, I just hadn’t observed these problems before!

The bug report was filed for 2.0.5+ and hasn’t been fixed since. I’m pretty sure I had it working before (on about 2.0.2) If you look at the MODX changelog, filemanager_path crops up quite regularly

All of which I wish I knew yesterday, before spending 2 hours toing and froing for no reason. La, and indeed, la.

I’m still having this problem exactly as described. Changing the system wide settings to other dirs works flawlessly for all users, alternate paths in the user settings don’t.

The bug mentioned (3427) however is closed. Did it reappear?

2.0.7pl traditional
CentOS 5

modxxx – do you still have the issue if you update to the latest release? you indicate you are running 2.0.7pl but 2.0.8 is out. Also, it looks like the Bug # was for target version 2.1, so maybe the fix hasn’t even been added in the downloadable release yet.

It has been resolved in 2.1.0, which is not released yet.