Answered Code: 200 OK {"success":false,"message":"Permission denied!","total":0,"data":[],"object":[]}

Thanks Mina and Susan,

Unfortunately now this install is not working in Chrome. I am trying unsuccessfully to debug with FF.

I also noticed that although the top menu items have changed in 2.3 to Content, Media, Extras, and Manage, the access policy permissions still are:
menu_reports, Show the top menu item "Reports".
menu_security, Show the top menu item "Security".
menu_site, Show the top menu item "Site".
menu_support, Show the top menu item "Support".
menu_system, Show the top menu item "System".
menu_tools, Show the top menu item "Tools".
menu_user, Show the top menu item "User".

Trial and error lead me to discover that checking menu_tools allows the new Manage menu to be viewed. As this is my first 2.3 site I don't know if this is a failure of this particular upgrade, or if these mismatched permissions exist in all 2.3 installs...

@lucy you don't need to go with trial and error. If you go to "Settings, Menues" in manager, you will see each menu item required permission in the permission field.

And yes, the permission naming is still legacy, so the Extras permission is "components" etc.

Hi Mina,

I'm completely baffled as to how that Menus page is supposed to work. And I don't see a permission field...?

Is there a doc somewhere mapping the legacy menu items with the new menu items? That would be useful.

- Go to "Settings, Menus" in manager
- Expand "Topnav" (this is the top menu)
- Expand the tree you are concerned about, right click the item and click on update, you will see the permission field.

NB. The parent menu (Content, Extras, Manage etc.) permission should be given to the user to be able to see the submenu items.

You can create a new menu under "topnav" give it any name you like, then create under it submenus and copy any item you want to it (just changing the "Lexicon key"), And you can create a new security policy template and create your custom new permissions there.

With regards to the documentation, I guess Bob Ray, might have something about it in his blog, dig his blog. If you have a specific question i would be glad to assist.

If you right-click on a Menu item and select "Update Menu," you'll see a permissions field. That's the permission they need to see that menu item and (usually) to perform any related actions.

Note that if the user doesn't have permission for a parent menu item, they won't have permission for any children under it.

Another tip: When you look at the Policy tab in Access Controls, if you click on the little + sign next to a Policy, you'll see a list of the permissions that are enabled in that Policy.

If a user can see a menu item, but can't perform its action, it's possible that the code that performs the action requires a permission that the menu item does not. You can use the method described above (looking at the network tab in dev. tools) to see which file is failing the user, then look in that file for uses of checkPolicy or hasPermission. The first one will check a context policy, the second one will check a resource policy.

You might first want to make sure it's really a permission problem. Give the user an Administrator context policy for any 'web' or 'mgr' Context Access ACL entries, and the Resource policy for any Resource Group Access ACLs. Then flush permissions and sessions. If that doesn't solve the problem, something much weirder is going on.

Quote from: boomerang at Jul 31, 2014, 08:20 AM

I got the:

Code: 200 OK
{"success":false,"message":"Permission denied!","total":0,"data":[],"object":[]}

problem on upgrade from 2.2.14 to 2.3.1 and can confirm it was resolved my checking permission for class_map as suggested by codenator below:

class_map
To view a list of classes in the Class Map. role solve issue
There problem no much info which king of issue I got.

Did need to Logout All Users to fully flush permissions but it did fix the message

I tried this fix on revo 2.31 + 2.3.2 and still get the error just when editing resources made with the Articles extra for non admin users only. I flushed permissions and emptied cache. Same website in Revo 2.2.14 performs fine. No error.
Thanks [ed. note: howster last edited this post 9 years, 5 months ago.]

You do not have to change files or database entry's.
Just go to the active access policy for the usergroup having problems and make sure the checkbox is checked for the entry class_map.

Then flush user sessions and log back in. That should do the trick.

It's a permission, so you need to go to (in Revolution 2.3) Gear Icon -> Access Control Lists.

Then, on the "Access Policies" tab:

- Right-click on the appropriate policy
- Scroll down
- Put a check next to the "class_map" permission and any other permissions the user might need.
- Save the policy.

The "appropriate policy" is the one specified in the Context Access ACL entry that gives the users access. [ed. note: BobRay last edited this post 9 years, 5 months ago.]

Quote from: howster at Oct 30, 2014, 02:43 PM

Quote from: boomerang at Jul 31, 2014, 08:20 AM

I got the:

Code: 200 OK
{"success":false,"message":"Permission denied!","total":0,"data":[],"object":[]}

problem on upgrade from 2.2.14 to 2.3.1 and can confirm it was resolved my checking permission for class_map as suggested by codenator below:

class_map
To view a list of classes in the Class Map. role solve issue
There problem no much info which king of issue I got.

Did need to Logout All Users to fully flush permissions but it did fix the message

I tried this fix on revo 2.31 + 2.3.2 and still get the error just when editing resources made with the Articles extra for non admin users only. I flushed permissions and emptied cache. Same website in Revo 2.2.14 performs fine. No error.
Thanks

Solved: permissiom "view_user" need to be checked

Такая же ошибка возникала, когда в настройках nginx были следующие строки

limit_zone slimits $binary_remote_addr 5m;
limit_conn slimits 5;

Т.е. modx загружал свои ресурсы, но в итоге превышал допустимые 5 одновременных запросов и вместо части ресурсов получал код 503.
Для нормальной работы modx оказалось достаточным:

limit_zone slimits $binary_remote_addr 10m; // на всякий случай
limit_conn slimits 10;