This question is in reference to Atlassian Documentation: Labels List Macro
Is there a way to use a wildcard to filter out multiple labels at once?
I'm working on documenting any user issue in 1 space for both external & internal apps. I'm looking to use this macro to show the labels for just external tags. I've created naming conventions for labels and want to filter out the ones for internal app issues.
For example, I'd want to filter out the labels 'internal-app1-feature1' & 'internal-app2-feature2' by entering 'internal-*' where * is the wildcard.
There aren't wildcards in macro. We have a similar need, and indeed, I continue to add to the exclude list as necessary.
Your best bet might be to have two spaces, one for internal and one for external projects. Then you specify the Space from which to list the labels.
Thanks! That's what I'm thinking we'll need to do, but I wanted to avoid 'a separate Space for everything' situation. My organization is just starting to use Confluence and I don't want to be "that guy" that makes it bloated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Having been a Confluence admin for 5+ years, I would go with separate spaces. With that approach, you can control permissions and visibility. Trying to manage labels on 1000+ pages will not be fun. And adding a space does not create bloat, just an easy way to organize information.
The other reason for breaking up content into spaces is to avoid page name collisions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The more I think about it, the more this seems to be the right answer. This functionality would still be useful as I could centralize info and work to one Space for the topic (User Issue) and hopefully avoid going to the wrong space for the info.
But, to your point of managing lots of pages in the future, it does make sense to split in this case between Internal User Issues & External User Issues.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This is not an answer to your question, but wouldn't the problem go away if you would define two sets of labels?
One set of labels for the features and one for tagging them as "internal" or "external". Maybe you could go so far to label apps also separate from the features. With this is would be easy to filter on internal and external features.
Would this interfere with other of your requirements? One drawback would be that you cannot simply click on a label and have all related documents listed. Users need to specify more than one link to list the tagged pages.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's what I'm trying to do, but I'm not understanding how to scope the Labels List Macro to just one set.
For example my excluded labels list looks like this:
kb-how-to-article,kb-troubleshooting-article,kb-resource,admin-not-reviewed,admin-resource,admin-not-reviewed-support-app
And I'll have to keep adding to the list whenever a new label is created in the set(s) I want to exclude (in this example any label prepended with "kb" or "admin").
Does that help explain more fully?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, I did not make my point clear.
What I was trying to say is, why don't you label your pages with "kb", "how-to-article", "admin", "not-reviewed" instead of the compound labels (e.g. "kb-how-to-article")?
Then selecting on those "atomic" labels in the macro may be easier.
The only drawback I can think of is the one I mentioned in my answer. But you may have other requirements that lead to your naming convention ...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That makes sense. The drawback you mentioned does apply in this case as the issues being documented will have varied relationships between app & feature, and keeping those as open as possible will provide an easier way for my team to explore and find the info. (That is if their query in the search macro and the content don't match)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.