Contexts aren't working in beta-1

I’m running Beta-1 on MySQL 5.1.32, PHP 5.2.9 and having a little trouble with contexts.

I’ve created a user group which will have permission to manage a context, and created a user and added them to that group.

I’ve then created a new context, assigned the user group permission to the context, then tried to login as the user.

On login, the user gets: "Error! Permission denied!" with a logout link. When you click Logout, you get: "{"success":true,"message":"","total":0,"data":[],"object":[]}."

When you then log back in as the Admin user, the context has vanished, but it’s still there somewhere because you cannot create a new context with the same key (get an error.)

Should this be filed in JIRA? It’s a shame really, I was hoping I could use contexts properly in beta-1 (they worked in alpha-6.)

Otherwise good work!

Quote from: Pandy06269 at Jun 10, 2009, 03:44 PM

I’ve created a user group which will have permission to manage a context, and created a user and added them to that group.

I’ve then created a new context, assigned the user group permission to the context, then tried to login as the user.

On login, the user gets: "Error! Permission denied!" with a logout link. When you click Logout, you get: "{"success":true,"message":"","total":0,"data":[],"object":[]}."

The only thing that controls login to the mgr are permissions to the mgr context. The user will have to be a "Super User" member of Administrators to login to the mgr context with the permissions provided out of the box. Assigning Context policies to contexts other than mgr is a way to provide permissions for users to perform content management activities FROM scripts in that context. It has nothing to do with content management of that context.

Quote from: Pandy06269 at Jun 10, 2009, 03:44 PM

When you then log back in as the Admin user, the context has vanished, but it’s still there somewhere because you cannot create a new context with the same key (get an error.)

If you assigned a policy to the new context, make sure the Administrators group can access it. This gets a bit complex, and there were some bugs in beta-1 that have already been fixed that will show up if you try to add more than one policy that applies to a single person, but it should basically be working as expected. Context policies serve both as policies for managing access to the Context itself (can I even load the data object), as well as providing attributes which define permissions to perform various actions when taken from that context (can I save changes to a Chunk from a script running in the mgr context, or similarly, from the web context).

Again, I know this seems quite complicated, and in some aspects it is, but once we better document how this all fits together, I think you’ll be pleasantly surprised at the things you can do with it.

Jason,

Thanks for the prompt reply.

Quote from: OpenGeek at Jun 10, 2009, 05:13 PM

The only thing that controls login to the mgr are permissions to the mgr context. The user will have to be a "Super User" member of Administrators to login to the mgr context with the permissions provided out of the box. Assigning Context policies to contexts other than mgr is a way to provide permissions for users to perform content management activities FROM scripts in that context. It has nothing to do with content management of that context.

Ah OK, that’s my mis-understanding. Is this sort of behaviour planned for MODx Revo? I.e. being able to create a user group (or whatever) so that certain users can only see and manage defined contexts?

I guess the difference in user behaviour is that there are no longer "web" and "manager" users, just "users", right?

Also how would we go about creating a user that can login to the manager and edit content, but couldn’t touch the "system-wide" settings, such as contexts and configuration etc?

Quote from: OpenGeek at Jun 10, 2009, 05:13 PM

If you assigned a policy to the new context, make sure the Administrators group can access it. This gets a bit complex, and there were some bugs in beta-1 that have already been fixed that will show up if you try to add more than one policy that applies to a single person, but it should basically be working as expected.

Yes I did apply a policy to this context, unfortunately this context is not showing up anywhere in the system for the admin user. On a side note (I will raise this in Jira) you can’t edit a user group - you click the "Update User Group" menu item and it just shows the form for creating a new group.

Now I’ve managed to login as my "normal" user, that context isn’t showing up for them either! I guess the only way to get it back is delete it from the db directly?

Quote from: OpenGeek at Jun 10, 2009, 05:13 PM

Again, I know this seems quite complicated, and in some aspects it is, but once we better document how this all fits together, I think you’ll be pleasantly surprised at the things you can do with it.

Yeah this does sound well over my head at the moment (even with 0.9.6 I’d only done fairly basic stuff in terms of changing the core behaviour of MODx so all this in Revo is like functionality-overload!) I can’t wait until I can get onto play with it full time (I’m dedicated to a non-web project at the moment.)

Note: user group issue filed as http://svn.modxcms.com/jira/browse/MODX-797.

Quote from: Pandy06269 at Jun 11, 2009, 05:56 PM

Ah OK, that’s my mis-understanding. Is this sort of behaviour planned for MODx Revo? I.e. being able to create a user group (or whatever) so that certain users can only see and manage defined contexts?

Yes. Even, with ABAC controls, if you so desired, you can get even more fine grained - you could give a user access to save only Chunks in the ’foo’ context by using a custom Access Policy.

I guess the difference in user behaviour is that there are no longer "web" and "manager" users, just "users", right?

Correct - they have been merged. Now users span all ’contexts’ (web/mgr are two separate contexts), but can be restricted to only have access to one, both, or neither.

Also how would we go about creating a user that can login to the manager and edit content, but couldn’t touch the "system-wide" settings, such as contexts and configuration etc?

Access Policies. We’re definitely working on documentation - and a better UI - for those.

And, as Jason said, there’s been some bugs with Security-related stuff; specifically with having more than one policy per user group per context, which is fixed in SVN. We’re trying to make releases more frequent as well; hopefully we’ll have another release (beta-2) here soon.

Quote from: Pandy06269 at Jun 11, 2009, 05:56 PM

Yes I did apply a policy to this context, unfortunately this context is not showing up anywhere in the system for the admin user. On a side note (I will raise this in Jira) you can’t edit a user group - you click the "Update User Group" menu item and it just shows the form for creating a new group.

Now I’ve managed to login as my "normal" user, that context isn’t showing up for them either! I guess the only way to get it back is delete it from the db directly?

What attributes are defined with a value of true in the policy you have assigned to this context? Here are the attributes you will need, at a minimum, for it to show up:

[table]
[tr][td]list [/td][td]true[/td][/tr]
[tr][td]load [/td][td]true[/td][/tr]
[tr][td]view [/td][td]true[/td][/tr]
[/table]

The load attribute is the key; this indicates if the object instance can even be loaded from the database.
The list attribute indicates if it can be seen in the tree views (i.e. can be listed).
The view attribute indicates if it’s data can be viewed (more relevant to Resource policies than to those intended for Contexts).

Here are some additional "generic" policy attributes that affect what you can do with an object if you can at least load it:

[table]
[tr][td]remove [/td][td]true[/td][/tr]
[tr][td]save [/td][td]true[/td][/tr]
[/table]

The remove provides permission to delete the row( s ) in the database table( s ) associated with the object instance.
The save provides permission to save changes made to the object properties into the database.

There are a lot more "generic" policy attributes for Resources that I will describe as soon as possible in the documentation, including things like add_children, publish, unpublish, delete, undelete, etc.

Quote from: OpenGeek at Jun 11, 2009, 10:00 PM

What attributes are defined with a value of true in the policy you have assigned to this context? Here are the attributes you will need, at a minimum, for it to show up:

[table]
[tr][td]list [/td][td]true[/td][/tr]
[tr][td]load [/td][td]true[/td][/tr]
[tr][td]view [/td][td]true[/td][/tr]
[/table]

Apologies for not getting back to you sooner - where can I find these attributes and their associated values?

My previous contexts are listed in modx_context, there’s nothing in modx_context_resource and no settings related to my context in modx_context_setting. I couldn’t see anything else that looks relevant in the database.

Thanks.

Actually I think I’ve just found it in the manager. If I go to "Security" > "Access Policies" there are only two listed - resource and context. Both have all attributes set to true.

Also if I go to "Security" > "Access Permissions" nothing is listed for either context or resource permissions. I’m sure I assigned my user group to the context.

I’ve just tried again and made a note of what I did (all as Administrator.)

1. Create context test.
2. Logout, log back in, check it’s still there - yes
3. Assign the Context access permission to the test context and Administrator user group
4. Logout, log back in, it’s vanished.

The only thing of interest in the error log is:

[2009-06-19 17:10:52] (ERROR @ /connectors/context/index.php) modManagerLog: Attempt to set NOT NULL field item to NULL

Quote from: Pandy06269 at Jun 19, 2009, 11:15 AM

I’ve just tried again and made a note of what I did (all as Administrator.)

1. Create context test.
2. Logout, log back in, check it’s still there - yes
3. Assign the Context access permission to the test context and Administrator user group
4. Logout, log back in, it’s vanished.

What authority did you give in the access permission you created for the test context and what authority does the user have in the Administrator group? That is the key. If you did not make the user a Super User (authority 0) rather than Member (authority 9999) and you gave the Access Permission an authority of 0, he will not be able to see the context.

That said, this could possibly be related to a bug that was fixed just after the release of beta-1, though I doubt it. Regardless, I’ll get some merging done later today and we’ll try and release a beta-2 ASAP so you can see if that is the problem, should Authority prove not to be the issue for you.