mikeshardmind / salamander-v1

Apache License 2.0
6 stars 0 forks source link

[Mod] Advanced kick/bans/tempbans #37

Open mikeshardmind opened 3 years ago

mikeshardmind commented 3 years ago

I'm not sure how this is going to be implemented yet. I'll probably go about it in a way that adds an additional command rather than overloading an existing one to prevent accidental misuse.

One of the things that we're currently having asked for via other channels is a way to ban everyone that joined in a specific window of time, but I can think of a few other filter conditions that are appropriate to add to this and only kick/ban/tempban those that match all filters which are selected.

I'm putting this down for beta 6, not 5 at this time as beta 5 will be mostly identical to 4 with a few minor changes but will be a mandatory transition for those already testing for us before continuing to higher versions to cleanup oversights in the original DB schema.

LGACode commented 3 years ago

Requested ban options:

mikeshardmind commented 3 years ago

I think there may need to be more discussion on the goals of some of this.

In particular

  • Kick if not a member of another specified server

Does not neatly align with the other things here and might be better suited to being part of a separate "network membership management" module.

Soulrift commented 3 years ago

No pfp Having a specific pfp (useful for raids where the pfp is part of the raid or lazy avoidance of the previous)

I believe these would lend themselves better to a third party module... while both of these could likely be done via null or hash comparison, I could see them in a module utilizing something like pillow to do more robust pfp checking

Sync/pull bans between servers Kick if not a member of another specified server

I agree with ol' Mikey here that these would fit more neatly in a guild network management/etc module, whether core or 3rd party.

The other 3 are fairly simple userinfo level pulls... I could see these either core or 3rd party.. but adding minor functionality like this risks the project going down the same rabbit hole as Red, where core becomes inundated with features that are too situation-specific

mikeshardmind commented 3 years ago

In terms of a separate management tool for some of this, I think it makes more sense to add a way to tell the bot "these servers are related. This is the parent server."

Then be able to add rules like : Ban/kick/leave from parent results in Ban/kick/kick from rest (I'm sure we'll find other cases of rules like this that make sense for this situation too)

Marking them as sibling servers would make the rules added multi-directional.

This probably belongs in the contrib_extensions directory if we go this route, as it is something I would want to support, but with a level of separation on what we will eventually guarantee from the bot core.

mikeshardmind commented 3 years ago

This is partially implemented in a provisional state now. I'm not sure I'm happy with the user interface on it right now, open to changes/feedback