Expose member_role_id in ProtectedRefAccess REST API entity
## Context
| | |
|---|---|
| **Phase** | 3 of 6 |
| **Parallel with** | https://gitlab.com/gitlab-org/gitlab/-/work_items/594880+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594882+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594883+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594884+ |
| **Blocked by** | https://gitlab.com/gitlab-org/gitlab/-/work_items/594877+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594878+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594879+ |
| **Unblocks** | https://gitlab.com/gitlab-org/gitlab/-/work_items/594885+ <br> https://gitlab.com/gitlab-org/gitlab/-/work_items/594886+ |
## Summary
Expose `member_role_id` and the custom role name in the `ProtectedRefAccess` API entity so that API consumers can read back which custom role is configured on a protected branch access level.
## Background
The API entity `API::Entities::ProtectedRefAccess` (in `lib/api/entities/protected_ref_access.rb`) is prepended by `EE::API::Entities::ProtectedRefAccess` (in `ee/lib/ee/api/entities/protected_ref_access.rb`). The EE version currently exposes `user_id` and `group_id`. `member_role_id` and optionally the role name need to be added here.
## Relevant files
- `lib/api/entities/protected_ref_access.rb` — CE base entity
- `ee/lib/ee/api/entities/protected_ref_access.rb` — EE extension (add here)
## Changes required
### `ee/lib/ee/api/entities/protected_ref_access.rb`
```ruby
module EE
module API
module Entities
module ProtectedRefAccess
extend ActiveSupport::Concern
prepended do
expose :user_id, documentation: { type: 'Integer', example: 1 }
expose :group_id, documentation: { type: 'Integer', example: 1 }
expose :member_role_id, documentation: { type: 'Integer', example: 42 }
expose :member_role_name,
documentation: { type: 'String', example: 'Lead Developer' },
if: ->(access, _opts) { access.respond_to?(:member_role) && access.member_role } do |access|
access.member_role&.name
end
end
end
end
end
end
```
## API response example
```json
{
"id": 1,
"access_level": 30,
"access_level_description": "Lead Developer",
"member_role_id": 42,
"member_role_name": "Lead Developer",
"user_id": null,
"group_id": null
}
```
Note: `access_level_description` comes from `humanize` on the model, which (after Issue 3) will dispatch to `humanize_member_role` returning the custom role name. `member_role_name` is an additional explicit field for clarity.
## Testing
- Entity spec: verify `member_role_id` and `member_role_name` are exposed when set
- Entity spec: verify `member_role_id` is `null` and `member_role_name` is absent when not set
- Request spec: `GET /projects/:id/protected_branches/:name` returns `member_role_id` in access level objects
## Dependencies
- Issue 3 (EE concern — `belongs_to :member_role` and `humanize_member_role`)
- Issue 6 (API params — so the fields can be round-tripped)
## Labels
issue