We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 29606
    • 63 Posts
    I’ve been searching for hours and can’t seem to find how to do this...
    I would like to have a snippet that lists either all the documents that the current user has permission to access, or all the documents he doesn’t have permission.
    Can someone show me the way do to this ?
    Thanks !
      • 3749
      • 24,544 Posts
      It’s one of those things that sounds simple but takes some doing. It would involve several separate custom queries to the MODx database. (I’m assuming that you mean a web user in the front end and only care about published documents). You’d need to do something like this:

      Get a list of all published documents.
      Get a list of all documents that don’t belong to any web document group (since everyone has access to those).
      Get a list of document groups the user belongs to.
      Get a list of the documents in those groups.
      Create a master list of all of the above documents the user can access.
      Weed out any duplicate entries.
      That’s the list the user *can* access.

      Take the list of all published documents, remove the documents on the accessible list -- that’s the list the user *Can’t* access.

      There may be an easier way, but I can’t think of one at the moment.


        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 10449
        • 956 Posts
        http://modxcms.com/forums/index.php?topic=35663.0


        getAssignedDocs: Get document which the user has been assigned to them in his/her webgroups.
        getForbiddenDocs: Get document which the user has NOT been assigned to them in his/her webgroups.

        // edit: This works for Evo (0.9.6.x) only, afaik.
          • 22303 MODX Staff
          • 10,725 Posts
          huh Is this topic in the wrong forum? Or was the original question about how to do this in Revo? If this topic is for Revo...

          Once you have access permissions in place in Revo, the API returns secure data, like Resources, based on the user session, which contains their permissions. IOW, if I want to get all of the top level Resources the current user has permission to view (as determined by the access policies that apply to the user), I simply write in the snippet:
          <?php
          $objectCollection = $modx->getCollection('modResource', array('parent' => 0));
          ?>

          and when executed, the resulting collection of objects will be based on the user who’s session is active. Done. You just have to be conscious of not caching things inappropriately when you are presenting collections of potentially protected data like this.

          This means, in order to bypass the built in security policy-checking in the MODx API, you would have to cheat a little and bypass the object loading by using the lower-level PDO-based API, which is still part of MODx since it extends xPDO:
          <?php
          $query = $modx->newQuery('modResource', array('parent' => 0));
          $rowCollection = array();
          if ($query->prepare() && $query->stmt->execute()) {
              $rowCollection = $query->stmt->fetchAll(PDO_FETCH_ASSOC);
          }
          ?>


          Building a query to determine a list like you are wanting is more difficult however in Revo, because the security is now policy based, not just secure or insecure if you are in a certain group. You need the API to determine security now, you can’t just query it with some extra JOINs like you can in 0.9.x, though we can craft queries to determine some basic things without getting down to the fine-grained policy attributes.

          Perhaps if we discuss more precisely what you want to do, we can focus in on the best approach to get exactly what you want.

          If this is not meant for Revo, just ignore this post. tongue
            • 29606
            • 63 Posts
            Actually this is indeed for Revo.

            The reason for my question is that I’m still toying with Revo, and now, I have several user groups, with different access rights.

            For navigation purposes, I use a menu with Wayfinder.
            The problem is that Wayfinder displays all the links to published documents, and when a user clicks on a document for which he has no access rights, he goes to the unauthorized page.
            I feel that since that user doesn’t have access to this document, it shouldn’t appear in the menu.
            So I want to feed Wayfinder with a list of unavailable documents Id (or available documents Id , Wayfinder works with boths using includeDocs or excludeDocs)

            Hence my question. I hoped that there was a simple function which I hadn’t found for this, like ganeshXL’s class (too bad it’s only for Evo.)
              • 22303 MODX Staff
              • 10,725 Posts
              Quote from: Thalion at May 14, 2009, 03:31 PM

              The reason for my question is that I’m still toying with Revo, and now, I have several user groups, with different access rights.
              Can you describe the steps you took to apply the access permissions, what attributes you have assigned to the policies to restrict access, membership levels, etc.

              Quote from: Thalion at May 14, 2009, 03:31 PM

              For navigation purposes, I use a menu with Wayfinder.
              The problem is that Wayfinder displays all the links to published documents, and when a user clicks on a document for which he has no access rights, he goes to the unauthorized page.
              I feel that since that user doesn’t have access to this document, it shouldn’t appear in the menu.
              So I want to feed Wayfinder with a list of unavailable documents Id (or available documents Id , Wayfinder works with boths using includeDocs or excludeDocs)
              This should be automatic based on the attributes assigned to the policy that applies to the Resource Group. Again though, make sure you don’t cache Wayfinder calls that are going to be dependent on the user accessing it to render different menus.

              Quote from: Thalion at May 14, 2009, 03:31 PM

              Hence my question. I hoped that there was a simple function which I hadn’t found for this, like ganeshXL’s class (too bad it’s only for Evo.)
              It should be dead simple, i.e. automatic. And as a side note, that class posted by ganeshXL is a 3rd party, unofficial API and will not be supported by the core development team, at least not at this time.
                • 29606
                • 63 Posts
                Quote from: OpenGeek at May 15, 2009, 10:56 AM

                Can you describe the steps you took to apply the access permissions, what attributes you have assigned to the policies to restrict access, membership levels, etc.

                Here are the steps I followed :
                1) I created a User Group called User_Group_1
                2) I haded several users to User_Group_1
                3) I created a Document Group called Doc_Group_1
                4) I haded several docs, lets say doc5, doc13 and doc 22 to Doc_Group_1
                5) In "creating user group access to resource groups", I create a link with :
                - resource group : Doc_Group_1
                - user group : User_Group_1
                - Authority : 10
                - Access Policy : Ressource
                - Context : Web

                As fare as I understand access permissions, the fact that doc5, doc13 and doc22 are in a document group assigned to a user group, they should not be seen in Wayfinder when no user is logged, is that right ?
                However, they always appear, no matter what.
                Surely I’m missing something, but I can’t understand what.

                Oh, by the way, my wayfinder call is uncached, that was the first thing I checked (even disabled the whole caching, but nothing changed)
                  • 22303 MODX Staff
                  • 10,725 Posts
                  Please note, that when you change access permissions, you will need to refresh your session data or flush all sessions to have it take affect for the users. If you did this, and are checking with a user other than your default admin user (keep in mind you are automatically treated as your manager user if you are not logged into a context specifically other than mgr) or one that does not have the group membership, you should not see the record.
                    • 29606
                    • 63 Posts
                    Ok, I tried flushing i all, and no change...

                    I guess that maybe I got the whole permissions thing wrong... Can someone explain to me how it works in Revo ?
                    My goal being, as I explained, to have some documents that are only available to some user groups, and hidden for users who are not in the required groups.

                    I’m really sorry for the trouble, and once again, thanks everyone for the help !
                      • 22303 MODX Staff
                      • 10,725 Posts
                      Quote from: Thalion at May 22, 2009, 03:04 PM

                      Ok, I tried flushing i all, and no change...

                      I guess that maybe I got the whole permissions thing wrong... Can someone explain to me how it works in Revo ?
                      My goal being, as I explained, to have some documents that are only available to some user groups, and hidden for users who are not in the required groups.

                      I’m really sorry for the trouble, and once again, thanks everyone for the help !
                      No trouble; this is the last frontier in the new system to be documented and as such you are a pioneer. It may be improper configuration, or a bug perhaps. I’m going through and testing various scenarios as a prepare documentation for the new security system. It provides a lot more features and flexibility than the previous releases, but will also take some refining and getting used to, as it is a completely different approach.

                      High-level, you’ll need to create a new Resource policy without the attributes representing the permissions you want to restrict on a resource. Try taking away the view attribute from the policy you have attached as an access control list between the Resource Group you want to restrict access to and the User Group of the user you are testing with (in the mgr context for controlling view permission in the manager). You should not be able to view the object then in the mgr (and the same in the web context if you assigned that access control list to web). If you want it to disappear from the tree, remove the list attribute.

                      This is just one aspect of access control, and I’ll have a lot more thorough documentation to present with beta very soon.