Spike: Establish backend tasks to support Epic dependencies

This issue is to scope out the engineering steps to deliver &2581 (closed). The expected outcome is a list of tasks that are estimated for capacity and will deliver a first iteration.

📅 Due Date: 2022-02-14

What we will build

  • An exact replica of the current related issue widget, allowing epics to be related to each other.
  • The ability to define the relationship as related, blocking or blocked-by.
  • See #202431 (closed).

Additional Requirements

  • As close as possible to the issues widget in design, as they will be merged into one when Epics become a Work Item type.
  • Just as with issues, epics from different groups and hierarchies can be related by those who can interact with both. The user only sees what they have access to.

❓ Things to clarify

  • ✅ Tier for this feature
  • ✅ Solely REST in the first iteration or including GraphQL support (See slack thread (internal))
  • ✅ Internal vs Public API
  • ✅ Records storage - DB table name - columns needed - Model name.
    • Proposal to use related_epic_links name for table and Epic::RelatedEpicLink for model.
    • For columns we need 1-1 mapping of attributes/functionality with issue_links.
    • See See #351597 (comment 835799403) for details
  • ✅ Backend services needed
  • ✅ Permissions performance impact
    • We need to check permissions for every epic but should not be too costly given the limited amount of related epics
    • We would get unavoidable N+1 queries for SELECT "saml_providers"...
    • See #351597 (comment 835834914) for details

📋 Tasks

  1. Allow an epic to be marked as Related to, blocking or blocked by other Epics.
  1. Allow to view, create, and delete related epics
Edited by Eugenia Grieff