After the next release: drop Members.Role, make Boards.Key required #219

New issue

Closed

opened 2026-09-22 21:17:56 +00:00 by Grandiras · 0 comments

Grandiras commented

2026-09-22 21:17:56 +00:00

Owner

Part of #190's migration rule: the previous release can still run against the database for one release. Two columns are kept in a transitional shape for exactly that reason, and both can be finished once a release carrying #190's work has shipped. Not before: the release before it has to stay a valid rollback target.

Drop Members.Role (#192). Nothing reads it except DatabaseInitializer.WarnAboutUnconfiguredAdminsAsync, the one-off log line naming members the old Members page had promoted, who are no longer admins of anything but the boards they were given. Remove that method with the column, and the "deliberately gone from the entity" note in Data/Entities/Member.cs and DbAllowlistService.
Make Boards.Key NOT NULL (#197, AddBoardKeys). It's nullable so v2.6.0, which inserts boards without a key, can still run. DatabaseInitializer.EnsureBoardKeysAsync backfills on every boot, so by then every row has one. It can stay as a guard or go, whichever the migration makes simpler.

Both are one migration, and docs/data.md / docs/auth.md lose the sentences that explain the transition. Test against a copy of a database that went through the release in between, not a fresh one: a fresh database never had a null key.

Part of #190's migration rule: *the previous release can still run against the database for one release.* Two columns are kept in a transitional shape for exactly that reason, and both can be finished **once a release carrying #190's work has shipped**. Not before: the release before it has to stay a valid rollback target. - **Drop `Members.Role`** (#192). Nothing reads it except `DatabaseInitializer.WarnAboutUnconfiguredAdminsAsync`, the one-off log line naming members the old Members page had promoted, who are no longer admins of anything but the boards they were given. Remove that method with the column, and the "deliberately gone from the entity" note in `Data/Entities/Member.cs` and `DbAllowlistService`. - **Make `Boards.Key` `NOT NULL`** (#197, `AddBoardKeys`). It's nullable so v2.6.0, which inserts boards without a key, can still run. `DatabaseInitializer.EnsureBoardKeysAsync` backfills on every boot, so by then every row has one. It can stay as a guard or go, whichever the migration makes simpler. Both are one migration, and `docs/data.md` / `docs/auth.md` lose the sentences that explain the transition. Test against a copy of a database that went through the release in between, not a fresh one: a fresh database never had a null key.

Grandiras referenced this issue

2026-09-22 21:19:18 +00:00

Member-owned boards and a home page: decisions and order of work #190

Grandiras referenced this issue

2026-09-22 21:19:18 +00:00

Member-owned boards and a home page: decisions and order of work #190

Grandiras referenced this issue from a commit

2026-09-29 01:33:34 +00:00

Drop Members.Role and make Boards.Key required

Grandiras referenced this issue from a pull request that will close it,

2026-09-29 01:33:35 +00:00

Drop Members.Role and make Boards.Key required #234