-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
None
-
7
-
[CONFSERVER-54744] Ability to restrict Label List Macro further
This feature would be very useful indeed. Content By Label would overload parent page if you want to see all labels of a parent page and its child pages, especially with complex structure.
Would be really appreciated if Label List Macro is expanded to filter labels by page and its child pages.
Thanks @Elvar for so perfectly stating the requirements!
I would like to add that this would be a HUGE improvement for enterprise-scale sites, which tend to have large groups using large spaces.
The primary audience for Confluence documentation pages will most often be new employees who may ALSO be new Confluence users.
Thus, we should not rely on pre-existing user knowledge; we should improve initial conditions to create better odds of success for all users, including novices.
Where organizations are using a very large Confluence instance to inform or educate employees, we must remember that:
- Many users have no idea where the search button is, much less the space directory.
- Searching just about any english word will return a large number of irrelevant results, causing frustrated users (as Tom W explained in the first comment).
- Users often lack the means to refine their searches. They may not have any idea which space is relevant, or even what a space is, much less when the content might have been produced or by whom.
- Users are busy, and do NOT want to read long strings of extraneous text
Best practice for documentation is to provide multiple pathways for users to find relevant content. This means that we need:
- Search mechanism for specific strings (yes)
- Tree navigation for browsing topics (yes)
- Ways for content creators to easily construct alternative page trees, such as by user goal (missing)
For example, I might write about search in Confluence, Jira, and other products under each application's Confluence page tree. A user can find the information while browsing documentation for that app, BUT success depends on the user to know where to start looking.
The handful of users who actually understand Confluence search will no doubt find those pages using that mechanism.
However, users often want to find content based on their goal ("I need Help for Searching...).
Therefore I ALSO want to present a generic "How to Search" page in a more generalized Help page tree, and then give them a directory of all search-related page labels, e.g. confluence-search, jira-search, otherapp-search, etc.
Lastly, I may want to use this macro with the same settings for parent page and included labels on pages in other spaces, such as the general IT Help space.
I wouldn't have much real estate there, so this Label List Macro would be a far better solution than Content By Label, if only it had a few more parameters 
Two use cases / Requirements
- Restrict to child pages
- Restrict to one or more labels
Secondary function
- When clicking on a label in the list it would automatically show only pages with the same restriction as above
As mentioned in this comment being able to limit labels to children and grandchildren would be very useful.
+1, came here looking for this very feature... want to be able to introduce a macro to show labels for only children/grandchildren pages. Space contains many differet labeled pages, without this feature unable to use current label macro.
Agree. Macro is well needed to be able to reduce label filter to sub pages!
Being able to filter by page and sub pages makes this feature a LOT more useful
Agree that it would be amazing to have this filtering feature. Not sure if this macro is even supported in the fabric editor though.
This is my local workaround user macro. It's defined with "No macro body". Not perfect and always concern to changes in the confluence methods. Something comparable should be easy to implement by Atlassian.
## Macro title: dsv_labels_list_child ## Kategorie: Berichte ## Macro has a body: N (heisst: Makro bekommt keinen Textblock als Input ## Body processing: Kein Makrohauptteil ## Output: Liste mit Labels und deren Seitenlinks ## ## Developed by: Hga ## Date created: 05/03/2019 ## Installed by: Hga ## Parameter: optional Label, nachdem speziell gesucht wird. Default: Alle Labels ## @param SLabel:title=Search-Label|type=string|required=false|desc=Such-Label oder leer ## ## Achtung ! Zunächst wurden die Hyperlinks mit folgenden Methoden gesetzt: ## HTML-URL: <a href="$settingsManager.getGlobalSettings().getBaseUrl()$child.getUrlPath()">$child.title</a> ## Confluence-URL: <ac:link><ri:page ri:content-title="${generalUtil.escapeXml($child.title)}"></ac:link> ## Diese habe aber ein Problem mit Sonderzeichen im Seitennamen (Seitentitel). ## Daher wurde das PageID-Format verwendet, s. auch ## https://confluence.atlassian.com/confkb/the-differences-between-various-url-formats-for-a-confluence-page-278692715.html ## ## Hinweis zu HTML-URL: href "target=" Parameter wird von Confluence weggefiltert ## ## Geklaut von https://community.atlassian.com/t5/Confluence-questions/Writing-User-Macro-to-list-children-of-page-limited-by-label/qaq-p/383362 ## und https://community.atlassian.com/t5/Confluence-questions/User-Macro-for-counting-Child-Pages-with-Label/qaq-p/898599 ## und https://confluence.atlassian.com/pages/viewpage.action?pageId=44269610&permissionViolation=true ## und vielen weiteren ## URL für PageID-Format, pageID wird im Programm mit der betreffenden ID der Seite ergänzt #set ( $baseurl = "$settingsManager.getGlobalSettings().getBaseUrl()/pages/viewpage.action?pageId" ) ## Array mit Labelname, Titel (URL-encoded) PageId und Titel (Klartext) init. ## Der Array wird nach dem Aufbau nach Labelname und Titel sortiert. ## Da er nach Blanks gesplittet wird (positionaler Aufbau), muss fuer die Sortierung der Titel URL-encoded ## mitgegeben werden. Fuer die spätere Anzeige des Seitentitels im Klartext wird er als letzter Parameter ## angehängt, stellt beim Splitten also den Rest dar. #set ( $lbltab = [] ) ## Anzahl gefundener Label-Eintraege (ohne oder mit Filterung) #set ( $lblfound = 0 ) ## Aktuelle Seite (Ausgangspunkt des Trees) bearbeiten #set( $srchpage = $pageManager.getPage($content.getId() ) ) #set ( $acttitle = $srchpage.title ) #set ( $acttienc = $generalUtil.urlEncode($srchpage.title) ) #set ( $actpgid = $srchpage.getIdAsString() ) ## Ueber die Labels der durchsuchten Seite #foreach ($label in $srchpage.labels) ## Wenn kein spezifisches Label angegeben wurde, alle nehmen #if ( !$paramSLabel ) ## Label, Page-Titel (URL-encoded=single-word) PageId und Page-Titel (Klartext) in lbltab stellen #set ( $tabentry = $label.name + " " + $acttienc + " " + $actpgid + " " + $acttitle) #set ( $result = $lbltab.add($tabentry) ) #set ( $lblfound = $lblfound + 1 ) ## Wenn spezifisches Label angegeben und gefunden wurde #elseif ( $paramSLabel == $label.name ) ## Label, Page-Titel (URL-encoded=single-word) PageId und Page-Titel (Klartext) in lbltab stellen #set ( $tabentry = $label.name + " " + $acttienc + " " + $actpgid) #set ( $result = $lbltab.add($tabentry) ) #set ( $lblfound = $lblfound + 1 ) ## Wenn spezifisches Label angegeben und nicht gefunden wurde: ignorieren #else #end #end ## Seitenbaum unterhalb der aktuellen Seite bearbeiten ## Hinweis: getChildren liefert nur die nächste Ebene, getDescendants liefert gesamten Baum ## Achtung ! getDescendents ist deprecated, getDescendants (mit "a") benutzen ! #set( $childpages = $pageManager.getPage($content.id).getDescendants() ) #foreach( $srchpage in $childpages ) #set ( $acttitle = $srchpage.title ) #set ( $acttienc = $generalUtil.urlEncode($srchpage.title) ) #set ( $actpgid = $srchpage.getIdAsString() ) ## Alle Labels einer Childpage bearbeiten #foreach ($label in $srchpage.labels) ## Wenn kein spezifisches Label angegeben wurde, alle nehmen #if ( !$paramSLabel ) ## Label, Page-Titel (URL-encoded=single-word) PageId und Page-Titel (Klartext) in lbltab stellen #set ( $tabentry = $label.name + " " + $acttienc + " " + $actpgid + " " + $acttitle) #set ( $result = $lbltab.add($tabentry) ) #set ( $lblfound = $lblfound + 1 ) ## Wenn spezifisches Label angegeben und gefunden wurde #elseif ( $paramSLabel == $label.name ) ## Label, Page-Titel (URL-encoded=single-word) PageId und Page-Titel (Klartext) in lbltab stellen #set ( $tabentry = $label.name + " " + $acttienc + " " + $actpgid + " " + $acttitle) #set ( $result = $lbltab.add($tabentry) ) #set ( $lblfound = $lblfound + 1 ) ## Wenn spezifisches Label angegeben und nicht gefunden wurde: ignorieren #else #end #end #end ## Ausgabeprozessing nur, wenn auch Labels gefunden wurden #if ( $lblfound > 0 ) ## Sortieren des Array nach String Label-Name + Page-Titel $lbltab.sort(null) ## URL-Prefix fuer alle Hyperlinks, die PageID wird in der Schleife dazugegeben. #set ( $baseurl = "$settingsManager.getGlobalSettings().getBaseUrl()/pages/viewpage.action?pageId" ) ## Zaehler der bearbeiteten Labels #set ($lblctr = 0) ## Über alle gefundenen Label-Einträge #foreach($tpentry in $lbltab) ## Abtrennen des Labels #set ($tpstring = $tpentry) #set ($ColumnEnd = $tpstring.indexOf(" ")) #set ($sortlbl = $tpstring.substring(0, $ColumnEnd)) #set ($ColumnNext = $ColumnEnd + 1) #set ($tpstring = $tpstring.substring($ColumnNext)) ## Abtrennen des Titels (Url-Encoded, d.h. ohne Blanks !) #set ($ColumnEnd = $tpstring.indexOf(" ")) #set ($sorttienc = $tpstring.substring(0, $ColumnEnd)) #set ($ColumnNext = $ColumnEnd + 1) #set ($tpstring = $tpstring.substring($ColumnNext)) ## Abtrennen der Pageid #set ($ColumnEnd = $tpstring.indexOf(" ")) #set ($sortpgid = $tpstring.substring(0, $ColumnEnd)) #set ($ColumnNext = $ColumnEnd + 1) #set ($tpstring = $tpstring.substring($ColumnNext)) ## Rest ist Titel im Anzeigeformat (mit Blanks) #set ($sorttitle = $tpstring) ## Neues Label (Gruppenwechsel) ? #if ($sortlbl != $oldlbl) #set ($oldlbl = $sortlbl) ## Nur ab dem zweiten Label: HTML für vorheriges Label abschliessen #if ($lblctr > 0) </p> #end ## Für alle Labels: HTML Anfangsteil mit Label-Name <hr><p><span class="aui-label">$sortlbl</span><br> #set ($lblctr = $lblctr + 1) #set ($colctr = 0) #end ## Confluence Link-Adresse aus Seitenname <a href="$baseurl=$sortpgid">$sorttitle</a>   ## Link-Adressen über drei Spalten verteilen #set ($colctr = $colctr + 1) #if ($colctr > 3) #set ($colctr = 0) <br> #end #end ## Für letztes Label: HTML für vorheriges Label abschliessen #if ($lblctr > 0) </p><br> <hr> #end ## Keine Labels gefunden #else <p>Keine Labels im Seitenbaum gefunden</p> #end
I have the exact same need to filter the list of labels to those attached to sub pages instead of just a whole space.
Mayank Raja
added a comment - We have a lot of how to pages. We assign labels like robot, or bcr or some similar. So now if we have a parent page of all HowTo where we can list all the labels used, people can quickly get all HowTo that are for robot or for bcr as an example. Super helpful.
Otherwise you have to create a content report for each label and everytime a new label is added a new report has to be created. No Good!
Mayank Raja
added a comment - We have a lot of how to pages. We assign labels like robot, or bcr or some similar. So now if we have a parent page of all HowTo where we can list all the labels used, people can quickly get all HowTo that are for robot or for bcr as an example. Super helpful.
Otherwise you have to create a content report for each label and everytime a new label is added a new report has to be created. No Good! What sense does it make to show labels for a whole space in a page at a deeper level ?
The current display of the macro is of value on the top page, but on deeper level pages, I want to see an index of my contents below this page, not above or aside
Just to provide context for the request. As a Knowledge base grows, text search of the entire KB becomes less useful as you get too many false positives compared to useful results. To get around this, you hierarchically divide the KB using pages, and allow search restricted to one branch of the KB. This provides less false positives. However, it still allows text search of everything if the user cannot determine which branch their request resides, or does not find what they were looking for in a particular branch.
Labels, being hand-crafted get less false positives in general, but as the KB grows, we hit the same limitations as text search. You get too many false positives unless you can restrict the labels to particular branches. Sadly, LabelsList does not allow this. You can emulate the idea of a branch by splitting the KB over multiple spaces, but this sacrifices the ability to see a index terms (or do search) over the entire KB, which is a necessary back-stop to context-sensitive label lists.
Honestly, given the importance of KB's to Confluence's mission, and given the importance of search to KB's in general, I find this omission surprising. I'd have thought Atlassian's staff of Information Scientists would have been up in arms 
. After all, I imagine that most Confluence KBs are the point where Discovery is the user's primary concern, not the Content. After all, there's a reason why most consider Google more vital to "the Internet" than the literally millions of people who supply content.
Anyway, this is the same suggestion as CONFSERVER-26195, which was closed 4 years ago as "not happening".
However, 4 years is 4 years. Perhaps this time! (This is my single biggest request as a KB management tool.)
A joker to restrict would be fine, for e.g.
labelprefix*
*labelpostfix