• Dylan Griffith's avatar
    Fix N+1 query in Epics search for guest in private group · 403a4630
    Dylan Griffith authored
    Prior to this change a guest in a private group would end up in the
    `groups_user_can_read_epics` branch of logic in
    `#permissioned_related_groups`. This loops through each subgroup one at
    a time checking permissions. Instead of unwinding that logic for now we
    are just going to add a logical short circuit for a common specific
    case.
    
    The `#permissioned_related_groups` only needs to check if the user has
    the ability to view all epics in all subgroups in a group. Previously we
    were using the `read_confidential_epic` permission to confirm that the
    user could access all epics in the subgroups as well. But this is not
    necessary because this class will already filter confidential epics
    later in `with_confidentiality_access_check` so really we just need to
    answer the question "Can a user view all epics in this group and all of
    it's subgroups". This seems deceptively like we could just check the
    `read_epic` permission but there is a weird edge case for public groups.
    A user can view epics in a public group even if they aren't a member but
    that public group can contain private subgroups and they won't be able
    to view those epics. So we can conclude that if a group is `private?` as
    well as the user having the ability to `read_epic` in that group then
    they will also be able to `read_epic` in all child groups as well.
    
    This MR also introduces a new explicit test for `guest` permissions with
    confidential issues. The reason being that we don't appear to have any
    such tests about guest users already and it may give us more confidence
    that confidentiality filtering is working correctly prior to
    implementing this optimization.
    403a4630
327106-fix-epics-search-count-n-plus-1-queries.yml 115 Bytes