To help answer questions like "who's working helpdesk right now?" or "I need
a tech over here", we used a handful of roles which were set with the
"@mention" flag enabled.
That means that someone could be focused on any server channel and having
a conversation, and post a message with that special @role syntax to flag
any people currently on duty for that function to hop into the channel to
see what was up.
To facilitate self-service for said on-duty-ness, I constructed a role-menu
specifically for those "hailable" roles.
It wasn't so much a "clock" in the jobsite sense, although some of the
logging actually would show when roles were assigned and deassigned to
people; it was more like putting on a certain colored vest, which is what
made me think of the iconography at the top.
The overall idea certainly made sense to streamline getting help to people.
For a while I wasn't sure which roles we needed to put in this, and a bit of conversation ensued around an initial set. The first layout before actually menuing it was just to show the design crew where I was headed with the idea, and obviously it would change before being put into service. |
I went back to the "tall" arrangement and let the text flow itself more or less naturally, and that turned out to be okay. On mobile, people are used to scrolling to see everything anyhow. |
This is more of the sausage-making that has to happen in the channel where
the menu is, and then one has to go back and manually delete all that
stuff.
The long number is the target message ID, obtainable from the target message
meatball menu
when you have "Developer Mode" set for yourself.
The sync-up process is a little klunky, and gets even worse when you
go to change any of the role icons or try to move stuff around.
Due to highly varying external demands on which roles should be in the "clock" or not and thus duty-switchable, I had to re-edit this whole thing at least three times. |
Then there was the battle over what power any group would hold to deal
with other users, be they nickname changes or kicking out or whatever.
This went back and forth a bunch, and I kept pointing out that if any
working status was to receive additional powers, it should NOT be switched
through here since then any other staffer could attain those powers
by simply clicking a role on the Clock.
Such things needed to be externally managed, and a decision made about
who was going to handle that.
Note carefully, though: with suitable buy-in from all players, it would be possible to construct custom menus to bestow elevated power temporarily to *certain* users, or design a few bot-functions to channel and utilize parts of elevated privilege in a much more controlled way. [See the "muting" rathole, in fact.] In other words, with some effort you could write "sudo" in robot-ese. Because of the complexity of Discord's role/permission model, let alone when bots get involved, the transitive paths that can inadvertently get set up when you're messing with this stuff can be subtle and escape notice. Just like any other security problem. |
This is what the final role-command group configuration looked like at the YAGPDB end. The YAGPDB doc on role-menus lays out how to set this up fairly well, although it's a little sketchy on how the "edit" function is supposed to work. That's one reason reworking a menu is a pain in the ass unless all you're doing is *adding* to it. |