Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-18601

Navigation tree displays an arrow even in case of private page in hierarchy

Details

    • Bug
    • Resolution: Unresolved
    • Minor
    • None
    • 13.2
    • Index, Tree
    • Unknown

    Description

      Reproducing Steps:

      • Create a public page under default Dashboard which is in left-side navigation bar
      • Create a child for this page and remove its viewer rights for some group/user

      Result:

      • An arrow is still present on parent public page that shows there should be something under it

      Expected result:

      • There should just be a bullet point if there's no public child

       

      In the screenshot, Secret Page is unavailable for a specific group while About is available for everyone. The bug concerns About bullet in incorrect.png

      Attachments

        Activity

          [XWIKI-18601] Navigation tree displays an arrow even in case of private page in hierarchy

          With the current architecture we have in place access rights cannot be check at database query time. This has multiple side effects:

          • counts don't take access rights into account; we're not going to retrieve all the results and check access rights on each of them just to compute the count; this is true for page tree, live table, search results, etc.
          • page references (including page name, but not page title) are not protected and thus are not considered as private information; any user with script right can write a script to list page references or to count them; page tree, live table and search try to hide them when possible, but this leads to pagination holes (because if previous point). Again, it can be very costly to find the next 10 pages that the current user can view (you can have 1k pages and the user might have view access to only one, and you might end up checking access right for all of them to find that single page).

          So this is not easy to fix and I think we should find/create a more generic issue and close this as duplicate, because we can create tens of issues like this but the root problem is the same: access rights cannot be checked at query time.

          mflorea Marius Dumitru Florea added a comment - With the current architecture we have in place access rights cannot be check at database query time. This has multiple side effects: counts don't take access rights into account; we're not going to retrieve all the results and check access rights on each of them just to compute the count; this is true for page tree, live table, search results, etc. page references (including page name, but not page title) are not protected and thus are not considered as private information; any user with script right can write a script to list page references or to count them; page tree, live table and search try to hide them when possible, but this leads to pagination holes (because if previous point). Again, it can be very costly to find the next 10 pages that the current user can view (you can have 1k pages and the user might have view access to only one, and you might end up checking access right for all of them to find that single page). So this is not easy to fix and I think we should find/create a more generic issue and close this as duplicate, because we can create tens of issues like this but the root problem is the same: access rights cannot be checked at query time.

          People

            Unassigned Unassigned
            gcoquard Guillaume COQUARD
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: