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

[Guillaume Delhumeau]

I prefer solution 4, that's the more intuitive. You just should add a
button to enable/disable the filter, so if you really need to see
everything, you can. To me it's simple and cover 99% of everyday usages.

+1 for S4.

Thanks,

2018-05-03 17:20 GMT+02:00 Anca Luca :

> 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.flo...@xwiki.com> wrote:
>
> > 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
> >
>
> 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.
>
>
> >
> >
> > Solution 2: Blacklisting
> >
> > Add support for specifying a list of (top level) pages to exclude from
> the
> > navigation panel.
> >
>
> 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).
>
>
> >
> > 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
> >
>
> 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 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 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.
>
>
> > * 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.
>
>
> >
> > Solution 3: Whitelisting
> >
> > Add support for controlling the list of top level pages that are
> displayed
> > in the navigation panel.
> >
>
> 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".
>
>
> >
> > Pros:
> > * the 

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

[Anca Luca]

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.flo...@xwiki.com> wrote:

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

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.


>
>
> Solution 2: Blacklisting
>
> Add support for specifying a list of (top level) pages to exclude from the
> navigation panel.
>

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


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

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


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


>
> Solution 3: Whitelisting
>
> Add support for controlling the list of top level pages that are displayed
> in the navigation panel.
>

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


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

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

[Marius Dumitru Florea]

On Thu, May 3, 2018 at 4:28 PM, Ecaterina Moraru (Valica)  wrote:

> On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > On Thu, May 3, 2018 at 3:01 PM, Vincent Massol 
> wrote:
> >
> > > Hi Marius,
> > >
> > > See below
> > >
> > > > On 3 May 2018, at 13:24, Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > > >
> > > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol 
> > > wrote:
> > > >
> > > >>
> > > >>
> > > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea <
> > > >> mariusdumitru.flo...@xwiki.com> wrote:
> > > >>>
> > > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
> > > >>> vali...@gmail.com> wrote:
> > > >>>
> > >  On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> > >  mariusdumitru.flo...@xwiki.com> wrote:
> > > 
> > > > 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) 

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

[Ecaterina Moraru (Valica)]

On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Thu, May 3, 2018 at 3:01 PM, Vincent Massol  wrote:
>
> > Hi Marius,
> >
> > See below
> >
> > > On 3 May 2018, at 13:24, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol 
> > wrote:
> > >
> > >>
> > >>
> > >>> On 3 May 2018, at 12:32, Marius Dumitru Florea <
> > >> mariusdumitru.flo...@xwiki.com> wrote:
> > >>>
> > >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
> > >>> vali...@gmail.com> wrote:
> > >>>
> >  On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> >  mariusdumitru.flo...@xwiki.com> wrote:
> > 
> > > 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 

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

[Marius Dumitru Florea]

On Thu, May 3, 2018 at 3:01 PM, Vincent Massol  wrote:

> Hi Marius,
>
> See below
>
> > On 3 May 2018, at 13:24, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > On Thu, May 3, 2018 at 1:44 PM, Vincent Massol 
> wrote:
> >
> >>
> >>
> >>> On 3 May 2018, at 12:32, Marius Dumitru Florea <
> >> mariusdumitru.flo...@xwiki.com> wrote:
> >>>
> >>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
> >>> vali...@gmail.com> wrote:
> >>>
>  On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
>  mariusdumitru.flo...@xwiki.com> wrote:
> 
> > 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 

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

[Vincent Massol]

> On 3 May 2018, at 14:04, Thomas Mortagne  wrote:
> 
> On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica)
>  wrote:
>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>> 
>>> 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.
>> -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 

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

[Vincent Massol]

Hi Marius,

See below

> On 3 May 2018, at 13:24, Marius Dumitru Florea 
>  wrote:
> 
> On Thu, May 3, 2018 at 1:44 PM, Vincent Massol  wrote:
> 
>> 
>> 
>>> On 3 May 2018, at 12:32, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>>> 
>>> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
>>> vali...@gmail.com> wrote:
>>> 
 On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
 mariusdumitru.flo...@xwiki.com> wrote:
 
> 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
 

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

[Vincent Massol]

Hi Caty,

> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica)  wrote:
> 
> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:

[snip]

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

[snip]

> I prefer solution 3, but with the ability to sort and also to include some
> dynamic parts :) is this possible?
> 
> Thanks,
> Caty

FTR I don’t like solution 3 alone because I find it a bit less useful than 
blacklisting. If the need is to display only some known elements in the Nav, 
it’s already possible (not easy though ;)) to create your own Nav tree.

IMO the difficulty is when users want to benefit from the automatic navigation 
for new pages (they’re listed by default) but they also want to control things 
they don’t want to see in the navigation (not because they necessarily want to 
hide them in the wiki for everyone to see but because it’s a navigation and 
they want to not display some parts that are less important - ie not provide a 
top level nav to them).

This is why I’m advocating to have both a blacklist and a whitelist so that we 
can support all use cases. If this is doable technically then it’s the best 
solution. Now the Nav tree already has an issue: it’s very slow. So we need to 
fix this slowness and yet be able to filter with a whitelist and a blacklist 
too :)

I guess it depends if we want to fix the configurability issue for good or only 
fix some aspects of it (ie. XWiki space, Home space, apps when they’re 
installed).

[snip]

Thanks
-Vincent

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

[Vincent Massol]

> On 3 May 2018, at 12:32, Marius Dumitru Florea 
>  wrote:
> 
> On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
> vali...@gmail.com> wrote:
> 
>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
>> mariusdumitru.flo...@xwiki.com> wrote:
>> 
>>> 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 

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

[Marius Dumitru Florea]

On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
> > 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 

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

[Vincent Massol]

Hi Caty,

> On 3 May 2018, at 12:14, Ecaterina Moraru (Valica)  wrote:
> 
> On Thu, May 3, 2018 at 12:07 PM, Vincent Massol  wrote:
> 
>> 
>> 
>>> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) 
>> wrote:
>>> 
>>> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
>>> mariusdumitru.flo...@xwiki.com> wrote:
>>> 
 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.
>>> -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
>> 
>> What you’re saying is that users will always want to show the full tree in
>> the Navigation panel and that there are no use cases where they’ll want to
>> hide some parts (that they have created). I believe that this use case
>> exists.
>> 
> 
> If they want to hide something, they have the Hidden pages mechanism.

I’m trying to read between the lines and I guess you mean this because you 
assume that users will want the Navigation Panel in sync with the rest of the 
features of XWiki, i.e. for ex that when they search they don’t see results 
that don’t appear in the Nav panel, right?

So you’re saying in essence that you want the Nav panel to represent exactly 
what the users sees in this wiki….

However if that were true, we wouldn’t be having this discussion that we have 
now… It’s because users want to control the navigation panel content that we’re 
discussing this ;)

You mention below that you like the whitelist, but you’ll get exactly the same 
“discrepancy" issue: when you search users will find pages not listed in the 
nav panel!

Also this is really not reasonable to say “users should use the hide page 
mechanism” because 1) it’ll mean those pages won’t be found in the search for 
example 2) it’s just impossibly hard to use to hide a full page and all its 
children (it works at a page level) and 3) you can hide some pages but as soon 
as someone adds a new page in that space, it’ll appear in the Nav Panel.

So, I don’t believe they can use the Hidden pages mechanism.

Do you agree?

Thanks
-Vincent

> 
> 
>> 
>> This is why we need to agree about the use cases first before even
>> discussing solutions!
>> 
>> And this is why in my previous reply I’ve put what I consider to be the
>> use cases we need to implement. Pasting it again here:
>> 
>> “
>> * I believe we need to satisfy **all** the following generic use cases
>> (with the whitelist taking precedence for example):
>> ** Be able for the admin user to black list some nodes and children
>> ** Be able for the admin user to white list some nodes and children
>> “
>> 
>> So 

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

[Marius Dumitru Florea]

On Wed, May 2, 2018 at 7:24 PM, Thomas Mortagne 
wrote:

> On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea
>  wrote:
> > 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
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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).
>
>

> Maybe a slightly better default criteria could be "extension page with
> type denying edit" (which means things like Main.WebHome won't be
> hidden by default).
>

Good point! We should do this indeed.


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

> Isn't this going to be a pain for pagination too since it's based on
> an information which is not stored in the database ?
>

Well, in this 

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

[Marius Dumitru Florea]

On Wed, May 2, 2018 at 7:18 PM, Vincent Massol  wrote:

> Hi Marius,
>
> Thanks for working on this.
>
> Some general remarks/ideas.
>
> * I believe we need to satisfy **all** the following generic use cases
> (with the whitelist taking precedence for example):
> ** Be able for the admin user to black list some nodes and children
> ** Be able for the admin user to white list some nodes and children
>

I haven't seen any user requests for these *generic* use cases. What I've
seen are requests for removing from the tree *top level pages* that belong
to applications:

-
https://forum.xwiki.org/t/release-notes-how-to-remove-it-from-navigation/494
"I have installed the cool application of “Release Notes” but I would like
to have access to my Release Notes only by the Application panel and not by
the Navigation menu."

http://jira.xwiki.org/browse/XWIKI-12895
"This could be a field where one specifies a list of root nodes (more than
one) than one would like to exclude."

"The example discussed yesterday was about removing the "XWiki" space from
the list (not really "content" from an end user perspective), the "Main"
space (e.g. if used together with the showRoot="true" people are confused
why they expand the "Home" link on the wiki and get another "Home" link
inside pointing to the same page), and the "Sandbox" (as it is a
playground, and not "real content" - a wiki owner might decide that
"Sandbox" will linked from a separate panel, and should not be mixed with
the "actual, serious content"). Another example is the "MoccaCalendar" that
people might not want to see in the tree because it is already in the
applications panel."

"I'm looking for something like this:
#set ($blacklistedSpaces = ['Main', 'AnnotationCode', 'ColorThemes',
'XWiki', 'Panels', 'Scheduler', 'Stats', 'AppWithinMinutes', 'Blog',
'Space1', 'Space2', 'Space3', 'Space4', 'Macros', 'Space5', 'Space6',
'Space7'])"
-

Which can be translated to:

* Exclude from the navigation panel top level pages that correspond to
applications accessible from the application panel
* Exclude from the navigation panel application pages (non user content)

The problem is at the *top level* because at the top level there are pages
that the administrator doesn't "own" (cannot rename or delete safely).



> * When the admin defines the black list and white list in the Admin UI, I
> agree that one whitelist filter he could add is the “Don’t show top level
> application pages”. However for me this is just one filter among several
> that he should be able to add. In other words he could choose this white
> list + some manual ones. I even agree that this whitelist could be turned
> on by default.
>

 I see where you go with this but I find it overly complicated.


> * I don’t see how solution 4 alone would solve the “XWiki” space needing
> to be blacklisted use case.
>

The "XWiki" page is provided by an extension so solution 4 will exclude it
by default (unless the admin adds an exception).


>
> So in other words my preference from a functional POV is both solutions 2,
> 3 and 4 :)
>
> Note that I don’t know at this point the performance cost.
>
> Thanks
> -Vincent
>
>
> > On 2 May 2018, at 18:02, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> >
> > 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
> >
> >
> > 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 

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

[Ecaterina Moraru (Valica)]

On Thu, May 3, 2018 at 12:07 PM, Vincent Massol  wrote:

>
>
> > On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) 
> wrote:
> >
> > On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> 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.
> > -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
>
> What you’re saying is that users will always want to show the full tree in
> the Navigation panel and that there are no use cases where they’ll want to
> hide some parts (that they have created). I believe that this use case
> exists.
>

If they want to hide something, they have the Hidden pages mechanism.


>
> This is why we need to agree about the use cases first before even
> discussing solutions!
>
> And this is why in my previous reply I’ve put what I consider to be the
> use cases we need to implement. Pasting it again here:
>
> “
> * I believe we need to satisfy **all** the following generic use cases
> (with the whitelist taking precedence for example):
> ** Be able for the admin user to black list some nodes and children
> ** Be able for the admin user to white list some nodes and children
> “
>
> So first let’s agree or disagree that these are real use cases we need to
> satisfy for a generic platform such as XWiki :)
>
> WDYT?
>
> Thanks
> -Vincent
>
> >
> >>
> >> 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 

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

[Vincent Massol]

> On 3 May 2018, at 10:58, Ecaterina Moraru (Valica)  wrote:
> 
> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> 
>> 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.
> -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

What you’re saying is that users will always want to show the full tree in the 
Navigation panel and that there are no use cases where they’ll want to hide 
some parts (that they have created). I believe that this use case exists.

This is why we need to agree about the use cases first before even discussing 
solutions!

And this is why in my previous reply I’ve put what I consider to be the use 
cases we need to implement. Pasting it again here:

“
* I believe we need to satisfy **all** the following generic use cases (with 
the whitelist taking precedence for example):
** Be able for the admin user to black list some nodes and children
** Be able for the admin user to white list some nodes and children
“

So first let’s agree or disagree that these are real use cases we need to 
satisfy for a generic platform such as XWiki :)

WDYT?

Thanks
-Vincent

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

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

[Ecaterina Moraru (Valica)]

On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

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

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

[Vincent Massol]

Hi Marius,

Thanks for working on this.

Some general remarks/ideas. 

* I believe we need to satisfy **all** the following generic use cases (with 
the whitelist taking precedence for example):
** Be able for the admin user to black list some nodes and children
** Be able for the admin user to white list some nodes and children

* When the admin defines the black list and white list in the Admin UI, I agree 
that one whitelist filter he could add is the “Don’t show top level application 
pages”. However for me this is just one filter among several that he should be 
able to add. In other words he could choose this white list + some manual ones. 
I even agree that this whitelist could be turned on by default.

* I don’t see how solution 4 alone would solve the “XWiki” space needing to be 
blacklisted use case.

So in other words my preference from a functional POV is both solutions 2, 3 
and 4 :)

Note that I don’t know at this point the performance cost. 

Thanks
-Vincent


> On 2 May 2018, at 18:02, Marius Dumitru Florea 
>  wrote:
> 
> 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
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> 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