Update EpicsFinder to filter out confidential epics
When user can set particular epics as confidential, we should make sure that access to these confidential epics is properly checked in our EpicsFinder which should be used everywhere for listing group epics when #213078 (closed) is done.
Updating EpicsFinder to filter confidential epics might be the most challenging part of enabling confidential epics. We can inspire how confidentiality filtering is done in IssuesFinder, but the problem is that for groups we don't keep any pre-generated group_authorization which would keep minimum access level for each user for each project. An option how to deal with lack of group_authorization
table might be:
- after getting groups user can read epics we would prepare sub-list of these groups containing only groups where user is a member and his role is reporter or higher (my hope is that because the list of these groups is usually fairly small, also this filtering should be also acceptable)
- then the query to filter out confidential epics might be something like (not tested, pseudo code):
Epic.where(group: <original_list_of_groups>).where(epics.confidential IS NOT TRUE or (epics.confidential = TRUE and
(epic.author_id = :user_id OR EXISTS (select 1 from <list of groups user is at least reporter member> where group_id=epics.group_id))
This confidential check in EpicsFinder should be done only if confidential_epics
flag is enabled.
Update
related to this discussion, even when the feature flag is disabled, it will be better to respect the confidentiality of an epic and not expose these to not-member users. So we may consider something like this to keep confidential epics not-visible to unauthorized users even if the flag is off:
if flag is on:
use a new, potentially risky, query
elsif user is member of the group
use existing query which lists all epics
else
use existing query but filter out confidential epics
end
Or if not possible we would have to just treat them as public as planned originally.
Related to #197339 (closed)