* refactor: Remove all existing migrations
* refactor: Create clean set of migrations
* chore: Skip check_statetype_slugs when DB is not yet populated
* fix: Do not cache active_groups_menu on module import
* fix: Do not patch timezone awareness out of oidc-provider
* refactor: Migrate to create postgres schema, only use pgloader for data
* ci: Use migration scripts from feat/pg-migrations branch
* Revert "ci: Use migration scripts from feat/pg-migrations branch"
This reverts commit c82f64c614241ccede4865a50d494725c8a47c15.
* ci: Run check before migrate
* fix: Remove redundant migration caused by merge error
* chore: Add casts/ALTER TABLEs to eliminate pgloader errors/warnings
* chore: Change schema name to match docker image assumptions
* chore: Clear out schema so we get a clean start in case of a retry
primary keys from character strings to integers, and makes corresponding code
changes.
This was prompted by database limitations discovered when trying to make
DocAlias use a m2m document field; with 255 long strings as primary keys for
Document and DocAlias this violated the MySQL database limitations.
Changing the primary keys to integers should also improve efficiency.
Due to the data migrations which create the new integer primary keys and adds
corresponding integer foreign keys matching the previous string foreign keys
in all tables having foreign keys to Document and DocAlias, some of these
migrations take a long time. The total set of migrations are expected to have
a runtime on the order of 2 hours.
- Legacy-Id: 16237
tables from legacy to new through Django (with minimal cleaning to
have the import go through) and removing migrations from submit and
liaisons as they interfere with the clean slate of the new database,
adjusting IPR model to add null=True on fields with nulls in the
database
- Legacy-Id: 3778
* Assign a title to liaisons that have no title (Copy the title of the first attachment of set a default title)
* Copy old "From" information to from_raw_body field
See #383
- Legacy-Id: 2542
Users in that group can send outgoing liaisons from any ietf entity.
Users in that group can send incoming liaisons from any sdo.
Fixes#356
- Legacy-Id: 2467
If an user can approve pending liaisons he/she have access to:
- List of pending liaisons he/she can approve
- Detailed view of a pending liaison with an approval button
Fixes#357
- Legacy-Id: 2466
