Whenever a user does something, record this user as having been seen at the
current time.
This function will be called whenever an IRCEvent is
being processed of the IRCEvent.Types that we annotate
the function with.
The IRCEventHandler.chainable
annotations mean that the plugin will also process other functions in this
module with the same IRCEvent.Type annotations,
even if this one matched. The default is otherwise that it will end early
after one match and proceed to the next plugin, but this doesn't ring well
with catch-all functions like these. It's sensible to save
IRCEventHandler.chainable
only for the modules and functions that actually need it.
* Permissions.ignore will
let precisely anyone trigger it, without looking them up. It just doesn't care.
* Permissions.anyone will
let anyone trigger it, but only after having looked them up, allowing
for blacklisting people.
* Permissions.registered
will let anyone logged into a services account trigger it, provided they
are not blacklisted.
* Permissions.whitelist
will only allow users in the whitelist section of the users.json
resource file, provided they are also not blacklisted. Consider this to
correspond to "regulars" in the channel.
* Permissions.elevated
will also only allow users in the whitelist section of the users.json
resource file, provided they are also not blacklisted. Consider this to
correspond to VIPs in the channel.
* Permissions.operator
will only allow users in the operator section of the users.json
resource file. Consider this to correspond to "moderators" in the channel.
* Permissions.staff will
only allow users in the staff section of the users.json resource file.
Consider this to correspond to channel owners.
* Permissions.admin will
allow only you and your other superuser administrators, as defined in
the configuration file. This is a program-wide permission and will apply
to all channels. Consider it to correspond to bot system operators.
In the case of
Permissions.whitelist,
Permissions.elevated,
Permissions.operator,
Permissions.staff and
Permissions.admin it will
look you up and compare your *services account name* to those known good
before doing anything. In the case of
Permissions.registered,
merely being logged in is enough. In the case of
Permissions.anyone, the
WHOIS results won't matter and it will just let it pass, but it will check
all the same so as to be able to apply the blacklist.
In the other cases, if you aren't logged into services or if your account
name isn't included in the lists, the function will not trigger.
This particular function doesn't care at all, so it is
Permissions.ignore.
Whenever a user does something, record this user as having been seen at the current time.
This function will be called whenever an IRCEvent is being processed of the IRCEvent.Types that we annotate the function with.
The IRCEventHandler.chainable annotations mean that the plugin will also process other functions in this module with the same IRCEvent.Type annotations, even if this one matched. The default is otherwise that it will end early after one match and proceed to the next plugin, but this doesn't ring well with catch-all functions like these. It's sensible to save IRCEventHandler.chainable
only for the modules and functions that actually need it.
The IRCEventHandler.requiredPermissions annotation dictates who is authorised to trigger the function. It has six policies, in increasing order of importance: Permissions.ignore, Permissions.anyone, Permissions.registered, Permissions.whitelist, Permissions.elevated, Permissions.operator, Permissions.staff and Permissions.admin.
* Permissions.ignore will let precisely anyone trigger it, without looking them up. It just doesn't care.
* Permissions.anyone will let anyone trigger it, but only after having looked them up, allowing for blacklisting people.
* Permissions.registered will let anyone logged into a services account trigger it, provided they are not blacklisted.
* Permissions.whitelist will only allow users in the whitelist section of the users.json resource file, provided they are also not blacklisted. Consider this to correspond to "regulars" in the channel.
* Permissions.elevated will also only allow users in the whitelist section of the users.json resource file, provided they are also not blacklisted. Consider this to correspond to VIPs in the channel.
* Permissions.operator will only allow users in the operator section of the users.json resource file. Consider this to correspond to "moderators" in the channel.
* Permissions.staff will only allow users in the staff section of the users.json resource file. Consider this to correspond to channel owners.
* Permissions.admin will allow only you and your other superuser administrators, as defined in the configuration file. This is a program-wide permission and will apply to all channels. Consider it to correspond to bot system operators.
In the case of Permissions.whitelist, Permissions.elevated, Permissions.operator, Permissions.staff and Permissions.admin it will look you up and compare your *services account name* to those known good before doing anything. In the case of Permissions.registered, merely being logged in is enough. In the case of Permissions.anyone, the WHOIS results won't matter and it will just let it pass, but it will check all the same so as to be able to apply the blacklist. In the other cases, if you aren't logged into services or if your account name isn't included in the lists, the function will not trigger.
This particular function doesn't care at all, so it is Permissions.ignore.
The ChannelPolicy here is the same omniscientChannelPolicy we defined earlier, versioned to have a different value based on the dub build configuration. By default, it's ChannelPolicy.home.