Logged in as administrator, but put in web context?

Am having a hard time getting some stuff to work with logged in users. I created a snippet to test the context of the user:

Which reports back 'web', even for myself as administrator of the site with super user permissions..
I have flushed sessions, permissions and cache (which after an edit I constantly have to do, otherwise I don't see the right content).

Any ideas?

If you're previewing from the Manager, your status is somewhat unusual. You're logged in to the Manager, but you're not in the Manager context (yet you can see unpublished documents). It can be confusing. If you want to see pages in the front end that require you to be logged in to the 'web' context, you need to log in just like everyone else, even though you're the admin Super User and already logged in to the Manager.

If you're trying to see what happens with other users, it's best to use another browser where you're not logged in to the Manager.

Yes, I know about the difference between logged into the manager or front end, etc. But, the issue is that even when logged in from the front end through Login snippet and in another browser, it still reports me to be in the 'web' context. The same with another user on my system that also sits in the 'mgr' and administrator context.

Setting user privs up, I followed this step through: http://rtfm.modx.com/display/revolution20/Giving+a+User+Manager+Access

modx' user/permission system has bitten me in the tail before, but now am really confused.

Sorry, I'm having a hard time following you. Assuming that you have only two contexts ('web' and 'mgr'), if you're logged in to the front end, you're in the 'web' context, no matter who you are. When any person visits the front end of the site, they are in the 'web' context and they stay there unless you do something to switch the context they are in.

By default, Login logs you in to the current context (which in the front end is the 'web' context). Users can be logged in to other contexts (or multiple contexts) with the &contexts property of the Login snippet, but I don't think that will change what your snippet returns.

Can you can explain what it is you're trying to accomplish?

I do understand now the difference between 'web' and 'mgr'. I did add the &contexts property and this ensured to be logged in the 'mgr' context. So far so good. Now I have difficulty getting the Aloha editor (from Andchir) to load for that user. The plugin checks on context fine, but bails at


I have set the roles according to the check list above and gave permissions for 'save_document' and 'save', but still won't work.

It might help to modify the code to report which permission check is failing (or write your own snippet with those two checks separated and report the results).

You probably know this, but save_document is the Context Access permission, so that check will be related to the policy that gives the user access to the current context.

The save permission is an object permission, so it will be related to the policy attached to the ACL entry that gives the user's user group access to the current Resource's resource group. If the resource isn't in any resource group, it should be an automatic pass.

That said, I'm not sure anyone has gotten the Aloha Editor to work in the front end of the current version of MODX. I know it was a real challenge getting TinyMCE to work in the front end with NewsPublisher.

Great idea, this is my user permission check snippet:

The user login passes all tests except 'save_document'. The user is in the mgr context.. as tested through the &contexts=`mgr` login snippet call. So when you say 'save_document is the Context Access permission' this confuses me. Sorry about being dense here, am trying to get a grasp on what's going on. Your help is much appreciated!

Don't feel dense, it's complicated. I only know this stuff because I've wrestled with it for many hours when trying to explain it.

Your diagnostic code is really helpful. It's telling us very clearly that the Context Access ACL entry that applies to the User's group in the current Context has a Policy that doesn't include save_document.

(More correctly, it's telling us that *none* of the applicable Context Access ACL entries for any of the User's User Groups has that permission -- though there might be only one ACL entry and one User Group involved.)

The good news is that the problem doesn't involve Resource Groups at all. The solution will definitely go on the Context Access tab.

The code needs one addition, to tell us what that Context is (though we're pretty sure it's 'web'):

Yes, that shows the 'web' context as we discussed above. I have now added the user to admin group and have added a 'web' context ACL with save_document permissions. Now it works, but as 'mgr' was reported in the session context I was confused I needed to have explicit permissions for the 'web' context.. I found it tricky to give the 'web' context these permissions. But tested it as being restricted as I hoped. Phew, that was quite a journey. Thanks for your help!
BTW: Aloha editor works as expected, needs a bit of work, so that it will also save on blur and a few other things, but for the rest it is already useful.

Does Aloha have a decent file and/or image browser? I don't think it did the last time I checked.