Jess, first, have the user click on the "house" icon to see if it expands to show the resources.
Next, check whether they modified or deleted any Context Access ACL entries or changed the tree_root_id setting. They might also have put all the web resources into a resource group and connected it to a user group they don't belong to.
Jess, go to Security -> Access Controls -> User Groups tab.
Right-click on the group the user belongs to and select "Update User Group."
Select the "Context Access" tab to see what ACL entries exist for the group. One should have a context of 'web' and that entry should have a policy that has the 'list' permission enabled.
Ok, great I found it thanks. There are six "mgr" contexts and six "web" contexts. Does it matter which "web" context item I set to "load, list and view?" The access policy for all are "administrator."
Jess, that's just nuts.
For a given user group, there should only be one Context Access ACL entry for each context (unless the extra ones are for different roles -- and yours aren't). They all use the same role and policy so they're completely redundant.
IOW, delete all of them except two. Keep the first 'web' one and the first 'mgr' one -- toss the rest. Clear the cache, flush permissions and flush all sessions.
See if that solves the problem, though it makes me wonder if some other goofy permissions might be set up or if the Administrator policy has been altered (it should have *all* permissions checked) or if the Administrator template has had permissions removed (never do that).
I generally deny the access_permissions permission for users other than me, especially low-level users, so they can't mess with the permissions system (or lock me out of the site).
It seems unlikely, but I guess it's possible, especially if people were accessing the site during the upgrade. Tables do crash from time to time, though, and the crashed table is almost certainly the cause of the problem.
First, flush all sessions and don't log back in.
Using cPanel (or whatever admin panel your host provides), go into PhpMyAdmin. Select the database used by the modx install. You should be able to select the modx_site_content table and have it repaired.
While you're there, check for other tables that might need repair (that might explain the multiple ACL entries if no one created them).
Hopefully, you have a recent backup of the site in case the repair doesn't work or causes the loss of some resources. It's possible to restore just that table from the backup, but try the repair first.
After the repair, delete all the files in the core/config directory before trying to access the site.
Ha, just tried to hard code it and that's not working either. Appears there is still an issue. So close!