Update permissions to relate epics
Related to #381308 (closed)
What does this MR do and why?
As part of Group minimum role should be Guest for epic rel... (&9232 - closed) we need to update permissions to relate epics, to require a Guest role instead of Reporter.
This MR updates the policy used for relating epics and the corresponding specs.
Before | After |
---|---|
admin_related_epic_link |
admin_epic_link_relation |
Permission checks: have Reporter access and related_epics feature is available for the group |
Permission checks: have Guest access, can read the epic, and related_epics feature is available for the group |
Before | After |
---|---|
admin_epic |
admin_epic_relation |
Permission checks: have Reporter access |
Permission checks: have Guest access and can read the epic |
The main reason for using a new policy instead of changing the permissions of admin_related_epic_link
is to keep names consistent.
We have the existing admin_epic_link_relation
that also relies on the admin_epic_relation
policy, so we can group them as admin_*relation_type*_relation
.
Screenshots or screen recordings
How to set up and validate locally
Internal ednpoints (UI)
- Logged in as an admin user create 3 epics in a group, one of them confidential
- Create and impersonate a Guest in the group by visiting
http://gdk.test:3000/admin/users
- Visit one of epics and add link to non-confidential epic in linked epics component. This should display the epic are related and create a new system note.
- Add link for the confidential epic, this should return an error (see screen recording above)
- Delete the previously related epic by clicking the
X
button inline. The epic should be removed from the list and a new system note is created - Using the admin user change Guest role to Reporter and try to relate the confidential epic, it should succeed this time.
link to docs)
REST endpoints (- Using a guest user's access token test the following endpoints
export GITLAB_PAT=<guest_user_access_token>
export GROUP_ID=<group_id>
export SOURCE_EPIC_ID=<source_epic_id>
export TARGET_EPIC_ID=<target_epic_id>
# relate source and target epics
curl --request POST --header "PRIVATE-TOKEN: $GITLAB_PAT" "http://127.0.0.1:3000/api/v4/groups/$GROUP_ID/epics/$SOURCE_EPIC_ID/related_epics?target_group_id=$GROUP_ID&target_epic_iid=$TARGET_EPIC_ID"
# list source's related epics to obtain "related_epic_link_id"
curl --request GET --header "PRIVATE-TOKEN: $GITLAB_PAT" "http://127.0.0.1:3000/api/v4/groups/$GROUP_ID/epics/$SOURCE_EPIC_ID/related_epics"
# delete related epic link
curl --request DELETE --header "PRIVATE-TOKEN: $GITLAB_PAT" "http://127.0.0.1:3000/api/v4/groups/$GROUP_ID/epics/$SOURCE_EPIC_ID/related_epics/<related_epic_link_id>"
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Eugenia Grieff