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 |
|---|---|---|
| blank | matches any value | matches everything |
| ? | matches a single character | C?O matches CEO and CTO , but not C3PO |
| * | matches 0 or more characters | en* matches en , en_GB , en_US, but not de_DE or men |
| OR | Logical 'or' operator | en_GB OR fr_FR matches en_GB and fr_FR , but not de_DE |
| AND | Logical 'and' operator | en* AND *GB matches all values that start with en and end with GB |
| NOT | Logical 'not' operator | en* 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 QS | HR AN? QS | AND |
| NOT for everybody | NO? for everybody | NOT |
| This OR That | This O? That | OR |
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:
test*→ The search will find anything that begins with "test" (test, testing, tested...) → Both departments will be found.test-→ The search will apply stemming and make "test" out of the query. → Both departments will be found.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.- -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.
department→ The search will find anything that fits "department" exactly. → Both departments will be found.department-→ The search will apply stemming and make "department" out of the query. → Both departments will be found.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.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.