On Thu, May 3, 2018 at 12:07 PM, Vincent Massol <vincent(a)massol.net> wrote: If they want to hide something, they have the Hidden pages mechanism.

On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < valicac(a)gmail.com&gt; wrote: The Content space is for all users, shared. This is not about having a separate space for each user. I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel. They would want to have an entry in the application panel like the rest of the apps I think.

On Thu, May 3, 2018 at 1:44 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either. Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain. And what about the hidden pages? Don't you find it hard to manage a blacklist of 28+ excludes? Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically. When you create a top level page, it's shown automatically in the tree.

On Thu, May 3, 2018 at 3:01 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: No. The implementation I had in mind for Solution 4 is very simple: check if the top level page itself is part of an extension. That means Menu.WebHome, Sandbox.WebHome, XWiki.WebHome, etc. Checking if there is some nested child page created by the user inside a top level page is way to complex and time consuming. So it doesn't matter if the application has Code and Data nested pages. What matters is that the home page of the application is part of an extension and thus that page and all its children will not appear in the navigation panel. Solution 4 is about top level *pages* that *belong* to an extension. If the XWiki and Home pages (WebHomes) wouldn't be part of an extension then you wouldn't have them installed with the Standard flavor. XWiki.WebHome https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribu… is part of xwiki-platform-distribution-ui Main.WebHome https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribu… is part of xwiki-platform-distribution-flavor-common So both would be excluded (along with all their child pages) from the navigation tree. Main.WebHome could be kept though if we check also the page type (as Thomas mentioned): keep top level pages that belong to an extension if they are "editable" (based on their type, the XAR page type introduced by Thomas recently). The plan would be to use the Extension Manager API to check if a page is part of an extension and ATM this is limited to the pages that are include in the extension XAR package. If the application creates at runtime a top level page then that page would be shown.

On Thu, May 3, 2018 at 4:28 PM, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com > On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea < > mariusdumitru.florea(a)xwiki.com> > > On Thu, May 3, 2018 at 3:01 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > > > > > Hi Marius, > > > > > > See below > > > > > > > On 3 May 2018, at 13:24, Marius Dumitru Florea < > > > mariusdumitru.florea(a)xwiki.com> > > > > > > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol &lt;vincent(a)massol.net&gt; > > > > > > > > > >> > > > >> > > > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea < > > > >> mariusdumitru.florea(a)xwiki.com> > > >>> > > > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < > > > >>> valicac(a)gmail.com> > > >>> > > > >>>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > > > >>>> mariusdumitru.florea(a)xwiki.com> > > >>>> > > > >>>>> Hi devs, > > > >>>>> > > > >>>>> Some users have complained that the navigation panel shows top > > level > > > >>>> pages > > > >>>>> that they don't need/want to navigate to, most importantly the > > XWiki > > > >>>> page. > > > >>>>> > > > >>>>> There are multiple ways in which we can fix this. > > > >>>>> > > > >>>>> Solution 1: Content Page > > > >>>>> > > > >>>>> Create a top level "Content" page for user content and configure > > the > > > >>>>> navigation panel to show the contents of this page. > > > >>>>> > > > >>>>> Pros: > > > >>>>> * Namespace isolation (no conflicts between user pages and > > > application > > > >>>>> pages) > > > >>>>> > > > >>>>> Cons: > > > >>>>> * The user may want to navigate to a top level application page > > > >> (although > > > >>>>> it's better to use the application panel for this instead) > > > >>>>> * All the paths / references used to access the user content will > > > start > > > >>>>> with this "Content" page > > > >>>>> > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >>>> S1: This solution is good if users would work in isolation or in > the > > > >>>> evaluation period, but for team and multiple people sharing > spaces, > > I > > > >> don't > > > >>>> see this as a valid solution. > > > >>>> > > > >>> > > > >>> The Content space is for all users, shared. This is not about > having > > a > > > >>> separate space for each user. > > > >>> > > > >>> > > > >>>> -0 > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> Solution 2: Blacklisting > > > >>>>> > > > >>>>> Add support for specifying a list of (top level) pages to exclude > > > from > > > >>>> the > > > >>>>> navigation panel. > > > >>>>> > > > >>>>> Pros: > > > >>>>> * The user (top level) pages created later on will be visible in > > the > > > >>>>> navigation panel > > > >>>>> * The blacklist could be used to filter not only top level pages > > but > > > >> also > > > >>>>> any nested page from the navigation panel. > > > >>>>> > > > >>>>> Cons: > > > >>>>> * The blacklist depends on the installed apps. The administrator > > may > > > >> have > > > >>>>> to update the blacklist when new applications are installed > > > >>>>> * The blacklist depends on whether you view hidden pages or not. > If > > > you > > > >>>>> don't view hidden pages then the blacklist probably contains 4 > > pages: > > > >>>> Help, > > > >>>>> Menu, Sandbox, XWiki (there is an application panel entry for > each > > of > > > >>>> them > > > >>>>> except XWiki), which is manageable. If you view hidden pages then > > you > > > >>>> need > > > >>>>> to black list 28+ pages which is hard to manage and maintain. > > > >>>>> * The filtering needs to happen on the database (otherwise we > break > > > the > > > >>>>> pagination) so the database queries will become a bit more > complex, > > > >> which > > > >>>>> could led to some performance penalty, depending on how long the > > > >>>> blacklist > > > >>>>> is. > > > >>>>> > > > >>>>> > > > >>>> S2: I see the blacklist solution more as a hack for things in > XWiki > > > that > > > >>>> should be fixed (have users outside XWiki space, move Sandbox into > > > Help > > > >>>> space, hide Help pages and provide a dedicated Help entry in the > > User > > > >> menu, > > > >>>> etc.) but we don't have the time to do it. > > > >>>> -0 in an ideal state > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> Solution 3: Whitelisting > > > >>>>> > > > >>>>> Add support for controlling the list of top level pages that are > > > >>>> displayed > > > >>>>> in the navigation panel. > > > >>>>> > > > >>>>> Pros: > > > >>>>> * the whitelist doesn't depend on the installed extensions or > > hidden > > > >>>> pages > > > >>>>> so it's easier to maintain. > > > >>>>> * the whitelist can be used to order the top level pages visible > in > > > the > > > >>>>> navigation panel. > > > >>>>> * the whitelist can be used to show at the top level (for > > navigation > > > >>>>> purpose) a page that is not really a top level page > > > >>>>> * No performance penalty > > > >>>>> > > > >>>>> Cons: > > > >>>>> * The user (top level) pages created later on will not be visible > > in > > > >> the > > > >>>>> navigation panel. The administrator will have to add them to the > > > >>>> whitelist > > > >>>>> if they are useful for the navigation. Although creating top > level > > > >> pages > > > >>>>> should happen less often than creating nested pages under the > > > existing > > > >>>> top > > > >>>>> level pages. > > > >>>>> * the whitelist controls only the first level in the tree. The > next > > > >>>> levels > > > >>>>> will be dynamic (database queries) and with the default order. > > > >>>>> > > > >>>> > > > >>>> S3: I prefer this solution, but with the ability to also display > > some > > > >>>> dynamic pattern, something like: display X, Y and all children of > Z, > > > or > > > >>>> all pages starting with A, or all pages created by group N :) > (they > > > are > > > >>>> just ideas, I know some are very hard to implement). > > > >>>> +1 > > > >>>> > > > >>>> > > > >>>>> > > > >>>>> > > > >>>>> Solution 4: Exclude extension pages > > > >>>>> > > > >>>>> Exclude from the navigation panel the top level pages that belong > > to > > > an > > > >>>>> installed extension, allowing the administrator to make some > > > exceptions > > > >>>>> (e.g. keep the home page). The rationale is that if an installed > > > >>>> extension > > > >>>>> has a top level page then that page is most probably the > > application > > > >> home > > > >>>>> page which should be accessible from the application panel. This > > can > > > be > > > >>>>> implemented on top of solution 3 (the whitelist is basically > > dynamic: > > > >> we > > > >>>>> collect the top level pages that don't belong to an extension). > > > >>>>> > > > >>>>> Pros: > > > >>>>> * It does a clear separation between applications (accessible > from > > > the > > > >>>>> application panel) and content (accessible from the navigation > > > panel). > > > >>>> The > > > >>>>> navigation panel is currently mixing application pages and (user) > > > >> content > > > >>>>> pages. > > > >>>>> * The administrator doesn't need to update the navigation panel > > > >>>>> configuration to exclude a top level application home page each > > time > > > an > > > >>>>> application is installed > > > >>>>> * The hidden top level extension code pages are not shown even > when > > > >> "show > > > >>>>> hidden pages" is set to true > > > >>>>> * The user top level pages created later on appear in the tree > > > >>>>> automatically > > > >>>>> > > > >>>>> Cons: > > > >>>>> * The user won't be able to navigate easily to an application > home > > > >> page: > > > >>>>> ** if the application panel is not shown > > > >>>>> ** or if the application doesn't provide an application panel > entry > > > >>>>> ** or if the administrator has removed the entry from the > > application > > > >>>> panel > > > >>>>> > > > >>>>> > > > >>>> > > > >>> > > > >>> > > > >>>> S4: I don't know if for our users this separation between apps and > > > >> content > > > >>>> is very clear. > > > >>> > > > >>> > > > >>> I think our users (or their administrators at least) want to > separate > > > the > > > >>> applications from the content. So I think it would be good to have > > > >>> something dedicated to applications, the application panel, and > > > something > > > >>> dedicated to content, the navigation panel. > > > >> > > > >> > > > > > > > >> I’m seeing this a bit as a “hack" since the separation would exist > in > > > the > > > >> Nav panel but not elsewhere (AllDocs, other trees such as the > > > Rename/Copy > > > >> ones, etc). > > > >> > > > > > > > > I don't get it. The blacklist / whitelist would be applied *only* to > > the > > > > navigation panel also so what you propose is not consistent either. > > > > > > In the end it boils down to how you view the Navigation panel I think. > > > > > > I view it as something that can be controlled by the user to decide > what > > > to see/not see. > > > > > > Deciding to see or not the apps is a choice. > > > > > > > > > > >> I think if we want that separation we need to think about it more > > > >> globally. AFAIR we had some discussions about this separation > already > > > and > > > >> the proposed solution were different than the one proposed here. So > if > > > you > > > >> want to go in this direction, we need to review the previous > proposals > > > and > > > >> think more globally which IMO is going to take a lot of time. > > > >> > > > >> > > > > > > > >> I’m still thinking that we should allow users to define a white list > > > and a > > > >> black list and that’s all. That will cover all use cases that a > > generic > > > >> platform requires. > > > >> > > > > > > > > Did you read the cons? Having to manually update the blacklist > whenever > > > you > > > > install an application is a pain. > > > > > > Only if you don’t want to see the app you added in the nav panel :) > > > > > > BTW I said that I find it ok to have this “app filter” but as one of > the > > > white list filters that can be applied. So I’m not against it if it’s > > > configurable. > > > > > > > And what about the hidden pages? > > > > > > You mean the blacklisted pages? > > > > > > > Don't > > > > you find it hard to manage a blacklist of 28+ excludes? > > > > > > Sure. And again I said I’m fine with with having this whitelist filter > ;) > > > > > > > Solution 4 doesn't > > > > require maintenance from an administrator. When you install an app > it's > > > top > > > > level pages are excluded automatically. > > > > > > > > > > > BTW I’m not sure that’s enough. For example several apps have subspaces > > > such as a Data space and a Code space. This means that the Data space > > would > > > be displayed and thus the app will be displayed in the nav panel, no? > > > > > > > No. The implementation I had in mind for Solution 4 is very simple: check > > if the top level page itself is part of an extension. That means > > Menu.WebHome, Sandbox.WebHome, XWiki.WebHome, etc. Checking if there is > > some nested child page created by the user inside a top level page is way > > to complex and time consuming. So it doesn't matter if the application > has > > Code and Data nested pages. What matters is that the home page of the > > application is part of an extension and thus that page and all its > children > > will not appear in the navigation panel. > > > > > > > > > > Another note: I’m probably not understanding something because I don’t > > see > > > the point of hiding, say, ReleaseNotes.Archives when we’ll display > > > ReleaseNotes.Data.*. It could even be seen as a regression (I’m > assuming > > in > > > this example that ReleaseNotes.Archives is a page of the ReleaseNotes > > app, > > > which it isn’t FTM). > > > > > > > > > > > I also fail to see how this will remove XWiki and Home from the Nav > menu > > > since they’re not apps/extensions… > > > > > > > Solution 4 is about top level *pages* that *belong* to an extension. If > the > > XWiki and Home pages (WebHomes) wouldn't be part of an extension then you > > wouldn't have them installed with the Standard flavor. > > > > XWiki.WebHome > > https://github.com/xwiki/xwiki-platform/blob/master/ > > xwiki-platform-distribution/xwiki-platform-distribution- > ui/xwiki-platform- > > distribution-ui-base/src/main/resources/XWiki/WebHome.xml > > is part of xwiki-platform-distribution-ui > > > > Main.WebHome > > https://github.com/xwiki/xwiki-platform/blob/master/ > > xwiki-platform-distribution/xwiki-platform-distribution- > > flavor/xwiki-platform-distribution-flavor-common/ > src/main/resources/Main/ > > WebHome.xml > > is part of xwiki-platform-distribution-flavor-common > > > > So both would be excluded (along with all their child pages) from the > > navigation tree. Main.WebHome could be kept though if we check also the > > page type (as Thomas mentioned): keep top level pages that belong to an > > extension if they are "editable" (based on their type, the XAR page type > > introduced by Thomas recently). > > > > > > > > > > Last point: when you say “top level pages are excluded” you mean > default > > > extension pages, not top level pages created by the app when it’s used, > > > right? > > > > > > > The plan would be to use the Extension Manager API to check if a page is > > part of an extension and ATM this is limited to the pages that are > include > > in the extension XAR package. If the application creates at runtime a top > > level page then that page would be shown. > > > > Sure, that's why Solution 4 has this: "[...] allowing the administrator to make some exceptions (e.g. keep the home page)." The Procedures app doesn't have any top level page (all its pages are nested inside XWiki). The top level category pages created with the Procedures app (actually using the Category page template from the Create page wizard) are user content (not part of an extension) and thus will be visible in the navigation panel. they expect is to see only their content in the navigation tree. And of course, for the use cases you mentioned the "exception list" of Solution 4 should be enough.

On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica) &lt;valicac(a)gmail.com&gt; wrote: S4 is only related to installed extensions, application you create in the wiki using AWM for example would behave as content page from navigation panel point of view. -- Thomas Mortagne