Filter confidential epics
What does this MR do?
Updates EpicsFinder to consider epic's confidential attribute when listing accessible epics in the group and subgroups.
Related to #213075 (closed)
DB queries:
query which checks user's max member access in the group (this is an existing query, we just re-use it in epics finder now): https://explain.depesz.com/s/9PAs
SELECT
"members".*
FROM
"members"
LEFT OUTER JOIN "users" ON "members"."user_id" = "users"."id"
WHERE
"members"."type" = 'GroupMember'
AND "members"."source_type" = 'Namespace'
AND "users"."state" = 'active'
AND "members"."requested_at" IS NULL
AND "members"."source_id" = 9970
AND "members"."user_id" = 1642716
ORDER BY
"members"."access_level" DESC
LIMIT 1
query which gets all visible epics in the group and its related groups (subgroups by default) if user is not member of the group. The list of group IDs is used (we preload groups as part of group permission checking so no subquery is used).
warning: this checks epics only in group id 9970, if I try with a synthetic list of 9970's subgroups then the query is pretty similar - https://explain.depesz.com/s/9eae) but I don't have access to this. There is a significant difference between cold cache: https://explain.depesz.com/s/EaRa and warm cache: https://explain.depesz.com/s/6zgj
SELECT
COUNT(*)
FROM
"epics"
WHERE
"epics"."group_id" IN (9970)
AND ("epics"."confidential" != TRUE
OR "epics"."confidential" = TRUE
AND "epics"."group_id" IN (
SELECT
"members"."source_id"
FROM
"members"
WHERE
"members"."type" = 'GroupMember'
AND "members"."source_type" = 'Namespace'
AND "members"."source_id" IN (9970)
AND "members"."user_id" = 1642716
AND (members.access_level > 10)))
AND "epics"."state_id" = 1
Related to #213075 (closed)
Screenshots
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Edited by Jan Provaznik