template variables and categories have dissapeared [SEMI-SOLVED]

So all of a sudden my template variables and categories have dissapeared from the Elements tab of the manager. The parent item/folder appears but it has no children.

I was creating a new user group for site editors, being careful not to touch the administrator group, now all of a sudden this started to happen. I’m not sure if it was something I did or just coincidence. I did look in the database and the TV are still present. The site also displays the content that was in those templates.

Also when editing the documents, the TV don’t display although categories do.

I’m left scratching my head here. Does anyone know what would cause this? I really don’t want to loose all of the work I have already put into this site.

Thanks
Brian

Sounds like you assigned a category access control entry to the new user group you created without giving your Administrator group access to it first. Maybe?

Thank you OpenGeek for taking the time to help me trouble shoot this.

I have since deleted the group I created (trying to figure out what was going on) and that didn’t break them back.

To summarize what I did.

I created a new user group "Editor"

Created an access policy "File Editor" allowing access to the files manager. (based this on the admin template.)

Added Manager context access to this new policy and the content policy.

I did not add a resource group.

Then I added an element category access to the mgr. the category was left blank and the access policy was load,list, view.

Everything I added had a minimum role of "Editor" the new group I created.

I assume this last step is what you are referring to but by deleting the new user group, should that have corrected it?

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

Then I added an element category access to the mgr. the category was left blank and the access policy was load,list, view.

Left blank? If you did not assign this to your Administrator group, and only to the Editors group you added, then that is why you cannot see them.

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

Everything I added had a minimum role of "Editor" the new group I created.

Roles are not Groups, so I’m confused by this statement. I would leave Roles alone and just always use Member unless you know what you are doing with Roles already.

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

I assume this last step is what you are referring to but by deleting the new user group, should that have corrected it?

You will need to remove the access control entries that you had linked to that new user group or manually add one in the database for your Administrator group. Whenever you restrict access to something, always restrict access to the Administrators group first, otherwise, only the group you assigned the policy to will be able to access it.

Quote from: OpenGeek at Jan 27, 2011, 06:41 PM

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

Then I added an element category access to the mgr. the category was left blank and the access policy was load,list, view.

Left blank? If you did not assign this to your Administrator group, and only to the Editors group you added, then that is why you cannot see them.

Yes it was left blank because there was nothing in the dropdown and I couldn’t type in that area. Thinking about it now it may be blank becuase I can’t see any categories

Quote from: OpenGeek at Jan 27, 2011, 06:41 PM

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

Everything I added had a minimum role of "Editor" the new group I created.

Roles are not Groups, so I’m confused by this statement. I would leave Roles alone and just always use Member unless you know what you are doing with Roles already.

I confuse myself sometimes. I created a role "Editor" with the authority of 10 and when a setting had a minimum role, the Editor role was selected.


Quote from: OpenGeek at Jan 27, 2011, 06:41 PM

Quote from: betoranaldi at Jan 27, 2011, 06:29 PM

I assume this last step is what you are referring to but by deleting the new user group, should that have corrected it?

You will need to remove the access control entries that you had linked to that new user group or manually add one in the database for your Administrator group. Whenever you restrict access to something, always restrict access to the Administrators group first, otherwise, only the group you assigned the policy to will be able to access it.

So now that I deleted the group, before doing this, am I stuck? Is there anyway to reset the whole user access area?

I don’t know if this is any help but looking at the modx_access_category table I see the following:

id target principal_class principal authority policy context_key
1 modUserGroup 2 10 5 mgr
4 modUserGroup 2 10 4 mgr
3 modUserGroup 2 10 6 mgr
5 modUserGroup 3 10 6 mgr

This issue was definitely access/permission based. I ended up restoring all 13 access related database tables (from a day old backup) and now everything is displaying in the manager for the super user account.

I will definitely have to be more careful when creating access groups/settings. I would love to know exactly what I did but most likely has something to do with an access category policy.

Thank you for your help OpenGeek

Why are you using Roles/authority like that? Aren’t groups enough? You do not need to use Roles unless you need advanced granularity to identify different types of group members. Thus the least authority (given the highest number, or 9999) is known as just a Member. In most cases, being a Member of a Group is all that should matter. Using custom Roles should be reserved for advanced security scenarios where you need Group administrators or team leaders that might get additional privileges over say, a Member. Using it otherwise will just make your life way too complicated for no good reason.

Quote from: OpenGeek at Jan 28, 2011, 09:50 AM

Why are you using Roles/authority like that? Aren’t groups enough? You do not need to use Roles unless you need advanced granularity to identify different types of group members. Thus the least authority (given the highest number, or 9999) is known as just a Member. In most cases, being a Member of a Group is all that should matter. Using custom Roles should be reserved for advanced security scenarios where you need Group administrators or team leaders that might get additional privileges over say, a Member. Using it otherwise will just make your life way too complicated for no good reason.

I am still trying understand the whole ACL system (I did watch the video tutorial in the wiki) and was just making it more complicated then it needed to be. Using just groups I was able to accomplish what I wanted to.