FilterList model and endpoints

[lemonsaurus]

This pull request introduces a new model, FilterList, and the prerequisite viewset, URL endpoint, migrations, serializer and tests.

The intention of this model is to store things that we will either whitelist or blacklist. For example, we'll be storing file formats, guild invite IDs, and other things that are currently in the bot config file, but that we want to be able to modify during runtime.

Eventually, we may set up automation where this table is synchronized against stuff like the Awesome Discord Programming List.

Review style: commit-by-commit.

Closes #305.

Routes

GET /bot/filter-lists

Returns all filterlist items in the database.

Response format

[
    {
        'id': "2309268224",
        'created_at': "01-01-2020 ...",
        'updated_at': "01-01-2020 ...",
        'type': "file_format",
        'allowed': 'true',
        'content': ".jpeg",
        'comment': "Popular image format.",
    },
    ...
]

Status codes

• 200: returned on success
• 401: returned if unauthenticated

GET /bot/filter-lists/<id:int>

Returns a specific FilterList item from the database.

Response format

{
    'id': "2309268224",
    'created_at': "01-01-2020 ...",
    'updated_at': "01-01-2020 ...",
    'type': "file_format",
    'allowed': 'true',
    'content': ".jpeg",
    'comment': "Popular image format.",
}

Status codes

• 200: returned on success
• 404: returned if the id was not found.

GET /bot/filter-lists/get-types

Returns a list of valid list types that can be used in POST requests.

Response format

[
    ["GUILD_INVITE","Guild Invite"],
    ["FILE_FORMAT","File Format"],
    ["DOMAIN_NAME","Domain Name"],
    ["FILTER_TOKEN","Filter Token"]
]

Status codes

• 200: returned on success

POST /bot/filter-lists

Adds a single FilterList item to the database.

Request body

{
   'type': str,
   'allowed': bool,
   'content': str,
   'comment': Optional[str],
}

Status codes

• 201: returned on success
• 400: if one of the given fields is invalid

DELETE /bot/filter-lists/<id:int>

Deletes the FilterList item with the given id.

Status codes

• 204: returned on success
• 404: if a tag with the given id does not exist

[MarkKoz]

An allowed field doesn't make sense to me because it facilitates the simultaneous maintenance of both a blacklist and whitelist for the same type. This means every possible value would have to exist in the database as explicitly allowed or denied, which is of course infeasible.

It makes more sense to enforce all records of a certain type to all be whitelist or all be a blacklist. Each type should have a default state (i.e. allowed or denied), and if an item of that type is present in the DB, then assume the opposite state. It can be up to the client to decide what that default state is. If you really need to have it in the DB, then it should be stored in a separate table as a mapping between type and allowed/denied rather than stored as a field for individual items in the list.

[lemonsaurus]

@MarkKoz

An allowed field doesn't make sense to me because it facilitates the simultaneous maintenance of both a blacklist and whitelist for the same type.

Some types need both a blacklist and a whitelist, for example the Guild Invite IDs. Here the idea is that some guild invites will be blacklisted and will never be permitted, some will be whitelisted and will always be permitted, and everything else will be permitted based on certain criteria (whether they are Partnered or Verified, in this case).

The UniqueConstraint makes it impossible for a blacklist and a whitelist for the same item to simultaneously exist, so every item is always exclusively on one of the two lists.

All requested changes fulfilled

[SebastiaanZ]

Alright, that's quite a lot of commits and files, but it looks solid. I've also ran some manual tests locally by polling the endpoints; looks good. One requested change to prevent us from using a wrong default value somewhere.

changes addressed

[SebastiaanZ]

Nice work. Adding in the rework/fix/kaizen of the social account tests made it a slightly less focused PR, but I doubt fixing that would have otherwise been a major priority. Better to get it done.

[lemonsaurus]

Now that we're gonna merge this pretty soon, I'll write a migration to get all the data ready.

[SebastiaanZ]

Is this now ready for merge?

[MarkKoz]

Best to wait until the bot PR is ready too, in case a review there requires changes here.