The problem of non inheriting rights walking the menu tree

  • Trebly

    (@trebly)


    6 years, 10 months ago

    ;Hi,

    I often meet the following problem :

    When a menu element is moved from a menu branch to another, the admin commonly imagine by instinct that the rights of the top parent into the new branch are inherited by the children elements.

    If the rights of the element moved are more restricted that those of the new parent, the element will simply not appear into the structure if the current user has not the rights, that’s normal. The admin must care to the rights of each element with the question “allow to who”.

    But, this is the current behavior, if the child element has lower rights the effect, if the child element doesn’t inherit of the limitations of the rights of the parent, is that the menu hierarchy will be broken and that the element will be displayed anywhere into the menu (this depends of the css of the menu, most commonly one or several lines of orphans elements can appear when you reorganize the menu).

    This lead the admin to create separately (with excel for example) a full list of the menu with as columns content the hierarchy of rights, and to organize everything manually and after the job ended copy each check box to the menu manager… which job is fully boring long and lead to a great risk of errors and accidentally awful menu displays.

    There is a partial solution that I propose, the children would always inherit of the limitations of the rights of the parent. This would make much more easier the migration of menu element from one branch to another, and the administrator would only to just care of the accesses that have to be directly limited for the current element of menu.

    Best regards

    Trebly

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author HelgaTheViking

    (@helgatheviking)

    6 years, 10 months ago

    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.

    Thread Starter Trebly

    (@trebly)

    6 years, 10 months ago

    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).

    Thread Starter Trebly

    (@trebly)

    6 years, 10 months ago

    Hi,

    Do you agree with my comments ?

    Best regards

    Trebly

    Plugin Author HelgaTheViking

    (@helgatheviking)

    6 years, 10 months ago

    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.

    Thread Starter Trebly

    (@trebly)

    6 years, 10 months ago

    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 6 years, 10 months ago by Trebly.
Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘The problem of non inheriting rights walking the menu tree’ is closed to new replies.