Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Validation for active infractions #278
This pull request needs to be manually merged after #269 has been merged to avoid conflicting migration files.
This pull request adds validation rules to the API to validate infractions based on the
In addition, this pull requests adds a data migration to make sure the database itself is consistent with the new validation rules. Since this is a fairly complex data migration, I have added tests to make sure the migration works as expected. (Read more about that below.)
Finally, I've introduced a database-level
To test the effect of the migration file, I've created a subclass of
Since a migration is really snapshot in time of the migration history, this also allows us to work with the database models as they were at those two time points in the migration history (directly before and directly after applying this migration), since otherwise these tests will fail in the future if we decide to change the models.
#273 This commit adds validation rules to the Infraction serializer that validate if a given infraction should be accepted based on its status of being considered `active`. If the validation fails, the API will reject the request and return a 400 status. Specifically, this validator checks that: - infractions that can never be active do not have `active=True` set; - a user can never receive a second active infraction of the same type. Tests have been added to `test_infractions.py` to ensure that the validators work as expected. This commit implements the first part of #273
#273 This commit adds a data migration to migrate active infractions that should not be active to inactive. There are two types of infractions that this migration will migrate to inactive: - Infractions of types that should never be active (e.g. notes) - Secondary active infractions if a given user already has an active infraction of the same type. Since this makes the migration file fairly complex, I have written tests to make sure the migration works as expected. In order to do this, I've subclassed `django.test.TestCase` to create a `MigrationsTestCase` that takes care of reverting the database back to a state prior to the migrations we want to test and injects test data before applying the migrations we want to test. For more information, see `pydis_site.apps.api.tests.migrations.base` This implements the last part of and closes #273
MarkKoz left a comment