Todo: Fixed length tempmute command for TQS members

[Erisa]

TQS context: https://discord.com/channels/150662382874525696/787398986091855893/1077040136556134480

Mod context: https://discord.com/channels/150662382874525696/780516096335282206/1077056494509498460

For permission handling, probably best to put TQS as a tier underneath Trial Mod and use that system.

Ideally:

• Length of mute cannot be changed
• All usage sends an alert to #investigations
• Only works in #tech-support or threads where the parent channel is #tech-support or #tech-support-forum
• Will act like a normal mute, but:
  • cannot be applied if the user is already muted
  • has different wording (something about muted pending action from the mod team, similar to dotsimus)
  • is expected to be followed up with a warning from a moderator
• In the ephemeral response for its usage, we should tell the TQS member to make a modmail thread as well

[FloatingMilkshake]

It looks like the command(s) for this should be restricted to #tech-support & threads, AND the mute should only apply to those channels, correct? This would mean a new 'muted in tech support' role should be applied and timeouts cannot be used since those are server-wide

Any preference on mute length?

[Erisa]

It looks like the command(s) for this should be restricted to #tech-support & threads

Correct but make sure the parent channel of those threads is the tech support forum.

AND the mute should only apply to those channels, correct?

This hasn't been decided yet. I suspect this would cause overspill of spam into other channels and potentially make things worse for the mods who have to clean that up afterwards. But maybe we can trial it and see? It might not be as scary as it seems.

Any preference on mute length?

No preference. An hour or two perhaps.

[FloatingMilkshake]

This hasn't been decided yet. I suspect this would cause overspill of spam into other channels and potentially make things worse for the mods who have to clean that up afterwards.

This is what I was thinking too when this idea was initially suggested. From the discussion I saw afterwards though, it looked like the general idea was a mute limited to #tech-support/etc. I like the idea of trying out a limited-scope mute first.

I can probably take a shot at this some time today.

[Erisa]

Sure, thanks! Assigned to you for now and set to Planned

[FloatingMilkshake]

Ideally: ...

• Will act like a normal mute, but:
  • cannot be applied if the user is already muted

@erisa Do you have a preference as to how I do this check? The Muted role is in config.json, so I can check the member's roles for mutedRole—but this means that if a member is TQS-muted, they can be TQS-muted again, which will reset the timer back to whatever the TQS mute length is. Alternatively, if I check the db for a mute entry, it will disallow a TQS-mute if the member is already muted (mutedRole) OR TQS-muted.

[Erisa]

Source of truth for whether someone is muted should be this:

https://github.com/Erisa/Cliptok/blob/fa31ca565a565f4d1905a04330da6010381a3595/Commands/Mutes.cs#L26

So they have a db entry OR they have a muted role. That needs to be "or" to account for users who aren't currently in the server but still are muted. Desyncs between the muted role and the db only happen if someone assigns the role manually and the existing checks don't pick it up.

So you need to

• When TQS muting, first ensure they are not muted by checking the role(s) AND checking the db for mutes and TQS mutes (however you end up storing those). If there is an existing mute of any kind then don't bother. TQS mutes should expire before they can be reapplied, to discourage issuing them indefinitely.
• When full muting, ensure that you can still mute if the current mute is just a TQS mute (in which case it will clobber it as mod mutes take priority).