Need to implement auto-expiration for infractions. I.E. infractions that have expired (based on Duration but have not been marked as Rescinded should be rescinded automatically, with the bot itself as the "Rescinded By" user.

As per Rowboat

Things like decaying infractions, invite puring, spam detection, etc should log to a channel. Today that is #mod-log

As we're not keeping a history of migrations and everyone is recreating initial migrations, some people may rely on data to be inserted/modified as part of their migration; these would be deleted when merged and someone else rescaffolds the initial migration. This issue serves as a homebase for all "manually" added migration members.

Comments on this issue with a common layout may be a good way of conveying this. Format I suggest, short and simple:

Issue ref and small summary

Code that needs to be inserted

Need to rework/refactor the promotions feature to match the Repository/Service structure used by all the rest of the DB-related code.

Most notably, DBPromotionRepository needs to NOT create UserEntity record directly, as it can cause concurrency issues. UserRepository should be the only one messing with the Users table.

This proposal is to implement some kind of raid detection in MODiX, which can automatically issue an @Staff notification in #mod-log if it detects a potential raid.

The criteria for defining the start of a raid, and end of a raid, are obviously the most interesting part about this proposal. My initial thoughts are...

1. If a certain number of users have joined the server, within a certain timeframe. Say, 10 people in 30 seconds, for example.
2. Potentially, a lower threshold, for users that were created briefly before joining.
3. Once a notification has been issued, there would need to be a cooldown to prevent repeats during the raid. Say, "once an hour has passed with no new users joining".

It is possible to enter numerous votes/comments from the same user account to an individual Promotion Campaign via the Web Interface.

Suggestion:
Store user id against comments/votes and allow only one instance per user (amend existing on re-submission, as opposed to just dropping it).

Listing out the users' infractions in an embed instead of using an ASCII table. It will help with categorizing infractions by type.

A through usage document needs to be available for new users to understand how to manage moderation with this bot.

Insights on:

• Node memory usage
• Messages processed

tempmute
unmute

It should describe how to setup and run locally, as well as a better high-level description of features

use of moderation command should be logged to a channel, today that is #mod-log

• Infraction browsing / review
• Moderation log browsing
• Managing user claims
• Managing designated roles
• Managing designated channels
• Integrate new authz/authn systems

Comment with more as they are added.

Add ability to move a message from one channel to another.

Something like:
!move 12345 #foo because i wanted to

Would move a message with the ID of 12345, to the channel #foo, with a reason field stating "because i wanted to"

This should act as a baseline to add different kinds of moderational actions upon.

An infraction could be the baseclass for tempmutes, warnings, bans etc. It should contain stuff that can be searched through for an user, meaning there should be an unique identifier, it should be associated to a user(the bad guy) and a moderator(the good guy). A reason should be required.

The interface for searching throw them should be idiomatic and easy. Maybe we can do that using memorable shortcuts? This needs to be iterated upon

It has been a long standing issue that we are not entirely sure if people are actually accepting the offers posted in the mentoring channel. Adding functionality to facilitate mentor/mentoree offers and acceptances through Modix would give more insight into this.

An implementation may work as follows:

Users can post offers through the web interface. The mentoring channel is locked to all posters except the bot, so the bot will be responsible for posting the offer made in that channel. An emoji reaction is added to the post, where adding an additional reaction to it will count as an acceptance of the offer, and the offer posting is then edited to mark it as accepted. The original poster of the offer can then accept the acceptance, or decline it to reopen it.

Vote now for your preferred unit testing frameworks!

I'm partial to setups including NUnit + NSubstitute + Shouldly.

Yep, do that...pgsql

infractions expire over time. different infractions have different weights

MODiX currently has no spam prevention. As discovered in #83, although we purge invite links, there's nothing stopping a user from posting multiple invites and letting MODiX itself spam the channel with replies to the user (as well as the #debug-log).

We need some sort of cooldown or functionality like Rowboat. Rowboat checks the amount of links sent by the user in X timespan, and automutes. Would be good to port that feature,

infractions search
infractions remove

When I log in, the source of the image being used for my avatar is https://cdn.discordapp.com/avatars/96642168176807936/acf8818538bfce80a29793085e46de9c.

@Inzanit has promised a WinForms UI - this issue is to capture this feature.

I wanted to explore the possibility of porting RoboDanny's tag command.

Is there any particular functionality that we need from tags that we don't currently have?

Does the tag ownership model work fine as it is? Tags seem to be owned by individuals, so they're only editable by their creators or staff (?), but we collectively use them in moderation and assisting. Would it make sense to have a pool of server tags and do away with ownership completely?

An option might be to enable the creation of multiple tag pools that are collectively controlled by a particular role. For example, tags popular in the beginner-questions channel, like yellowbook and devessentials might belong to the help pool, which can be added to and edited by Associates and higher. There might also be a tag pool called modtools with read access restricted to Operators and higher, and so on.

I've heared we use an "aka" url service, which sounds like it may do some of this already, but I'm gonna post this anyway.

This proposal would be to have invites to the server handled EXCLUSIVELY through MODiX.

What MODiX could do is support an HTTP endpoint like "mod.gg/[servername]/join" which simply returns a 302 with an actual invite link. This would have the following benefits:

1. MODiX could either generate a new invite link, per request, or reuse an invite link for only a short period of time, before expiring it.
2. MODiX could enforce rate-limiting on people joining the server. Say, only once every 5 seconds.
3. MODiX could easily implement a "!raidmode" command that prevents people from joining the server, until the raid has ended.

Downsides include:

1. No one would be able to join the server during MODiX downtime.

See title.

Pretty sure this is coming from Discord.NET, not a bug in our code.

ban
temp ban
unban

At some point after release, we should refactor some stuff for consistent naming and organization. Such as the following:

1. Interfaces either always being in separate files, or always in the same file as the implementation (for single-implementations).
2. Use of the Async suffix (or not) for methods returning Task/Task<T>.
3. Use of [Required], [DatabaseGenerated], etc. where not explicitly needed, in favor of being self-documenting of intention (or not).

Feel free to add more.

Currently issuing !infraction delete <id> will delete the reaction without any feedback to the issuer of the command. We should provide some sort of visual feedback, perhaps in the form of a reaction, to indicate that the command was successful.

With a bunch of people working on MODiX, we're starting to see some divergence in code conventions. It might be a good idea to chuck some Rosyln analyzers in and make warnings get treated as errors. This will allow us to decide on and enforce one standard code style that we all use for this project.

As a voting regular, after commenting on a nomination I should see which comments are my own somehow so I know who I already commented or voted on.

warn
remove warning

I know this has been brought up before, but it came up again today in the aftermath of RaidVite. And datadata, at least, expressed that he previously thought the suggestion was to require people to formally apply to join the server, and get approval.

The actual suggestion is just to limit new users in the guild to only seeing the #rules channel, until they are granted a "User" role by MODiX, which is triggered by one of the following:

1. After 60 seconds (or whatever) have passed
2. When the user enters an "!accept" command, or similar, to confirm their acceptance of the rules.

This would have the following benefts:

1. Allow MODiX to have a "!raidmode" command that simply stops it from handing out the "User" role until Staff decides the raid has cooled off.
2. Actually maybe force some users to read the rules, before posting.
3. Help prevent bots coming in and scraping data. Apparently, the Discord API "Get Users within a Guild" query might not limit based on what channels the caller can see?

I myself support this idea quite a lot. Kameko originally brought it up today, and everyone in channel seemed to like it.

add
remove

note is an administrative thing