We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3698
    • 57 Posts
    Hi all,
    I try to restrict editors, that are only allowed to edit/publish resource documents of a subdomain, to a certain folder in the file manager and in the Resource browser.

    Using filemanager_path and rb_base_dir settings in the Context definition I had "some" success. When the user first clicks onto a resource and after that clicks on the File tab, only files in the folder I specified are displayed. But when the user clicks onto the File tab before he had clicked on a resource the file manager shows the files in the root of the website. The user can even edit and rename them. Also, when the user edits a resource and adds an image via image icon of the TinyMCE editor he first sees the files in the root.

    I thought that it might help to specify filemanager_url and rb_base_url, but when I do this the images are referenced incorrectly. Example: When I use http://subdomain.domain.de/assets/sh_assets/ for both URL settings, the images come in with links of this kind: <img src="http:/subdomain.domain.de/assets/sh_assets/dummy216.gif" alt="test" /> , one slash is missing after the http.

    I used this subdomain approach because I wanted to avoid setting up individual filemanager_path and tree_root_ids for each user, because there will be quite a lot of them.

    Any help appreciated,
    Andrea
      • 3698
      • 57 Posts
      Some progress:
      I reduced the permissions in the Access Policy for the web context to "file_manager" and "load".
      This way the root files are no longer displayed when the user clicks onto the Files tab before he had clicked on a resource.

      But this did not help with the Resource-Browser. Here the root files are still visible. filemanager_path is set to "assets/sh_assets/" for the restricted context. The user should see the files in that folder and nothing "below". (Folders under that folder should be seen too, but that seems to be a bug and not possible in MODx Revolution 2.0.4-pl2, isn’t it?)

      Could a permission in the Access Policy for the intranet context be the "culprit"? If so, which permission could that be?

      -Andrea