On Thu, May 3, 2018 at 12:07 PM, Vincent Massol <vinc...@massol.net> wrote:
> > > > On 3 May 2018, at 10:58, 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. > > -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 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. Also they might create their own apps and they will want > > those to be part of the navigation. The ideal navigation should be able > to > > state some important pages to be shown (static aspect), order that list > in > > terms of priority, and later contain and navigate to pages created by the > > user or team (dynamic aspect). Adding metadatas to pages and creating > apps > > on top of content is a major feature of XWiki and I don't want to remove > > these pages from the navigation. > > -0 > > > > I prefer solution 3, but with the ability to sort and also to include > some > > dynamic parts :) is this possible? > > > > Thanks, > > Caty > > > > > >> > >> I prefer solution 4. > >> > >> WDYT? > >> > >> Thanks, > >> Marius > >
