Possible Admin / Violation Functionality

[rawrguard]

Aloha you beautiful beasts.

What is the possibility of adding the following functionality to any of our key bots to assist with our toxicity levels.

Should we need to restrict a user for a violation then the idea for the user-journey :

1. User commits violation.
2. Admin pings bot with a command = !violation @lionguard "Harassment of User X" 3.1 - Bot restricts user ( thus putting them in #appeals ) 3.2 - Bot adds +1 to a violation increment on that user in a database. This tally's. 3.3 - Bot adds that entire violation command '@lionguard "Harassment of User X" - submitted by @spazer" to #violations
3. Admin deals with user in #appeals
4. When a users incremented amount hits 3, we get pinged and can issue a 1 week restriction.
5. When a users incremented amount hits 6, we ban from server.

Bonus Win ( Ill even paypal cash for this ) :

1. If the violations can be stored in the database and called upon if need be.

!violation-list @lionguard 1 - @lionguard "Harassment of User X" - submitted by @spazer - on 14/09/2017 2 - @lionguard "Touching Tooks No-No-Place" - submitted by @spazer - on 20/09/2017 3 - @lionguard "Harassment of User X" - submitted by @spazer - on 35/09/2017

I have no idea to what degree this is possible but thats why this exists. :D

I think with this in place, we can actually deal with the toxicity a bit better. Nothing is set in stone, so lets talk about how if it is possible. Ill discuss the ethos behind this in the other repository.

[chrislennon]

@rawrguard nice write-up and request. Allow me to filter it into the technical tasks required. Whilst not a lot of work (probably about 1/2 hours) I cant complete it instantly as I no longer have access to the organisation's API repositories etc - I'll mark this separately.

DiscoBot:

• [ ] Creation of !violation command to submit a PUT/POST request towards API-Gateway endpoint (similar to the stats and information gathered in leave/join events)
• [ ] Addition/Reuse of the code that currently handles the restriction of a user to push them towards #appeals Assumptions/Questions:
  • first mention of a tagged user will be the offending user?
  • Will we need to have scope for multiple offenders in the same violation (if so we need to be careful we don't tag 'victims' or design it so they are distinct)?
• [ ] Creation of !violation-list command to submit GET request towards API-Gateway endpoint Assumptions/Questions:
  • Should this respond all results for tagged user?
  • n last results?
  • without a tagged user should it respond with all/n violations for all users or just fail?

Backend processing (I got no access here, at least officially via the repos):

• [ ] Creation of a lambda function to process the violation(s) towards RDS (the database)
• [ ] Creation of a lambda function that reads the records from the database.

Database Schema/Creation:

• [ ] Creation of a violations table, schema should probably consist of:
  • id - int
  • userid - int - discord userid
  • reason - string
  • valid - boolean - potential reversal of violations, but still recording historic reference
  • submitterid - int - discord userid
  • created_at - timestamp - NOW() on creation
  • last_updated - timestamp - NOW() on update
• [ ] [If required] a field added to a view regarding users to see number of violations, similar to number of leaves/joins