Showing missing, hidden or protected pages in the Page Tree

Hi everyone,

Due to the way the nested pages hierarchy and the access rights system are implemented, we can have the following 3 edge cases:

  • a page exists although some of its parent / ancestor pages are missing (e.g. One.Two.Three exists but One.Two is missing)
  • a page is not hidden (i.e. appears in search results) although some of its parent / ancestor pages are hidden (e.g. One.Two.Three is not hidden but One.Two is hidden)
  • the current user can view the current page but not all of its parent / ancestor pages (e.g. the user can view One.Two.Three but not One.Two)

While you may argue that these use cases are not recommended or valid (in real-life), they are possible so we need to address them in the Page Tree.

The Page Tree can be expanded in two ways:

  • top → down: in this case we don’t include missing, hidden or protected pages because we load nested pages level by level and it would be too costly to check if for a given page that is missing / hidden / protected there are nested pages at any level below that are viewable. We simply filter out missing, hidden and protected pages. I think we should keep it like this.
  • bottom → up”: this happens when we open the tree to a specific node, either using the openTo macro parameter or using the tree finder (which calls openTo under the hood). Since we know the target node we can compute the path in the page hierarchy. Now, the issue is that some of the path elements might not be viewable as per the 3 use cases mentioned above. The current behavior is that the tree tries to open each path element, stopping either at the end or when reaching a node that can’t be viewed.

So the first question is: should the openTo operation add the missing nodes (that otherwise would not be visible) in order to be able to reach the target node?

  • No: then we do nothing, so we may have to close issues like XWIKI-19067 as invalid.
  • Yes: then the next question is whether these special nodes (missing / hidden / protected pages) should be displayed differently (than normal pages) or not?
    • No: that’s easy but it won’t be clear for the users why some pages appear in the tree sometimes and sometimes they don’t (like when you access a page directly vs. trying to reach that page by expanding the tree from a different location)
    • Yes: then we need to decide how to display:
      • missing pages: there is a standard way to display links to missing pages in XWiki so we could reuse those styles for consistency. There is the question whether clicking on the missing page node should open the Create Page popup. I’m not convinced because the tree is often used for selecting a page, where the links are off (but we still need to show that some page might be missing). As for the icon, I’d use the same icon as for the existing pages.
      • protected pages: we don’t have a clear standard of displaying “links” to protected (view restricted) pages. The breadcrumb uses the entity reference name as label and doesn’t generate a link. Plus, it uses gray (“disabled”) text. On the jsTree side, we have styles for disabled nodes that uses gray text but also decreases the opacity. So the first question is whether there should be a link or not. The fact is that jsTree always generates an a tag, so if we leave the href empty we get a link targeting the current page which is confusing to me. I’d rather generate the link to the protected page. Then, regarding the styles, I’d use the jsTree style for disabled nodes. As for the icon, we can either use the default one, or use a lock icon to better emphasize that the page is protected.
      • hidden pages: to be clear, this is when the user doesn’t want to see hidden pages but the tree has to display such a page because one of its child pages is not hidden. We don’t have a standard way to display links to hidden pages. We could simply decrease the opacity, using the same icon.

I’ll post a mock-up with my proposal ASAP so that you better understand what I’m talking about.



Here’s what I had in mind:

  • example without icons but with links (navigation)
  • example with icons but without links (page selector)





Sounds good to me.

Maybe the behavior should be controlled by the user of the document tree macro, with a parameter to control that behavior. For the navigation panel, it makes sense to open the create page dialog, while for selecting a page, it should just get the doc reference.