Fix upgrading oauth2_provider and accounts.Profile on Review Board 5.

Review Request #12281 — Created May 15, 2022 and submitted — Latest diff uploaded


Review Board


Our big move to Django 3.2 has been blocked largely due the
oauth2_provider app. In Review Board 4, we switched this from our
in-house evolutions to the official migrations, with the belief that
that would be the better upgrade path going forward.

Unfortunately, at some point, that project reset their baseline
migrations, meaning that it was no longer possible to upgrade the app
without just starting over on the schema or doing some manual
workarounds. This is not an option for us.

Work was explored on giving Django Evolution the ability to override
migrations, and then on undoing a MoveToMigrations mutation. In the
end, the best solution was just to give our own upgrade code a
pre-upgrade step of modifying the stored evolution and migration state,
undoing the MoveToMigrations ourselves, and then overriding the
evolutions used for this app.

This is now done in a new reviewboard.upgrade module, which has
pre-upgrade and post-upgrade steps that can be applied by both and rb-site upgrade.

The pre-upgrade step deletes the migration and evolution history for
oauth2_provider and modifies the stored signature. That then allows
our custom evolutions to apply on top of it. If this is a completely new
install, none of this kicks in, but Django Evolution will proceed with
the standard evolution process for creating the models for the app,
marking those evolutions as applied and setting us up for future
evolutions to this app down the road.

There's also a fix for the Profile model, which lacked evolutions for
one of the changes made for 5.0.

Tested upgrading from 3.0 and from 4.0 to 5.0 on SQLite.

Tested a brand new install of 5.0 on SQLite.

Tests are still pending for earlier versions of Review Board (which
are failing, but are unrelated to this, and likely regressions in
Django Evolution) and for MySQL and Postgres databases.