We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 28120
    • 380 Posts
    I've got a site with 50 pages.

    I now need to add a new user that can only amend one page.

    So far I've got it so the user can only amend pages. So far so good.

    I'm struggling with the bit of just showing the one page in the tree. My attempt so far enables the user to see all the other pages but not the one in question!!

    Can anyone tell me in really simple steps how to get to the next stage of showing only one page to a specific user in the manager.

    Thanks.
    • What's happened is that you have essentially protected the one document from being accessed by the user while preventing other users from seeing what that new user can access. In other words, it's a little backwards yet. Your user can see everything BUT the protected resource, and I bet if you log in as administrator (super user) you'll only be able to see that one resource.

      from http://rtfm.modx.com/display/revolution20/Security
      "Access is allow/deny in MODx, meaning that access is "open" by default. Once an ACL is applied to an object, such as a Context or Resource Group, those Contexts or Resource Groups will now only be accessible to the objects with appropriate Permissions."


      You need to create a user group for administration that has full access, and change the new user to restricted access.

      This is explained in simple terms in the security section of "MODX - The Official Guide" which is on my lap... but it's far too much to type out and I haven't read it all anyway.

      "MODX - The Official Guide"
      Resources become protected when a user group is associated with a resource group. The users in the user group will have access to the resouces in the resource group. Other users will be denied that access unless a rule is created that gives them access as well. In MODX Revolution, the link between a user group and a resource group is created by adding an Access Control List (ACL) entry.

      The docs do contain the information but as I'm finding to be typical, Bob's book is much more clear and concise. Although the video contained in the docs is nicely done.
      http://rtfm.modx.com/display/revolution20/Security



      [ed. note: frogabog last edited this post 12 years, 3 months ago.]
        Frogabog- MODX Websites in Portland Oregon
        "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
        Having server issues? These guys have MODX Hosting perfected - SkyToaster
        • 28120
        • 380 Posts
        Thanks - I've got the book - which page?
          • Frogabog- MODX Websites in Portland Oregon
            "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
            Having server issues? These guys have MODX Hosting perfected - SkyToaster
            • 28120
            • 380 Posts
            Thanks. Having ready all of those posts I'm now feeling a little sick smiley
            • I know... I had to pause and get back to work. It effectively dampens my initiative to implement a customer based winter ski trail reporting system till likely... next winter.

                Frogabog- MODX Websites in Portland Oregon
                "Do yourself a favor and get a copy of "MODX - The Official Guide" by Bob Ray. Read it.
                Having server issues? These guys have MODX Hosting perfected - SkyToaster
                • 3749
                • 24,544 Posts
                Mark, the key is that you need to protect all resources on the site to hide them from the user.

                You do that by putting them in a resource group (let's call it AllDocs) and connecting that resource group to the Administrator group (which the user isn't in) with a Resource Group Access ACL entry.

                That hides all the resources from the user.

                Next, just create a new resource group for the user's resource(s) and a user group containing the user (I like to name both after the user).

                Put the user in the user group and the resource(s) in the resource group.

                Connect those two with another Resource Group Access ACL entry to give the user access to his or her resource(s) and you're done.

                BTW, this utility snippet will put all the resources in the AllDocs group -- it's handy if there are a lot of them (Important: you need to create the AllDocs Resource Group first):

                <?php
                /* Put all resources in AllDocs */
                
                $resources = $modx->getCollection('modResource');
                
                foreach ($resources as $resource)  {
                
                   $resource->joinGroup('AllDocs');
                
                }


                You can download the DefaultResourceGroup extra to put all future new resources in the AllDocs group automatically.

                http://bobsguides.com/defaultresourcegroup-tutorial.html



                ---------------------------------------------------------------------------------------------------------------
                PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
                MODx info for everyone: http://bobsguides.com/modx.html [ed. note: BobRay last edited this post 12 years, 3 months ago.]
                  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
                  • 28120
                  • 380 Posts
                  Thanks Bob
                    • 28120
                    • 380 Posts
                    Thanks Bob, that's all working but to be honest I'm not entirely sure I understand why/how it's working.

                    One point of confusion is what's the difference between Object and Resource in the Access Policy, see attached. For example both Object and Resourse have a 'Save' option.
                      • 3749
                      • 24,544 Posts
                      The object policy is a very minimal policy with just things like list, load, view, create, and remove. It's not used very often.

                      The resource policy has those permissions plus resource-specific permissions like duplicate, add children, move, publish, unpublish, etc. If you're dealing with resources, you almost always want to use the resource policy.

                      Of course those policies are just examples, since you might want to give some users create permission but not remove permission, for example, or give users the right to delete, but not remove resources (they get the line through them in the tree, but can't be removed from the DB). In those cases, you could duplicate the resource policy, assign the duplicate, and uncheck some of the permissions.

                      Hope that makes sense.


                      ---------------------------------------------------------------------------------------------------------------
                      PLEASE, PLEASE specify the version of MODX you are using . . . PLEASE!
                      MODx info for everyone: http://bobsguides.com/modx.html
                        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