We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 23178
    • 22 Posts
    I cannot for the life of me figure out what I need to do here. Basically, I just want to lock down a user to only edit one page and remove additional unneeded fields as well. This was cake with managermanager and roles in evolution.

    No matter what I do I get a Permission denied and can never get into the manager with the new user.

    I have read the docs and I am still lost here. Can anyone give me a few simple steps to get me on my way?
      • 3749
      • 24,544 Posts
      Here’s one approach. Put the user in the a user group (not the admin user group -- a new one).

      Right-click on the new user group and "Update" it. Create:

      1. A Context Access ACL entry giving access to the mgr context and a policy of Administrator
      2. A Context Access ACL entry giving access to the web context and a policy of Administrator

      Be sure your use has a role in the group with an authority number equal or less than what’s needed for the two above.

      That should get the user into the mgr as a super user.

      Next, duplicate the Admin policy and switch both 1 and 2 above to that policy instead of Administrator.

      Then start taking away permissions in the duplicate policy to restrict access.

      Be careful not to change the admin Super User’s access and don’t modify the Administrator policy or you may be locked out.
        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
        • 23178
        • 22 Posts
        Ok I got in and was moving along and then I was adding some context items to my admin account that were set up for the user account and now I have really got myself into trouble.

        I took out many of the menus and resources for the end user and now with my superuser account I somehow triggered the same thing. now I have no menus for superuser account and can’t change anything back.

        Here is a screenshot of what I have done to myself.
          • 3749
          • 24,544 Posts
          I’m sorry if I wasn’t clear in my instructions. I’ve modified them to add a few warnings.
          It’s not a bad idea to Export the DB in PhpMyAdmin before messing with security so you can easily get back to where you started.

          It’s hard to tell exactly what you did because there are several things that would put you in that situation. I’m kind of guessing here, OpenGeek could give you a better answer, but I think this will do it. Before each step, delete the browser cache and cookies. You may have to delete the files in /core/cache/ also (everything but index.php). Check after each step (if you alter anything) to see if things are fixed.

          FYI, If you didn’t delete the admin user from the Administrators user group, then you either assigned a role with too high a number or a minimal access policy to that user, or edited the Administrator policy (to be avoided).

          You’ll have to do some work in PhpMyAdmin

          First, check the modx_user_group_roles table. The second entry should be the Super User. Make sure the authority level is 0.
          If not, making it 0 might fix things.

          Next, look at the modx_user_groups table. The first entry should be 1 1 1 2

          Next, check the modx_access_context table.
          The first two entries should look like this:

          1 mgr modUserGroup 1 0 2
          2 web modUserGroup 1 0 2


          If that doesn’t do it, look in the modx_access_policies table. The data field for the Administrator policy should look like this. If it doesn’t, you could paste it in in PhpMyAdmin:


          {"about":true,"access_permissions":true,"action_ok":true,"actions":true,"change_password":true,"change_profile":true,"charsets":true,"content_types":true,"countries":true,"create":true,"credits":true,"customize_forms":true,"database":true,"database_truncate":true,"delete_category":true,"delete_chunk":true,"delete_context":true,"delete_document":true,"delete_eventlog":true,"delete_plugin":true,"delete_propertyset":true,"delete_snippet":true,"delete_template":true,"delete_tv":true,"delete_role":true,"delete_user":true,"edit_category":true,"edit_chunk":true,"edit_context":true,"edit_doc_metatags":true,"edit_document":true,"edit_locked":true,"edit_parser":true,"edit_plugin":true,"edit_propertyset":true,"edit_role":true,"edit_snippet":true,"edit_template":true,"edit_tv":true,"edit_user":true,"element_tree":true,"empty_cache":true,"error_dialog":true,"error_log_erase":true,"error_log_view":true,"export_static":true,"file_manager":true,"file_tree":true,"flush_sessions":true,"frames":true,"help":true,"home":true,"import_static":true,"languages":true,"lexicons":true,"list":true,"load":true,"logout":true,"logs":true,"manage_metatags":true,"menus":true,"messages":true,"namespaces":true,"new_category":true,"new_chunk":true,"new_context":true,"new_document":true,"new_document_in_root":true,"new_plugin":true,"new_propertyset":true,"new_role":true,"new_snippet":true,"new_template":true,"new_tv":true,"new_user":true,"package_builder":true,"packages":true,"property_sets":true,"providers":true,"publish_document":true,"purge_deleted":true,"remove":true,"remove_locks":true,"resource_tree":true,"save":true,"save_category":true,"save_chunk":true,"save_document":true,"save_parser":true,"save_password":true,"save_plugin":true,"save_propertyset":true,"save_role":true,"save_snippet":true,"save_template":true,"save_tv":true,"save_user":true,"search":true,"settings":true,"steal_locks":true,"undelete_document":true,"unpublish_document":true,"unlock_element_properties":true,"view":true,"view_category":true,"view_chunk":true,"view_context":true,"view_document":true,"view_element":true,"view_eventlog":true,"view_offline":true,"view_plugin":true,"view_propertyset":true,"view_role":true,"view_snippet":true,"view_sysinfo":true,"view_template":true,"view_tv":true,"view_user":true,"view_unpublished":true,"workspaces":true}


          If everything else fails, you could do another install of MODx (using the same username and password for the admin), Export the modx_access* and modx_user* tables (but NOT modx_users or modx_user_attributes), and Import them into your site.

          Hope this helps.

            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
            • 23178
            • 22 Posts
            Thanks for getting back to me. I ended up just pulling my local build again and quickly re-doing everything I needed to. I read your article here http://bobsguides.com/revolution-permissions.html twice over before I set everything up again and it went just fine.

            Now that I have spent the past few days working with revo I have gone from confused to realizing how much easier the permissions / contexts / lexicon management is going to make my life.

            Thanks for your help!
              • 3749
              • 24,544 Posts
              Glad you got it working. smiley
                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
                • 31902
                • 342 Posts
                Sorry for dragging this topic back up but I’ve been having the same problems with a test user I created and cannot get to log in. It seems like the same issue described here.

                Before I go following this advice, which seems like quite a process (and possibly risky) for every user group I create, is there a simpler, more direct and stable method for getting a new user to be able to log in? I’m worried that this method is more of a workaround than the normal everyday method of adding a user and/or user group into the system.

                Not a criticism...just trying to learn a very promising CMS.
                  • 3749
                  • 24,544 Posts
                  Quote from: waizen at Sep 10, 2010, 09:36 AM

                  Sorry for dragging this topic back up but I’ve been having the same problems with a test user I created and cannot get to log in. It seems like the same issue described here.

                  Before I go following this advice, which seems like quite a process (and possibly risky) for every user group I create, is there a simpler, more direct and stable method for getting a new user to be able to log in? I’m worried that this method is more of a workaround than the normal everyday method of adding a user and/or user group into the system.

                  Not a criticism...just trying to learn a very promising CMS.

                  The advice was for someone who had accidentally locked out the admin Super User in such a way that they couldn’t fix things in the Manager. That doesn’t sound like your problem.

                  Maybe this will help: New users (in the Manager) need a Context Access ACL entry giving them access to the mgr context. That will let them log in, but the tree will be empty until you also give them a Context Access ACL entry giving them access to the web context.
                    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
                    • 31902
                    • 342 Posts
                    Thanks BobRay. Unfortunately, I have a bigger problem now. I started creating a new user by following the steps as outlined on your site, on this page:

                    http://bobsguides.com/revolution-permissions.html

                    Everything went fine for a while. I didn’t delete any permissions from my test user... I didn’t get to that point yet. As soon as I created the user and before going to start removing permissions, I decided to test the user’s ability to log in. With all the permissions still in tact.

                    I logged out as admin and logged in as the user. Success there.

                    ... however ...

                    After I logged back in as admin to start taking permissions out of the user’s access policy, I noticed that most (all except for two) resources were missing from my tree in the left side of the page.

                    I was careful not to touch the admin policy and sure enough, all entries seem to still be there. The administrator group is still there. I hadn’t even touched the contents of the user’s policy yet.

                    Not sure if I should have done this, but I deleted the user and just reversed the process back as best as I could. But the damage has been done. I haven’t had the time, yet, to get into the db tables with PhpMyAdmin to check things out yet.

                    Luckily, this was all just initial testing of ModX Revolution and not a client site, thank goodness. But, we do have some projects coming up that would be perfect for ModX and I really, really want this solution to work. We’re thinking of just scrapping the install and starting again, but I’m worried that the problem will just keep manifesting itself over and over. Not sure what it is I’m doing wrong. Simply adding a new user should not be such a risky thing.

                    Any thoughts? Thanks.
                      • 3749
                      • 24,544 Posts
                      I’m sorry you’re having trouble. Odd things happen when you’re learning the permission system and it’s easy to get confused.

                      If all you did was create a user, I don’t think you’d be seeing that effect. Is it possible that when you were trying to give the user rights to the manager, you also created a user group and a resource group containing the missing docs, then added a Resource Group Access ACL entry connecting the user’s user group to the resource group (instead of a *Context* Access ACL for the user’s user group)? That would block the Admin from seeing the resources (and would continue to do so even after you removed the user).

                      Normally, the only way that resources will be hidden in the Resource tree of the Manager (unless you created a tree_root_id User Setting or System Setting) is under the following conditions:

                      1. The Resources are in a resource group.
                      2. That resource group is connected to user group by a Resource Group Access ACL entry with a context of mgr.
                      3. The current user in the Manager is either not a member of the group (and the admin Super User isn’t unless you added him or her) or is in the group but in a role with too high an authority number.

                      Hope this helps.

                      If it’s a public site, I could take a look at it for you if you want to PM me with the URL and a way in.

                      BTW, when this stuff happens, the docs are almost certainly still there, you’ve just created a situation where the current user can’t see them.
                        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