Up until now, in order to register event type to the timeline, we
needed to list all of the event types in settings yaml.
This commit adds another option: specify event type to group/level
mapping using regular expressions, which should make mapping
definitions much shorter for providers with many different event types
that follow a certain pattern.
Changes were made in to areas: in database querying and in event to
category assignment.
When creating database condition for events, we now use three sources:
1. a set of event types that should be included in result,
2. a set of event types that should not be present in result and
3. a set of regular expressions that event types can match.
An event is part of the result if its type is in include set or
matches any of the regular expressions and is not part of the exclude
set. For example, take this fragment of settings file:
:ems:
:ems_dummy:
:event_handling:
:event_groups:
:addition:
:critical:
- !ruby/regexp /^dummy_add_.+$/
:update:
:critical:
- dummy_123_update
- !ruby/regexp /^dummy_.+_update$/i
:detail:
- dummy_abc_update
- dummy_def_update
- !ruby/regexp /^dummy_detail_.+_update$/
This translates into following three sources for :update category,
assuming user selected :critical level in UI:
* include_set: dummy_123_update
* exclude_set: dummy_abc_update, dummy_def_update
* regexes: ^dummy_.+_updates$
In this case, events of type dummy_abc_update will not be displayed,
since they match details and are thus put in exclude set. On the
other hand, if the user selected :critical and :detail levels, things
are a bit different:
* include_set: dummy_123_update, dummy_abc_update, dummy_def_update
* exclude_set:
* regexes: ^dummy_.+_updates$, ^dummy_detail_.+_update$
Regular expressions should be accepted by the PostreSQL DBMS and
should not contain Ruby-specific functionality. The only exception to
this rule is case sensitivity, which can make regular expressions a lot
simpler in certain situations.
Category assignment is done in two phases. First, we try to assign
category only looking at the full name of event. If this yields no
category, we try to assign one by matching against regular
expressions. If we continue with categories from example above, we
would get those mappings:
* dummy_123_update is mapped to :update. It also matches :addition
category, but since explicit names have higher priority, that
regular expression is not checked at all.
* dummy_nil_update is mapped to :update because it matches one of
the :critical expressions.
* dummy_add_event is mapped to :addition.
All this is done in order to give fully spelled-out event type
mappings higher priority than regular expression ones and to be
consistent with how EventStream classifies events into groups and
levels.