Currently enforces either "notifo" or "boxcar", but does not yet change
any behaviors in the rest of the module. Also prevents appending or
prepending to the option value.
Issue #226
Follow-up to ref 60632d42f. Initial implementation would lose loaded
options when the module was reloaded, and would cause errors if the
loaded dictionary did not contain all of the option values.
In preparation for renaming the project and supparting multiple
notification services, there needs to be a simple method for migrating
user options to the new module name. Using the built-in dictionary
read/write mechanism, migrating to a new module name would be as simple
as issuing `/msg *notifo save foo` and `/msg *notify load foo`.
When faced with sub-expressions, the parser was not correctly advancing
its iterator to the sub-expression's matching end parenthesis, causing
it to evaluate inner conditions twice, and incorrectly terminate early
when it reached the first end parenthesis.
Added preprocessor flag NOTIFO_DEBUG to generate debug output to
PutModule() to validate the expression parsing logic.
This option allows customization of the boolean logic used to
determine how conditional values are used to filter notifications for
channel messages. It evaluates as a full boolean logic expression,
including the use of sub-expressions. The default value of "all" will
bypass this evaluation and simply require all conditions to be true.
The expression consists of space-separated tokens in the following grammar:
* expression = expression operator expression | "(" expression ")" | value
* operator = "and" | "or"
* value = "true" | "false" | condition
* condition = <any condition option>
Also implemented EVAL command for testing purposes.
For any channel/PM where the user hasn't yet sent a message, the replied
condition would always return false due to failing a `0 < 0`
expression. The fix special-cases last_notification_time values of 0 to
always return true.
If set to "yes", notifications will only be sent if you have replied to the
channel or query window more recently than the last time a notification was
sent for that context.
To maintain compatibility with ZNC < 0.090 (such as 0.078 used by
Ubuntu), we need to conditionally disable the away_only condition when
compiled against versions that don't support CUser->IsIRCAway().
Time in seconds since the last activity by the user on any channel or query
window, including joins, parts, messages, and actions. Notifications will
only be sent if the elapsed time is greater than this value. A value of
0 (zero) will disable this condition.
Time in seconds since the last message sent by the user on that channel or
query window. Notifications will only be sent if the elapsed time is greater
than this value. A value of 0 (zero) will disable this condition.
Note that this condition keeps track of the last message sent to each channel
and query window separately, so a recent PM to Joe will not affect a
notification sent from channel #foo.
Space-separated list of nicks. Applies to both channel mentions and
query windows. Notifications will only be sent for messages from nicks
that are not present in this list, using a case-insensitive comparison.
Note that wildcard patterns can be used to match multiple nicks with
a single blacklist entry. For example, `set nick_blacklist *bot` will
not send notifications from nicks like "channelbot", "FooBot", or
"Robot". Care must be used to not accidentally blacklist legitimate
nicks with wildcards.
In preparation for nick_blacklist, which needs to allow input of a
space-separated list of nicks to ignore, the SET command shouldn't be
requirement an exact number of tokens. Any tokens past the first three
should be included in the option's new value, such that a command like
"set nick_blacklist nick1 nick2 nick3" will be accepted.
Daniel Wallace
John Reese
Travis La Marr
Ed Kellett
Steven Moazami
John Reese