Update epic relations permissions
What does this MR do and why?
Related to #397073
We use the admin_epic_relation policy for checking permission to link epics (related. blocking, parent, child).
At the moment this policy requires the user to have a guest role in the epics group regardless of the group's visibility. This is not matching the permission required to link an issue to an epic where guest role is only required when the group or project is private.
To fix this inconsistency this MR updates admin_epic_relation to be enabled when the user is authenticated and has permission to read_epic. The read_epic policy will dictate the ability to link the epics as follows:
| Visibility | Membership required |
|---|---|
| Public group | None |
| Private group | Guest |
| Public group + confidential epic | Reporter |
Note that checks apply for both epics so cases with different conditions might occur. Example:
- Group A [private] -> Epic A
- Group B [public] -> Epic B [confidential]
To add Epic B as a child of Epic A the user needs to be authenticated, have a reporter role in Group B and a guest role in Group A.
The number of changes in this MR is quite large but the majority are for fixing specs that break with the policy change so we can't split them.
In most cases, tests were using a non-member in a public group to test a user without permissions, but this no longer fails so we can use a private group instead.
How to set up and validate locally
- Create a public group with two epics
- Log in/impersonate a non-member and visit one of the epics
- Verify that the user can add/remove child epics and related epics
Screen_Recording_2023-05-08_at_13.23.17
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.