<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=40916776&issueIid=6849) </details> ## Bug Report ### Summary When `allowed_to_push`, `allowed_to_merge`, or `allowed_to_unprotect` contains both an `access_level` entry **and** a `user_id` (or `group_id`) entry where the user's role matches that access level, applying the resource produces a provider error: ``` Error: Provider produced inconsistent result after apply When applying changes to gitlab_branch_protection.branch_protection, provider "..." produced an unexpected new value: .allowed_to_push: planned set element cty.ObjectVal(map[string]cty.Value{"access_level":cty.StringVal("maintainer"), "access_level_description":cty.UnknownVal(cty.String), ...}) does not correlate with any element in actual. ``` The same configuration applies successfully on provider version 18.x. ### Root Cause The bug was introduced in commit `a4f31bf1` ("Add access_level attribute to allowed_to_* properties"). The functions `populateBranchPermissionOptionsData` and `populateBranchPermissionOptionsDataForPush` use an OR condition to decide whether a planned entry already exists in the current API state: ```go if allowedTo.AccessLevel == types.StringValue(api.AccessLevelValueToName[currentAllowedTo.AccessLevel]) || !allowedTo.UserId.IsNull() && allowedTo.UserId.ValueInt64() == int64(currentAllowedTo.UserID) || !allowedTo.GroupId.IsNull() && allowedTo.GroupId.ValueInt64() == int64(currentAllowedTo.GroupID) { requireCreation = false } ``` The GitLab API returns **separate** entries for access-level rules and user/group rules. However, user/group entries also carry an `AccessLevel` field reflecting the user's role. When the planned `access_level` value (e.g. `"maintainer"`) matches the `AccessLevel` field of a user entry (e.g. a Maintainer user), the first OR branch fires, `requireCreation` is set to `false`, and the access-level entry is **never sent to the API**. After the update, the API returns the access-level entry as a new element that was not in the plan, causing the inconsistency error. The same logical flaw exists in the "detect entities to be removed" loops in `generateAllowedToStateToAccessLevels` and `generateAllowedToPushStateToAccessLevels`. ### Fix The access-level match must be guarded so it only matches against pure access-level entries (i.e. entries where `UserID == 0 && GroupID == 0`, and for push also `DeployKeyID == 0`): ```go accessLevelMatch := !allowedTo.AccessLevel.IsNull() && !allowedTo.AccessLevel.IsUnknown() && allowedTo.AccessLevel.ValueString() == api.AccessLevelValueToName[currentAllowedTo.AccessLevel] && currentAllowedTo.UserID == 0 && currentAllowedTo.GroupID == 0 userMatch := !allowedTo.UserId.IsNull() && allowedTo.UserId.ValueInt64() == int64(currentAllowedTo.UserID) groupMatch := !allowedTo.GroupId.IsNull() && allowedTo.GroupId.ValueInt64() == int64(currentAllowedTo.GroupID) if accessLevelMatch || userMatch || groupMatch { requireCreation = false } ``` ### Reproduction Steps 1. Create a branch protection with both an `access_level` entry and a `user_id` entry where the user's role matches the access level, e.g.: ```hcl resource "gitlab_branch_protection" "example" { project = "my-project" branch = "my-branch" allowed_to_push { access_level = "maintainer" } allowed_to_push { user_id = 1234 # a user who is a Maintainer on the project } } ``` 2. Run `terraform apply` — first apply succeeds. 3. Make any change that triggers an update (e.g. change another attribute). 4. Run `terraform apply` again — the provider error occurs. ### Affected Attributes - `allowed_to_push` - `allowed_to_merge` - `allowed_to_unprotect` ### Environment - **GitLab Terraform Provider Version:** 19.x (regression introduced in the commit that added `access_level` as a configurable attribute to `allowed_to_*` blocks) - **Previously working version:** 18.x ## Implementation plan *Added by [GitLab Duo Agent Platform 🤖](https://gitlab.com/components/agents-and-flows/quick-win-labeller)* 1. **Locate the affected functions** in the `gitlab_branch_protection` resource implementation: - `populateBranchPermissionOptionsData` - `populateBranchPermissionOptionsDataForPush` - `generateAllowedToStateToAccessLevels` - `generateAllowedToPushStateToAccessLevels` 2. **Apply the fix** described in the Root Cause section: replace the existing OR condition with the guarded `accessLevelMatch` logic that only matches pure access-level entries (where `UserID == 0 && GroupID == 0`, and additionally `DeployKeyID == 0` for push). Use the corrected Go code snippet provided in the **Fix** section above. 3. **Apply the same fix** to the "detect entities to be removed" loops in `generateAllowedToStateToAccessLevels` and `generateAllowedToPushStateToAccessLevels`. 4. **Add a regression test** using the reproduction steps: configure a `gitlab_branch_protection` resource with both an `access_level` entry and a `user_id` entry at the same level, apply twice, and assert no inconsistency error occurs. 5. **Verify** that the fix does not break existing tests for `allowed_to_push`, `allowed_to_merge`, and `allowed_to_unprotect` with access-level-only or user/group-only configurations.