- In the final round of review (!5081), we moved the protected branch
access levels from Rails enums to constants from Gitlab::Access.
- The migrations that moved us from the old data model (a single
protected_branches table with developers_can_push and
developers_can_merge flags) to the new one (separate tables for
push_access_levels and merge_access_levels) was not updated.
- These migrations still used 0 to mean "Masters" and 1 to mean
"Developers" (matching the previous Rails enum), while Gitlab::Access
uses 40 and 30 for these, respectively.
- Once the migrations run, our data gets into a broken state.
- We fix this by migrating all `0`s to `40` and all `1`s to `30`.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/20606#note_13561628
= Caveats =
- In Gitlab::Access, 0 represents NO_ACCESS. When we run this migration,
all protected branches with "No one" as an access level will be
changed to "Masters"
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`
2. Use `can?(user, ...)` instead of `user.can?(...)`
3. Add `DOWNTIME` notes to all migrations added in !5081.
4. Add an explicit `down` method for migrations removing the
`developers_can_push` and `developers_can_merge` columns, ensuring that
the columns created (on rollback) have the appropriate defaults.
5. Remove duplicate CHANGELOG entries.
6. Blank lines after guard clauses.
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
`max_member_access`, which is a lot nicer.
2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
in migrations that don't need this module. Also remove comments where
not necessary.
3. Remove duplicate entry in CHANGELOG.
4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
5. Split the `set_access_levels!` method in two - one each for `merge` and
`push` access levels.
1. Remove the `developers_can_push` and `developers_can_merge` boolean
columns.
2. Add two new tables, `protected_branches_push_access`, and
`protected_branches_merge_access`. Each row of these 'access' tables is
linked to a protected branch, and uses a `access_level` column to
figure out settings for the protected branch.
3. The `access_level` column is intended to be used with rails' `enum`,
with `:masters` at index 0 and `:developers` at index 1.
4. Doing it this way has a few advantages:
- Cleaner path to planned EE features where a protected branch is
accessible only by certain users or groups.
- Rails' `enum` doesn't allow a declaration like this due to the
duplicates. This approach doesn't have this problem.
enum can_be_pushed_by: [:masters, :developers]
enum can_be_merged_by: [:masters, :developers]
Jan Provaznik