You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently we tested all the settings in the Access Policy and grouped them into logical groups, but almost every setting has an inaccuracy or even a bug.
Guys, we need help in testing these problems, both from the MODX-user and from the MODX-components.
No hierarchy in settings
In the Access Policу, need to somehow identify global settings and connect them with subordinate settings, for example, I can completely disable the section "Access Control List" through the setting "access_permissions", and then below configure the section "Roles" through the setting "edit_role", but it does not make sense anymore, since there is no access to the main section "Access Control List" (setting "access_permissions").
Navigation and control elements
Navigation items work strangely, depending on access settings.
For the top menu item from the menu may disappear, but at the same time work on a direct link. Or do not disappear, but do not work on a direct link. The whole section may disappear, but the elements will work on a direct link.
For the context menu: somewhere the items may disappear, or somewhere not, but not work. Somewhere item not to work completely (white screen), but somewhere partially (pop-up window) or not to respond at all.
For many elements (snippet, template, etc.), the delete button, for example, remains in the edit form, although in the element tree the "delete" link from the context menu disappears.
I think that it is more correct not to hide the navigation elements (except for the access settings to the main menu), and when you go without access, open the page with an error or pop-up window.
Firstly, the user will not be confused due to the fact that some buttons disappeared for some reason, secondly, the user sees the message on access denial and understands this, and thirdly, the code is easier to administer, because you will not need to add unnecessary checks in the navigation elements, but check access on the final file (?).
Grids
Grids do not immediately display a denied message, and sometimes display a grid without messages.
Error Message
Often, if you open a blocked item, an empty page opens with an error: "An error occurred ... Access denied.". It’s better to display this message with specific error information (what kind of error, what permissions is not available, etc.) in the manager panel, rather than make a blank page, the error template is already in the manager panel.
Blank error page
Manager error page
Sometimes, instead of the page, a window with a message pops up, and sometimes instead of a message, an error is displayed without text in json, for example, disable "view_category" and open any element (chunk, for example).
Pop-up window error
Incorrect pop-up window with no text, with json
Sometimes an error is displayed in the manager panel (not a page or a pop-up window), for example, if you disable "menus" setting and go to the "Menu" for a direct link, then another error will open.
Another version of the error
So maaaaany varints to display the error of access, which is strange.
Permission naming
The permissions keys are not understood as they have no logical connection: "delete_document" and "resource_duplicate" (more correctly "resource_delete", "resource_duplicate"), or "new_plugin" and "edit_plugin" (more correctly "plugin_create", "plugin_edit"), etc. - already discussed earlier - #14313
Description and Translation
The description of the settings is often not correct or does not give understanding.
Descriptions of settings are often incorrectly translated.
Also the error message text not fully translated.
Bug report
Summary
Recently we tested all the settings in the Access Policy and grouped them into logical groups, but almost every setting has an inaccuracy or even a bug.
Guys, we need help in testing these problems, both from the MODX-user and from the MODX-components.
No hierarchy in settings
In the Access Policу, need to somehow identify global settings and connect them with subordinate settings, for example, I can completely disable the section "Access Control List" through the setting "access_permissions", and then below configure the section "Roles" through the setting "edit_role", but it does not make sense anymore, since there is no access to the main section "Access Control List" (setting "access_permissions").
Navigation and control elements
Navigation items work strangely, depending on access settings.
For the top menu item from the menu may disappear, but at the same time work on a direct link. Or do not disappear, but do not work on a direct link. The whole section may disappear, but the elements will work on a direct link.
For the context menu: somewhere the items may disappear, or somewhere not, but not work. Somewhere item not to work completely (white screen), but somewhere partially (pop-up window) or not to respond at all.
For many elements (snippet, template, etc.), the delete button, for example, remains in the edit form, although in the element tree the "delete" link from the context menu disappears.
I think that it is more correct not to hide the navigation elements (except for the access settings to the main menu), and when you go without access, open the page with an error or pop-up window.
Firstly, the user will not be confused due to the fact that some buttons disappeared for some reason, secondly, the user sees the message on access denial and understands this, and thirdly, the code is easier to administer, because you will not need to add unnecessary checks in the navigation elements, but check access on the final file (?).
Grids
Grids do not immediately display a denied message, and sometimes display a grid without messages.
Error Message
Often, if you open a blocked item, an empty page opens with an error: "An error occurred ... Access denied.".
It’s better to display this message with specific error information (what kind of error, what permissions is not available, etc.) in the manager panel, rather than make a blank page, the error template is already in the manager panel.
Blank error page
Manager error page
Sometimes, instead of the page, a window with a message pops up, and sometimes instead of a message, an error is displayed without text in json, for example, disable "view_category" and open any element (chunk, for example).
Pop-up window error
Incorrect pop-up window with no text, with json
Sometimes an error is displayed in the manager panel (not a page or a pop-up window), for example, if you disable "menus" setting and go to the "Menu" for a direct link, then another error will open.
Another version of the error
So maaaaany varints to display the error of access, which is strange.
Permission naming
The permissions keys are not understood as they have no logical connection: "delete_document" and "resource_duplicate" (more correctly "resource_delete", "resource_duplicate"), or "new_plugin" and "edit_plugin" (more correctly "plugin_create", "plugin_edit"), etc. - already discussed earlier - #14313
Description and Translation
The description of the settings is often not correct or does not give understanding.
Descriptions of settings are often incorrectly translated.
Also the error message text not fully translated.
Environment
MODX >2.x
#14505, #14498, #14497, #14479, #14468, #14467, #14436, #14435, #14434, #14432, #14431, #14430, #14429, #14419, #14418, #14407, #14406, #14405
The text was updated successfully, but these errors were encountered: