Issue Table Column Filter Syntax

The Dashboard Column Filters are a powerful means to cut down the list of findings to smaller subsets you can work with. We try to keep basic filtering tasks as intuitive as possible but some advanced filtering possibilities and behavior require some explanation which you will find on this page.

The examples below apply more or less in the same way for the issue tables in all our different frontends. Additionally, in the Web Application, those filters also apply when browsing project files in the so called Index Page.

Web Application Issue Table

Web Application Index Page

Visual Studio Plugin

Eclipse Plugin

JSON Api

Basic examples

In the most basic cases, you can simply start typing what you are looking for intuitively. The matching will be done case-insensitively, that is capitalization of letters is irrelevant.

Filter for an exact issue by entering its Id, e.g. DE11 or simply 11

Filter for Style Violations by entering the provider name, in this case axivion or just a substring, e.g. axi

Filter for files having more than 20 issues by entering >20

Filter for issues in header files with *.h

The file filter

There is a special filter for file names as this is probably the most frequently used filter. Some issue kinds, namely Architecture Violations, Clones and Cycles have two associated source locations. For those, the file name filter matches issues where at least one of the two file names matches the filter. In the JSON API the file filter can be specified using a special column named any path.

Filter for Architecture Violations in C files with *.c. Note, that it is sufficient, if either Architecture Source or Target match the file filter.

Filter header files only with *.h

Whole string matching

At times, the inexact substring matches are not precise enough to express what we want. If we want to force matching on the whole string we can do this using double quotes “”:

In the example, you can see, that the file config.h.in sneaks into our results because *.h is interpreted as a substring filter.

And here we solve this problem by using the quoted filter “*.h”

Negative matching / Exclusion filters

Sometimes, we want to exclude certain results from our result set. We can achieve this using the negation operator !. A typical usecase is to shrink the result list by excluding generated files, which of course requires, that they have something common in their file system path, e.g. they all reside in a source folder named “generated”. Then we could use a file filter like !/generated/*. See below for another usage example:

Suppose, you have a policy requiring developers to justify issues they cannot fix for a good reason using the justifications feature.

Then it will be a frequent use-case to filter for issues not having a justification yet using “”, i.e. two double quotes with nothing in between.

One might also want to check what kind of justifications the developers are writing using the same filter but negating it prepending an exclamation mark: !””

Logical combination of filters

Sometimes, what we need is a logical combination of different filters when we want to include or exclude based on several properties of the same column:

Suppose, you are using tags for annotating issue states and affected code components and false positives.

Then one might want to filter for issues in a certain component but exclude issues already marked as false positives. This can be achieved using the filter Component_Y & !False_Positive using & as logical and operator.

We can also take this one step further and make use of | (inclusive or) and use brackets to specify operator precedence: (Component_X | Component_Y) & !False_Positive. Of course we could achieve the same result using Component_* & !False_Positive or simply Comp & !False

Escaping rules

Some filter characters can only be used inside double quotes when we want them to be interpreted literally. They are:

\ " ? [ & | ( ) ! < > = ~ ^ % $ @

Note, that quoting a filter makes it match on the whole string, see here, so you might need to add not only the double quotes, but also a wildcard around your filter expression, for example “*operator_&*”

Inside quotes some characters need to be escaped by a preceding backslash if you want them to be interpreted with their literal meaning. Those are:

\ " ? * [