On Wed, May 2, 2018 at 7:18 PM, Vincent Massol <vinc...@massol.net> 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 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 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 > > > > > > I prefer solution 4. > > > > WDYT? > > > > Thanks, > > Marius > >
