First, a bit of background.
When I first started working on the server, a role existed called "Not
Arisian".
There was nothing notable about it, but having seen a very similarly named
role with a specific purpose at a previous event, I took it to mean a sort
of "penalty box" role which could be used to specifically *disallow* normal
interaction.
It wasn't set up that way as I found it and nobody could really say what
it was intended for, but in various discussions about incident response, I
assumed we might need something like that for limited but judicious use
when necessary.
But a spat over who should have authority and equivalent of "arrest power" was still raging on in the management stratosphere. Some seemed semi-horrified by the idea of muting someone, saying that attachment of a "penalty" or "mute" role would be too obvious and demeaning, or something. I didn't understand that -- if someone is misbehaving badly enough for Safety or IRT to be called to intervene, and restraint is deemed necessary, why not muzzle the offender as needed and never mind if evidence of that is visible or not? They earned it, at least temporarily. The point is not to protect the offender somehow, the point is to handle the incident and hopefully de-escalate the whole situation and release the offender back to normal status with no further problem. Either way, as part of making things ready for a large influx of people I either co-opted "not Arisian" or made a new "penalty box" role, I forget which, and added channel permissions such that having the role would simply prohibit the sending of messages in most of the spaces. Those affected would still be able to *view* ongoing traffic, they just wouldn't be able to reply [or continue spewing bad stuff]. It was harmless to have such a means on tap, even if never used. I also described a more "invisible" way to handle a single channel or category thereof, by adding a negative posting permission for a single user -- doable, but far klunkier especially if having to search down a long user list. Anyway, in a normal Discord setup, some entities would ultimately need to wield the "manage roles" capability to effect usage of this. That is a fairly broad power, and misuse can really screw things up. Having better insight into what could be done with bot commands, I began thinking about how this power could be channeled, such that its *only* capabilty would be a streamlined "mute function", and nobody would have to romp around in the Discord administrative panel or even have "manage roles" capability to work with it. [*Note: this is not the same as the "mute user" built-in Discord function, which only applies to audio channels. This discusses the equivalent for text channels, for which there is no built-in.] |
Still lacking useful decisions from above, I laid all this aside for the time being. Meanwhile, the Safety and IRT crews were being trained to simply grind through the UI -- if they would ultimately even be allowed to do this. Notwithstanding, we wanted to do a functional test of the process, so I offered up my "crash test" dummy and pretended to say offensive things in a channel. Vivian played the part of incident response deciding that they'd had enough of my crap, and began the procedure. At this point, the role in question had been named "On Hold". Not really subtle at all... |
The real command enhancement was a full audit of WHO had put WHO ELSE into the hold role or taken them out, because the native server log would only show that YAGPDB did something. So this is both bots chiming in; Dyno happening to notice the changes, and Yag actually dropping its results in the audit channel INSTEAD of the channel where the command was used. And now it even got the full basename#discriminator username syntax right for *both* involved parties. | |
For the record, the production "put on hold" bot-code is nothing more than
{{$aa := parseArgs 1 "too many args" (carg "userid" "it")}} and the "un-mute" complement invokes "takeRoleName" instead with a different result message. Full disclosure, it took quite a bit of doc reading and experimental thrashing to noodle out the right syntax for all this; it's really rather arbitrary. The base "language" is a variant of Go templates. |
While human-side receptivity was a little disappointing, it was a great
exercise in mastering one type of bot custom commands.
So all worthwhile, and gives me something to write up as a kind of
tutorial for anyone interested in doing more along these lines.
There's a lot more to it than this, of course, and this is only YAGPDB.
The minor limitations of the "on hold" role were still bugging me, though, and I found a couple of references on permissions precedence to try and work through what could be done differently. First of all, the users/members of a server don't have permissions. They are given roles that carry some set of base permissions, such as "Arisian" being allowed to see and send and react as a baseline. But then specific channel or group/category permissions can override those, in specific deny or allow fashion. The problem is that channel "allow" permissions take precedence over denies; thus, if an "Arisian" is generically blocked from a channel but their "Staff" role permits seeing and sending to staff areas, guess what. "On Hold" now has no effect either, because that's just another deny role that got overridden. People have complained about this, with one person neatly summing up the problem in this support thread by saying "try and manage a firewall with 'allow all' as it last rule, and let us know how that goes." Flipping the precedence of allow and deny would certainly allow more restrictive postures, but a global change to how that's supposed to work would instantly break just about every server out there. If Discord was ever going to implement such a thing, there would have to be a very careful migration strategy -- perhaps servers could have a new control to select the order, but default to the original way until an admin was good and ready to try flipping it. |