mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-03-25 16:03:03 -04:00
2d4a3e5658
Project columns and cards use a sorting field for ordering, but nothing prevents duplicate values from being inserted. This causes unpredictable ordering and makes swap-based reordering unsafe. Additionally, the same issue can be added to a project multiple times, which shouldn't be possible. This PR adds a migration to clean up existing data and enforce three unique constraints: - (project_id, sorting) on project_board — one sorting value per column per project - (project_id, issue_id) on project_issue — one card per issue per project - (project_board_id, sorting) on project_issue — one sorting value per card per column The migration deduplicates existing rows and reassigns sequential sorting values before adding the constraints. Changes - Migration: fix duplicate sorting values in project_board and project_issue, remove duplicate (project_id, issue_id) rows, add three unique constraints - MoveColumnsOnProject: two-phase swap (negate then set) to avoid constraint collisions - MoveIssuesOnProjectColumn: three-phase approach with duplicate validation and sorted lock ordering - UpdateColumn: always persist sorting field (allows setting to 0) - GetDefaultColumn: query max sorting before auto-creating - createDefaultColumnsForProject: explicit sequential sorting - changeProjectStatus: only set ClosedDateUnix when closing ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [x] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. *The decision if the pull request will be shown in the release notes is up to the mergers / release team.* The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11334 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> Co-authored-by: Myers Carpenter <myers@maski.org> Co-committed-by: Myers Carpenter <myers@maski.org> |
||
|---|---|---|
| .. | ||
| column.go | ||
| column_test.go | ||
| issue.go | ||
| issue_test.go | ||
| main_test.go | ||
| project.go | ||
| project_test.go | ||
| template.go | ||