Fedora Notifications - howto?

[Michael Schwendt]

On Thu, 20 Aug 2015 10:10:29 -0600, Kevin Fenzi wrote:

> > If I log in, which is very slow and takes some time, I see two
> > "filters" with lots of rules. I'd like to understand these defaults.
> 
> Right, you should see "irc" and "email" on the first screen. 
> 
> These are the rules for each type of notification (if you want
> notifications via irc message or email or both). 
> 
> If you click on one of them it goes to the modify page for that type of
> notification. 
> 
> For each fedmsg that is emitted from anything in fedora infrastructure,
> it looks at your series of rules. If any of them match, you will get an
> email about that fedmsg. 

I watch the "email" screen.

I've clicked the "Reset" (factory defaults) button to restart with
something that likely is more sane than what I've found so far.

At the bottom is a section "The following messages would have matched
this filter". It now shows a lot more _expected_ notifications than before,
such as the pkgdb notifications I have missed. This is a much better basis
to begin with. I've found several green "include" rules that didn't make
sense to me.

So:

At the left, there are two filters. They have been given the names
"Events on packages that I own" and "Events referring to my username".

I think those names for the filters add to my confusion (because the
watchcommit ACL covers packages I do _not_ own). I can rename the
filters. So far so good.

Each filter consists of a list of multiple rules. Rules can be "added"
and "deleted" again. An added rule can be toggled between "Include"
(a green checkmark) and "Ignore" (a red exclamation mark).

At the top of the filter I can read:

  | (all these rules must be satisfied for the notification to be sent)

This is misleading. Actually, only all the green "include" rules must
match (= be satisfied) for a notification to survive the filter. Any
red "ignore" rule that causes a match, immediately deletes the
notification from further processing => nothing sent to you.

The second default rule in the filter deletes notifications triggered
by my own activity. An attempt at reducing mail flood. Negating the
rule includes _only_ notifications triggered by myself. It ignores
anything else, such as activity from other packagers I want to
observe via "watchcommit" ACL. Negating it is highly dangerous as it
drops too much. Deleting that rule would be the way to go. Or adding
a new filter for some specific "include" rules, and the same applies
to all the other default "ignore" rules in the default filters. Their
goal is to filter out lots of notifications.

That's why by default there is the second filter that explicitly only
includes notifications triggered by my FAS username.