This introduces channel-specificity to IRCUser.Class user classes.
The way it's worked so far is that admins, whitelists and blacklists were program-wide. As such, they applied to all channels, and there was no fine-granularity to be had.
With this, the users.json file is split into three top-level categories; operator, whitelist and blacklist. Each category in turn houses associative arrays of channels, which are arrays of users. Administrators remain program-wide and are set in the main configuration file (admins under [IRCBot]).
The Persistence service will, based on these, apply user classes directly onto IRCEvent.{sender,target} based on the channel it relates to (string IRCEvent.channel) at the postprocessing stage. Events that don't have a channel attached to them (such as private message queries) have their sender assigned a neutral IRCUser.Class.anyone, unless they are an administrator.
There is one small but difficult to tackle bug wherein the first event from a user that evokes a WHOIS chain does get properly played back, but is missing its defined class, instead being IRCUser.Class.anyone. This is because even though the WHOIS results return with the user's account name, allowing the Persistence plugin to divine its class, there is no channel attached to it, and there is no way to get Persistence to communicate that to the plugin whose function is being triggered. Postprocessing happens way earlier, and there is no way for plugins to re-request postprocessing.
By observing JOINs that carry login information (which can be the case on freenode, for instance), the bot will naturally work around this given time. Otherwise the first command issued (by a non-admin) is swallowed. We may need to issue WHOIS calls on channel participants.
This introduces channel-specificity to
IRCUser.Class
user classes.The way it's worked so far is that admins, whitelists and blacklists were program-wide. As such, they applied to all channels, and there was no fine-granularity to be had.
With this, the
users.json
file is split into three top-level categories;operator
,whitelist
andblacklist
. Each category in turn houses associative arrays of channels, which are arrays of users. Administrators remain program-wide and are set in the main configuration file (admins
under[IRCBot]
).Example
users.json
:The Persistence service will, based on these, apply user classes directly onto
IRCEvent.{sender,target}
based on the channel it relates to (stringIRCEvent.channel
) at the postprocessing stage. Events that don't have a channel attached to them (such as private message queries) have their sender assigned a neutralIRCUser.Class.anyone
, unless they are an administrator.There is one small but difficult to tackle bug wherein the first event from a user that evokes a WHOIS chain does get properly played back, but is missing its defined class, instead being
IRCUser.Class.anyone
. This is because even though the WHOIS results return with the user's account name, allowing the Persistence plugin to divine its class, there is no channel attached to it, and there is no way to get Persistence to communicate that to the plugin whose function is being triggered. Postprocessing happens way earlier, and there is no way for plugins to re-request postprocessing.By observing JOINs that carry login information (which can be the case on freenode, for instance), the bot will naturally work around this given time. Otherwise the first command issued (by a non-admin) is swallowed. We may need to issue WHOIS calls on channel participants.
This will break existing
users.json
files.