[xwiki-devs] [Proposal] Solutions to hide some pages from the navigation panel
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
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 <[email protected]> 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
On Wed, May 2, 2018 at 7:18 PM, Vincent Massol <[email protected]> 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 < [email protected]> 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
On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea <[email protected]> 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).
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 ?
I prefer solution 4.
WDYT?
Thanks, Marius
-1 for 1) -- Thomas Mortagne
On Wed, May 2, 2018 at 7:24 PM, Thomas Mortagne <[email protected]> wrote:
On Wed, May 2, 2018 at 6:02 PM, Marius Dumitru Florea <[email protected]> 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 case (only for the top level) will do the pagination in Velocity. I think it's OK because having thousands of pages at the top level is quite uncommon. The top level defines the "categories" (the buckets) where the users put content so it doesn't make sense to have many pages there at the top level.
I prefer solution 4.
WDYT?
Thanks, Marius
-1 for 1)
-- Thomas Mortagne
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 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
On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 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
On Thu, May 3, 2018 at 12:07 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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
Hi Caty,
On 3 May 2018, at 12:14, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Thu, May 3, 2018 at 12:07 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 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
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically
Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the rest of the apps I think.
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
On 3 May 2018, at 12:32, Marius Dumitru Florea <[email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically
Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc). I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation already and the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time. I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires. Then we can work on optimizing this later on when we decide how we do the separation between Content and apps and it’ll depend a lot on how we do it. If we don’t fo this we risk rushing into a suboptimal solution. WDYT? Thanks -Vincent
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the rest of the apps I think.
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
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 12:32, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically
Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc).
I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either.
I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation already and the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time.
I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires.
Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain. And what about the hidden pages? Don't you find it hard to manage a blacklist of 28+ excludes? Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically. When you create a top level page, it's shown automatically in the tree.
Then we can work on optimizing this later on when we decide how we do the separation between Content and apps and it’ll depend a lot on how we do it.
If we don’t fo this we risk rushing into a suboptimal solution.
WDYT?
Thanks -Vincent
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the rest
of
the apps I think.
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
Hi Marius, See below
On 3 May 2018, at 13:24, Marius Dumitru Florea <[email protected]> wrote:
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 12:32, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically
Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc).
I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either.
In the end it boils down to how you view the Navigation panel I think. I view it as something that can be controlled by the user to decide what to see/not see. Deciding to see or not the apps is a choice.
I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation already and the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time.
I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires.
Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain.
Only if you don’t want to see the app you added in the nav panel :) BTW I said that I find it ok to have this “app filter” but as one of the white list filters that can be applied. So I’m not against it if it’s configurable.
And what about the hidden pages?
You mean the blacklisted pages?
Don't you find it hard to manage a blacklist of 28+ excludes?
Sure. And again I said I’m fine with with having this whitelist filter ;)
Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically.
BTW I’m not sure that’s enough. For example several apps have subspaces such as a Data space and a Code space. This means that the Data space would be displayed and thus the app will be displayed in the nav panel, no? Another note: I’m probably not understanding something because I don’t see the point of hiding, say, ReleaseNotes.Archives when we’ll display ReleaseNotes.Data.*. It could even be seen as a regression (I’m assuming in this example that ReleaseNotes.Archives is a page of the ReleaseNotes app, which it isn’t FTM). I also fail to see how this will remove XWiki and Home from the Nav menu since they’re not apps/extensions… Last point: when you say “top level pages are excluded” you mean default extension pages, not top level pages created by the app when it’s used, right?
When you create a top level page, it's shown automatically in the tree.
Thanks -Vincent
Then we can work on optimizing this later on when we decide how we do the separation between Content and apps and it’ll depend a lot on how we do it.
If we don’t fo this we risk rushing into a suboptimal solution.
WDYT?
Thanks -Vincent
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the rest
of
the apps I think.
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
On Thu, May 3, 2018 at 3:01 PM, Vincent Massol <[email protected]> wrote:
Hi Marius,
See below
On 3 May 2018, at 13:24, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 12:32, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an application is installed * The hidden top level extension code pages are not shown even when "show hidden pages" is set to true * The user top level pages created later on appear in the tree automatically
Cons: * The user won't be able to navigate easily to an application home page: ** if the application panel is not shown ** or if the application doesn't provide an application panel entry ** or if the administrator has removed the entry from the application panel
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc).
I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either.
In the end it boils down to how you view the Navigation panel I think.
I view it as something that can be controlled by the user to decide what to see/not see.
Deciding to see or not the apps is a choice.
I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation already
and
the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time.
I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires.
Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain.
Only if you don’t want to see the app you added in the nav panel :)
BTW I said that I find it ok to have this “app filter” but as one of the white list filters that can be applied. So I’m not against it if it’s configurable.
And what about the hidden pages?
You mean the blacklisted pages?
Don't you find it hard to manage a blacklist of 28+ excludes?
Sure. And again I said I’m fine with with having this whitelist filter ;)
Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically.
BTW I’m not sure that’s enough. For example several apps have subspaces such as a Data space and a Code space. This means that the Data space would be displayed and thus the app will be displayed in the nav panel, no?
No. The implementation I had in mind for Solution 4 is very simple: check if the top level page itself is part of an extension. That means Menu.WebHome, Sandbox.WebHome, XWiki.WebHome, etc. Checking if there is some nested child page created by the user inside a top level page is way to complex and time consuming. So it doesn't matter if the application has Code and Data nested pages. What matters is that the home page of the application is part of an extension and thus that page and all its children will not appear in the navigation panel.
Another note: I’m probably not understanding something because I don’t see the point of hiding, say, ReleaseNotes.Archives when we’ll display ReleaseNotes.Data.*. It could even be seen as a regression (I’m assuming in this example that ReleaseNotes.Archives is a page of the ReleaseNotes app, which it isn’t FTM).
I also fail to see how this will remove XWiki and Home from the Nav menu since they’re not apps/extensions…
Solution 4 is about top level *pages* that *belong* to an extension. If the XWiki and Home pages (WebHomes) wouldn't be part of an extension then you wouldn't have them installed with the Standard flavor. XWiki.WebHome https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribut... is part of xwiki-platform-distribution-ui Main.WebHome https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-distribut... is part of xwiki-platform-distribution-flavor-common So both would be excluded (along with all their child pages) from the navigation tree. Main.WebHome could be kept though if we check also the page type (as Thomas mentioned): keep top level pages that belong to an extension if they are "editable" (based on their type, the XAR page type introduced by Thomas recently).
Last point: when you say “top level pages are excluded” you mean default extension pages, not top level pages created by the app when it’s used, right?
The plan would be to use the Extension Manager API to check if a page is part of an extension and ATM this is limited to the pages that are include in the extension XAR package. If the application creates at runtime a top level page then that page would be shown.
When you create a top level page, it's shown automatically in the tree.
Thanks -Vincent
Then we can work on optimizing this later on when we decide how we do
the
separation between Content and apps and it’ll depend a lot on how we do it.
If we don’t fo this we risk rushing into a suboptimal solution.
WDYT?
Thanks -Vincent
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the rest
of
the apps I think.
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
On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 3:01 PM, Vincent Massol <[email protected]> wrote:
Hi Marius,
See below
On 3 May 2018, at 13:24, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 12:32, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 application home page each time an > application is installed > * The hidden top level extension code pages are not shown even when "show > hidden pages" is set to true > * The user top level pages created later on appear in the tree > automatically > > Cons: > * The user won't be able to navigate easily to an application home page: > ** if the application panel is not shown > ** or if the application doesn't provide an application panel entry > ** or if the administrator has removed the entry from the application panel > >
S4: I don't know if for our users this separation between apps and content is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc).
I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either.
In the end it boils down to how you view the Navigation panel I think.
I view it as something that can be controlled by the user to decide what to see/not see.
Deciding to see or not the apps is a choice.
I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation already
and
the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time.
I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires.
Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain.
Only if you don’t want to see the app you added in the nav panel :)
BTW I said that I find it ok to have this “app filter” but as one of the white list filters that can be applied. So I’m not against it if it’s configurable.
And what about the hidden pages?
You mean the blacklisted pages?
Don't you find it hard to manage a blacklist of 28+ excludes?
Sure. And again I said I’m fine with with having this whitelist filter ;)
Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically.
BTW I’m not sure that’s enough. For example several apps have subspaces such as a Data space and a Code space. This means that the Data space would be displayed and thus the app will be displayed in the nav panel, no?
No. The implementation I had in mind for Solution 4 is very simple: check if the top level page itself is part of an extension. That means Menu.WebHome, Sandbox.WebHome, XWiki.WebHome, etc. Checking if there is some nested child page created by the user inside a top level page is way to complex and time consuming. So it doesn't matter if the application has Code and Data nested pages. What matters is that the home page of the application is part of an extension and thus that page and all its children will not appear in the navigation panel.
Another note: I’m probably not understanding something because I don’t
see
the point of hiding, say, ReleaseNotes.Archives when we’ll display ReleaseNotes.Data.*. It could even be seen as a regression (I’m assuming in this example that ReleaseNotes.Archives is a page of the ReleaseNotes app, which it isn’t FTM).
I also fail to see how this will remove XWiki and Home from the Nav menu since they’re not apps/extensions…
Solution 4 is about top level *pages* that *belong* to an extension. If the XWiki and Home pages (WebHomes) wouldn't be part of an extension then you wouldn't have them installed with the Standard flavor.
XWiki.WebHome https://github.com/xwiki/xwiki-platform/blob/master/ xwiki-platform-distribution/xwiki-platform-distribution-ui/xwiki-platform- distribution-ui-base/src/main/resources/XWiki/WebHome.xml is part of xwiki-platform-distribution-ui
Main.WebHome https://github.com/xwiki/xwiki-platform/blob/master/ xwiki-platform-distribution/xwiki-platform-distribution- flavor/xwiki-platform-distribution-flavor-common/src/main/resources/Main/ WebHome.xml is part of xwiki-platform-distribution-flavor-common
So both would be excluded (along with all their child pages) from the navigation tree. Main.WebHome could be kept though if we check also the page type (as Thomas mentioned): keep top level pages that belong to an extension if they are "editable" (based on their type, the XAR page type introduced by Thomas recently).
Last point: when you say “top level pages are excluded” you mean default extension pages, not top level pages created by the app when it’s used, right?
The plan would be to use the Extension Manager API to check if a page is part of an extension and ATM this is limited to the pages that are include in the extension XAR package. If the application creates at runtime a top level page then that page would be shown.
My problem with this solution is that sometimes we want the mix. There are wikis that have 2 major apps installed and they would want the pages created with those apps to appear in the Navigation. For example if you install the Procedures app, you might want to have some generic pages prioritized in the tree and after to have all the procedures pages dynamically listed. Or let's say there is a website flavor that has some static pages like Home, Contact, About and it also has an FAQ or a Blog app installed. I would like all these pages to be listed in the navigation tree. Or on xwiki.org, I would like to still be able to see pages from Release Notes app listead together with pages that are not an app yet, like Roadmap, etc.
When you create a top level page, it's shown automatically in the tree.
Thanks -Vincent
Then we can work on optimizing this later on when we decide how we do
the
separation between Content and apps and it’ll depend a lot on how we
do
it.
If we don’t fo this we risk rushing into a suboptimal solution.
WDYT?
Thanks -Vincent
Also they might create their own apps and they will want those to be part of the navigation.
They would want to have an entry in the application panel like the
rest
of
the apps I think.
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
On Thu, May 3, 2018 at 4:28 PM, Ecaterina Moraru (Valica) <[email protected]
wrote:
On Thu, May 3, 2018 at 4:21 PM, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 3:01 PM, Vincent Massol <[email protected]> wrote:
Hi Marius,
See below
On 3 May 2018, at 13:24, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 1:44 PM, Vincent Massol <[email protected]> wrote:
On 3 May 2018, at 12:32, Marius Dumitru Florea < [email protected]> wrote:
On Thu, May 3, 2018 at 11:58 AM, Ecaterina Moraru (Valica) < [email protected]> wrote:
> On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < > [email protected]> 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 application home page each time an >> application is installed >> * The hidden top level extension code pages are not shown even when "show >> hidden pages" is set to true >> * The user top level pages created later on appear in the tree >> automatically >> >> Cons: >> * The user won't be able to navigate easily to an application home page: >> ** if the application panel is not shown >> ** or if the application doesn't provide an application panel entry >> ** or if the administrator has removed the entry from the application > panel >> >> >
> S4: I don't know if for our users this separation between apps and content > is very clear.
I think our users (or their administrators at least) want to separate the applications from the content. So I think it would be good to have something dedicated to applications, the application panel, and something dedicated to content, the navigation panel.
I’m seeing this a bit as a “hack" since the separation would exist in the Nav panel but not elsewhere (AllDocs, other trees such as the Rename/Copy ones, etc).
I don't get it. The blacklist / whitelist would be applied *only* to the navigation panel also so what you propose is not consistent either.
In the end it boils down to how you view the Navigation panel I think.
I view it as something that can be controlled by the user to decide what to see/not see.
Deciding to see or not the apps is a choice.
I think if we want that separation we need to think about it more globally. AFAIR we had some discussions about this separation
already and
the proposed solution were different than the one proposed here. So if you want to go in this direction, we need to review the previous proposals and think more globally which IMO is going to take a lot of time.
I’m still thinking that we should allow users to define a white list and a black list and that’s all. That will cover all use cases that a generic platform requires.
Did you read the cons? Having to manually update the blacklist whenever you install an application is a pain.
Only if you don’t want to see the app you added in the nav panel :)
BTW I said that I find it ok to have this “app filter” but as one of the white list filters that can be applied. So I’m not against it if it’s configurable.
And what about the hidden pages?
You mean the blacklisted pages?
Don't you find it hard to manage a blacklist of 28+ excludes?
Sure. And again I said I’m fine with with having this whitelist filter ;)
Solution 4 doesn't require maintenance from an administrator. When you install an app it's top level pages are excluded automatically.
BTW I’m not sure that’s enough. For example several apps have subspaces such as a Data space and a Code space. This means that the Data space would be displayed and thus the app will be displayed in the nav panel, no?
No. The implementation I had in mind for Solution 4 is very simple: check if the top level page itself is part of an extension. That means Menu.WebHome, Sandbox.WebHome, XWiki.WebHome, etc. Checking if there is some nested child page created by the user inside a top level page is way to complex and time consuming. So it doesn't matter if the application has Code and Data nested pages. What matters is that the home page of the application is part of an extension and thus that page and all its children will not appear in the navigation panel.
Another note: I’m probably not understanding something because I don’t
see
the point of hiding, say, ReleaseNotes.Archives when we’ll display ReleaseNotes.Data.*. It could even be seen as a regression (I’m assuming in this example that ReleaseNotes.Archives is a page of the ReleaseNotes app, which it isn’t FTM).
I also fail to see how this will remove XWiki and Home from the Nav menu since they’re not apps/extensions…
Solution 4 is about top level *pages* that *belong* to an extension. If the XWiki and Home pages (WebHomes) wouldn't be part of an extension then you wouldn't have them installed with the Standard flavor.
XWiki.WebHome https://github.com/xwiki/xwiki-platform/blob/master/ xwiki-platform-distribution/xwiki-platform-distribution- ui/xwiki-platform- distribution-ui-base/src/main/resources/XWiki/WebHome.xml is part of xwiki-platform-distribution-ui
Main.WebHome https://github.com/xwiki/xwiki-platform/blob/master/ xwiki-platform-distribution/xwiki-platform-distribution- flavor/xwiki-platform-distribution-flavor-common/ src/main/resources/Main/ WebHome.xml is part of xwiki-platform-distribution-flavor-common
So both would be excluded (along with all their child pages) from the navigation tree. Main.WebHome could be kept though if we check also the page type (as Thomas mentioned): keep top level pages that belong to an extension if they are "editable" (based on their type, the XAR page type introduced by Thomas recently).
Last point: when you say “top level pages are excluded” you mean
default
extension pages, not top level pages created by the app when it’s used, right?
The plan would be to use the Extension Manager API to check if a page is part of an extension and ATM this is limited to the pages that are include in the extension XAR package. If the application creates at runtime a top level page then that page would be shown.
My problem with this solution is that sometimes we want the mix. There are wikis that have 2 major apps installed and they would want the pages created with those apps to appear in the Navigation.
Sure, that's why Solution 4 has this: "[...] allowing the administrator to make some exceptions (e.g. keep the home page)."
For example if you install the Procedures app, you might want to have some generic pages prioritized in the tree and after to have all the procedures pages dynamically listed.
The Procedures app doesn't have any top level page (all its pages are nested inside XWiki). The top level category pages created with the Procedures app (actually using the Category page template from the Create page wizard) are user content (not part of an extension) and thus will be visible in the navigation panel.
Or let's say there is a website flavor that has some static pages like Home, Contact, About and it also has an FAQ or a Blog app installed. I would like all these pages to be listed in the navigation tree. Or on xwiki.org, I would like to still be able to see pages from Release Notes app listead together with pages that are not an app yet, like Roadmap, etc.
From the user feedback it seems that all these are exceptions. By default they expect is to see only their content in the navigation tree. And of course, for the use cases you mentioned the "exception list" of Solution 4 should be enough.
When you create a top level page, it's shown automatically in the tree.
Thanks -Vincent
Then we can work on optimizing this later on when we decide how we
do
the
separation between Content and apps and it’ll depend a lot on how we do it.
If we don’t fo this we risk rushing into a suboptimal solution.
WDYT?
Thanks -Vincent
> Also they might create their own apps and they will want > those to be part of the navigation.
They would want to have an entry in the application panel like the
rest of
the apps I think.
> 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
Hi Caty,
On 3 May 2018, at 10:58, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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
On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 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.
S4 is only related to installed extensions, application you create in the wiki using AWM for example would behave as content page from navigation panel point of view.
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
-- Thomas Mortagne
On 3 May 2018, at 14:04, Thomas Mortagne <[email protected]> wrote:
On Thu, May 3, 2018 at 10:58 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, May 2, 2018 at 7:02 PM, Marius Dumitru Florea < [email protected]> 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 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.
S4 is only related to installed extensions, application you create in the wiki using AWM for example would behave as content page from navigation panel point of view.
That’s a good point that I hadn’t thought about that we need to add to the list of UC. And that’s exactly why I’m advocating for a generic solution (if technically possible). There’ll always be cases we won’t have taken into account. So what if you don’t want your AWM app to be displayed in the Nav menu? Since this topic is complex, we should probably list all the UCs in a table. Thanks -Vincent
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
-- Thomas Mortagne
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 < [email protected]> 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 are useful for the navigation. Although creating top level pages should happen less often than creating nested pages under the existing top level pages.
err, how? The create button displayed on the homepage - the only create button that you see when you start on an empty wiki - creates top level pages! (there's actually a bug in 9.11.3, I explicitly changed the location to the "Home" page, and it still created a toplevel page). Indeed, if the administrator has an idea about what would be put on the wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/ he might not want to, leaving users to organise their content as they wish.
* 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).
This is _very_ close to the cases I had, but the difference between "exactly" and "very close" is relevant, to me: obviously, some XWiki, Sandbox and other standard content needed to be removed, but also a custom page that I had created and manually put in the application panel. So, in my opinion, the work to do this is comparable to the work for implementing explicit blacklisted roots, so between this and 2, I choose 2. Long story short: I believe, as Vincent said, that we need to have the generic whitelist / blacklist parameters for the documentTree macro, in order to cover the maximum cases possible, and in my opinion, they all exist, because there is a great diversity in what users can do on the wiki but also in how they interpret some things: some people see applications as "special", some others don't, etc. For the navigation panel default blacklist we can make some dynamic computing of the parameters we pass to the documentTree call, e.g. all extensions, or some configuration in administration. As a priority choice between blacklist and whitelist, I would choose blacklist, as some sort of whitelist already exists, even if not fully complete and anyway it covers less "user content" cases than the blacklist one. Thanks, Anca
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
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 <[email protected]>:
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 < [email protected]> 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 are useful for the navigation. Although creating top level pages should happen less often than creating nested pages under the existing top level pages.
err, how? The create button displayed on the homepage - the only create button that you see when you start on an empty wiki - creates top level pages! (there's actually a bug in 9.11.3, I explicitly changed the location to the "Home" page, and it still created a toplevel page).
Indeed, if the administrator has an idea about what would be put on the wiki, he can create the toplevel pages, but 1/ it's not always the case, 2/ he might not want to, leaving users to organise their content as they wish.
* 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).
This is _very_ close to the cases I had, but the difference between "exactly" and "very close" is relevant, to me: obviously, some XWiki, Sandbox and other standard content needed to be removed, but also a custom page that I had created and manually put in the application panel.
So, in my opinion, the work to do this is comparable to the work for implementing explicit blacklisted roots, so between this and 2, I choose 2.
Long story short: I believe, as Vincent said, that we need to have the generic whitelist / blacklist parameters for the documentTree macro, in order to cover the maximum cases possible, and in my opinion, they all exist, because there is a great diversity in what users can do on the wiki but also in how they interpret some things: some people see applications as "special", some others don't, etc.
For the navigation panel default blacklist we can make some dynamic computing of the parameters we pass to the documentTree call, e.g. all extensions, or some configuration in administration.
As a priority choice between blacklist and whitelist, I would choose blacklist, as some sort of whitelist already exists, even if not fully complete and anyway it covers less "user content" cases than the blacklist one.
Thanks, Anca
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
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
participants (6)
-
Anca Luca -
Ecaterina Moraru (Valica) -
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol