Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] Access Policy: General information #14506

Open
Ruslan-Aleev opened this issue Mar 22, 2019 · 1 comment
Open

[bug] Access Policy: General information #14506

Ruslan-Aleev opened this issue Mar 22, 2019 · 1 comment
Assignees
Labels
area-core proposal Proposal about improvement aka RFC. Need to be discussed before start implementation.

Comments

@Ruslan-Aleev
Copy link
Collaborator

Ruslan-Aleev commented Mar 22, 2019

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
error_1

Manager error page
error_3

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
error_5

Incorrect pop-up window with no text, with json
error_2

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
error_4

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

@JoshuaLuckers JoshuaLuckers added bug The issue in the code or project, which should be addressed. area-core labels Mar 25, 2019
@Ruslan-Aleev
Copy link
Collaborator Author

Related with #12568

@alroniks alroniks added rfc and removed bug The issue in the code or project, which should be addressed. labels Apr 3, 2021
@alroniks alroniks self-assigned this Apr 3, 2021
@alroniks alroniks added proposal Proposal about improvement aka RFC. Need to be discussed before start implementation. and removed rfc labels Apr 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core proposal Proposal about improvement aka RFC. Need to be discussed before start implementation.
Projects
None yet
Development

No branches or pull requests

3 participants