Table of Contents


This page offers information useful for many apps. Here you can learn how to use filters and searches more efficiently.

Enhanced filtering

Some plugins allow personalization of content based on a user's profile information. This is useful for making your intranet more relevant to each single user, because there's less irrelevant clutter for their daily work, and important information is easily accessible. 

Oftentimes, a simple filtering argument is sufficient: If <field name> matches <value>, show <information>. The plugin administrations offer simple interfaces for entering those arguments.


Linchpin Launchpad offers the possibility to recommend apps to users who might need them most. The recommendations are based on user profile values.


Linchpin Enterprise News lets you create complex news sections, so that users can be shown only the most relevant news. This configuration is also based on user profile values.


In these examples we used a very simple statement: department = IT. For a lot of cases this is sufficient. But often enough you'll want to define a more complex personalization. 



Wildcards and logical operators

Wildcards and logical operators help to create even more complex filters based on user profile values.

In the past, you have already been able to assign menu items to specific profile field values. Now you can also use wildcards in addition to those values. You can also create more complex filters using logical operators (AND, OR, NOT).

For example: You could show a menu item to all users that have not selected English as their Confluence language ("NOT en*").

 


Wildcard / Operator
Description
Example
blankmatches any value matches everything
?matches a single characterC?O 
matches CEO and CTO , but not C3PO
*matches 0 or more charactersen* 
matches en , en_GB , en_US, but not de_DE or men
ORLogical 'or' operatoren_GB OR fr_FR 
matches en_GB and fr_FR , but not de_DE
ANDLogical 'and' operatoren* AND *GB 
matches all values that start with en and end with GB
NOTLogical 'not' operatoren* AND NOT en_US 
matches all values that start with en except en_US




Filter constraints

Due to "Wildcards and logical operators", it is not possible to use key words in filter attributes.

As a workaround, replace the key words with the same number of "?" signs. Or replace at least one letter of a word with a "?".

These keys are case sensitive, so "And" or "and" would not match.

 


Filter Attribute
Workaround
Keyword
New York (State)New York ?State?( )
HR AND QSHR AN? QSAND
NOT for everybodyNO? for everybodyNOT
This OR ThatThis O? ThatOR



Search and search operators

To make the most out of the search, we need to understand how it works.

Let's say you want to search for departments you created, let's call them "test-department-1" and "test-department-2".


If you search for "test-department-1", the search will divide this query into three items "test", "department" and "1".

This is due to tokenization and stemming. This logic is found in the Confluence search and our Linchpin macros utilize the Confluence search, so it applies to both.


It's possible that you won't find your departments because the search engine changed the query you entered/applied tokenization and stemming.


 

Here are some examples of this search:

  1. test* → The search will find anything that begins with "test" (test, testing, tested...) → Both departments will be found.
  2. test- → The search will apply stemming and make "test" out of the query. → Both departments will be found.
  3. test-* → The search will make two queries out of this search: "test" and "*" → Since "*" is a wildcard and can't be at the beginning of a search query, the search won't find anything.
  4. -test → The search will filter out everything that includes the word "test". The minus sign in front of a word means that the word following the sign should be left out. → No department will be found.
  5. department → The search will find anything that fits "department" exactly. → Both departments will be found.
  6. department- → The search will apply stemming and make "department" out of the query. → Both departments will be found.
  7. department-* → The search will make two queries out of this search: "department" and "*" → Since "*" is a wildcard and can't be at the beginning of a search query, the search won't find anything.
  8. department-1* → The search will make two queries out of this search: "department" and "1" → It should work, but it doesn't. It should find at least one department, but currently that's not the case. We are analyzing this issue.


Safety Guidelines

We strongly recommend the following Confluence configuration settings to avoid potential security risks:

Make sure people are not allowed to register their own accounts, especially without restriction to your domain.

If you allow anonymous access, make sure anonymous users don't have permission to create or edit anything anywhere (pages, blogposts, comments, attachments etc. in any space).
     
If you configure your instance differently, you do so at your own risk.





☁️ Looking for a Cloud-based Intranet?

Check out Mantra, your go-to alternative to Linchpin in the Atlassian Cloud!

Mantra is your a comprehensive solution for connecting teams, making collaboration a breeze, and keeping your company's internal communication strong and streamlined - all in the cloud.

Test the intranet for Confluence Cloud now for free: 


Discover Mantra


Link to this page: https://seibert.biz/wildcards 



This page was last edited on 11/15/2024.