Re: [xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel

Hello all, so, if I remember correctly, the navigation panel is just a call to the documentsTree macro. Unless otherwise specified, my remarks below are about the documentTree macro features. On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea < mariusdumitru.florea(a)xwiki.com&gt; wrote: The documentTree macro already has this feature, actually, to be able to start in a given root and I thought about this solution (manually implemented with a custom documentTree with a custom root). However, I think it's too restrictive (to force all content to be rooted in "Content") and in order to technically make it happen you'd need to change too many places of XWiki: the create, copy and move screens (when location is chosen) in order to make sure that user does not create content somewhere else. Most of the usecases I had fall into this category, with blacklisting only at root level (if this makes it easier to implement or doesn't introduce perf. issues). So to me the pages to exclude would be a feature of the documentTree macro (which can also be used as a gadget on a dashboard). Actually, this is a feature :) : any page (be it extension or user created content) is whitelisted until an administrator decides that it should not be in the tree. Note that it's the administrator that installs extensions on a wiki, and at least in theory it's not done every morning. For the management of the blacklists of the navigation panel (what navigation panel will pass to the documentTree macro), we can use an administration section, just like we do for what the applications panel displays by default :D. In addition, it would be consistent with what we already have! The fact that you see too many pages when you activate hidden pages in your profile is a problem that is not specific to the tree, so it shouldn't surprise anyone that the tree also shows too many things. To me, seeing hidden pages is not a "regular user in production" setting, it's mostly for setup / development phase. this is the same principle as blacklisting (only "reversed"), and as far as I can project now, it already has a workaround: having multiple documentTree calls with the root parameter set and showroots to true. Also, the default create button of the wiki creates pages on the root of the wiki, next to "Main" and this would mean that the administrator would need to update the navigation panel any time a page is created, which is way more often than "any time an extension is installed". err, how? The create button displayed on the homepage - the only create button that you see when you start on an empty wiki - creates top level pages! (there's actually a bug in 9.11.3, I explicitly changed the location to the "Home" page, and it still created a toplevel page). Indeed, if the administrator has an idea about what would be put on the wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/ he might not want to, leaving users to organise their content as they wish. This is _very_ close to the cases I had, but the difference between "exactly" and "very close" is relevant, to me: obviously, some XWiki, Sandbox and other standard content needed to be removed, but also a custom page that I had created and manually put in the application panel. So, in my opinion, the work to do this is comparable to the work for implementing explicit blacklisted roots, so between this and 2, I choose 2. Long story short: I believe, as Vincent said, that we need to have the generic whitelist / blacklist parameters for the documentTree macro, in order to cover the maximum cases possible, and in my opinion, they all exist, because there is a great diversity in what users can do on the wiki but also in how they interpret some things: some people see applications as "special", some others don't, etc. For the navigation panel default blacklist we can make some dynamic computing of the parameters we pass to the documentTree call, e.g. all extensions, or some configuration in administration. As a priority choice between blacklist and whitelist, I would choose blacklist, as some sort of whitelist already exists, even if not fully complete and anyway it covers less "user content" cases than the blacklist one. Thanks, Anca