The problem of non inheriting rights walking the menu tree

I’m not fully sure I understand your dilemma.

There is a partial solution that I propose, the children would always inherit of the limitations of the rights of the parent.

The children do inherit the rights of the parent… so if a parent isn’t visible, the whole tree of children is not visible. However, the meta values aren’t saved. If you move the child menu item to a new menu parent, then you need to re-assign the child’s visibility settings.

Hi,

We are perfectly in the same point of view.

The problem is that an element can have his own basic rights, but when it is attached to a parent which have stronger limitation, dynamically it will currently appear into the menu as an isolated element at first level.
For example an element “visible by everybody) and it is set into a menu branch accessible by everybody everything is right. The admin decides to replace it but want to keep the current version into is own private branch. If the admin moves the element into his branch (access limited to admin) the result is that the element will appear as a first level menu element when visitor accesses the site, this while the admin purpose was exactly the contrary. To reach the result the admin must change the “static” rights of the elements to “logged in -> admin”.

I think this is important and can change some elements of the presentation of your product :

• introduce the concept of “static” and “dynamic” rights (you began to tell about into your answer) : when an element is attached to a branch it inherits dynamically (for the current treatment) of the limitations of the parent, this all along the tree.
• this allows to move element from one branch to another and keeps a coherent structure of the menu
• this simplifies the creation of the rights of elements of menu because the rights then created for an element are only “static”. Then for example if an element is statically declared “limited access to logged in admin” it can never be seen by somebody else even attached (by error) to an accessible branch by visitor.
• this makes much more easy the management of rights by the admin of menu.

Thanks

Best regards

Trebly
_________________________________________________________________________
Note : A problem for future : when menu element leads to an article which has not good rights (for example more complex with the use of UAM), the access will become unallowed but after nmr had allowed the access. For this I uses a default page which explain to the user and creates a report to admin (page defined to uam when access is refused to avoid a 404). A future extension of UAM could be that a function (substituted -hook, to core request to elements access) could be asked for rights before activation of the link (the element is visible into menu but link is launched only if this function answers OK). Then this UAM function could tell : “you have no access … because…” or proposes an action or forbids access simply. This feature would avoid to load the forbid page but only a content loaded by ajax into a messagebox from the UAM function (or core).

Hi,

Do you agree with my comments ?

Best regards

Trebly

If you move a menu item I think it’s fair to expect you should have to modify the visibility rights. I don’t see a case for restructuring menus so frequently that this would be a burden.

I’m also not actively adding features to NMR at the moment. If you want to suggest a pull request I will review it.

Hi,

I will answer later to the question of a pull request, here I just answer to your first question by two examples.

• I had some articles which became obsolete (to be replaced) but I was not wanting to loose their content and stay able to read them (and edit to copy selected parts), then I have decided to move them (drag and drop) from a menu “visitor accessible” to a submenu which is into a menu header “admin” (restricted to administrators).
  This had the effect to get a main menu of many lines with these articles as main headers of menu. Such operation needs in fact that these articles inherit from the menu “menu” of the restricted access of this menu element.
  To avoid this I had to change for each article his NMR rights by copying the rights of “admin” menu element.

• The second case is to add the exact reverse, after moving temporarily an article from visitor menu to admin-author menu, after changes replace at his first place. This need to change again the intrinsic rights

My proposal is to avoid this problem making that an element will inherit dynamically of restrictions of the access of the parent into the menu. This avoids to generate accidentally orphan elements of menu. I think that the review of right is independent for the soft basic features considerations : production of orphan should be impossible in my opinion. Is this a new feature or should exist by default ?

Best regards
Trebly
_____________________________________________________________________
note 1 :

This procedure allows to show versus to hide elements to visitor (or any other role) using one alone operation into the menu without changing the intrinsic rights
________________________________________________________________________________
note 2 : Join the NMR and UAM advantages

As a finality but not security features (protect against orphans), there is an other manner to perform this, it is to use UAM, changing the UAM-group (or several) of the article it will appear versus disappear from the view of visitor (particularly from menu but also from list and indirect access) and or to admin-author-reviewers.
You understand that is not the same perspective of use nor the same operations. If you uses UAM to do the same you need to create a list of elements selected by their UAM group into a menu “admin and review” the list of articles which must be modified (for example because a major error has been found after a first publication).
But when you uses this procedure, to check to menu view you must log out to be able, after reload, to see the true and verified menu content.
This is a more elaborated and heavy process for which security is a problem (complex tools to check the content generated ; by basic operations it is easy to produce very bad errors with a simple checkbox typing error; one unique error should make that the article appear to admin into a “rights anomalies list” )

• This reply was modified 7 years, 5 months ago by Trebly.