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.
Time in seconds since the last notification sent from 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 notification sent from each
channel and query window separately, so a recent PM from Joe will not affect a
notification sent from channel #foo.
Config option client_count_less_than (uint) determines if notifications
will be sent based on how many IRC clients are connected to ZNC. A
value of zero disables this condition (always met), otherwise only sends
notifications if the number of connected clients is less than the
configured threshold.
Personal use case is client_count_less_than = 2, in that I always have
Irssi connected from my server, but if also connected from my phone, I
don't want duplicate notifications.
In order to better abstract and handle the difference between messages
and actions, notify_pm() is changed to only determine whether a private
message or action should send a notification to the user, and leave
sending the notification to the calling method. This allows PM's and
PA's to have different notification text formats, while still
centralizing the logic to decide when to send them.
TODO: Make notify_pm() actually use logic instead of blindly saying yes.
Rather than re-encoding the auth string for every message, factored it into a
separate method that only gets called when the username or password is changed,
or the plugin is loaded/reloaded.
John Reese