Technical Breakdown for links widget
This is the technical breakdown for Linked Resources (gitlab-org&3994)
Architecture
- We store the
ResourceLinks
in a separate table, the table will be very similar toRelatedIssues
andRelatedMergeRequests
. - We need a GraphQL API to fetch, add, and delete
ResourceLinks
.
Assumptions & Limitations
Permissions & Security
Frontend
TBA
Backend
We will add GraphQL API to add, delete, and fetch the resource links.
Database
We will add a new table with the columns mentioned below.
-
Table:
issuable_resource_links
-
Model:
IssuableResourceLinks
Column | Type | Required? | Description |
---|---|---|---|
id | int | primary key | Primary key of the record |
issue_id | reference | not null | Include the id to parent incident issue |
link_text | string | no | Optional text for the link |
link | string | yes | Actual link of the resource (slack, zoom, etc.) |
link_type | int | yes | Type of the link (zoom, slack, general, etc.) |
Validations & Constraints:
API
Sample Query
Sample Input
Conclusions from the following discussion on this issue:
- The old zoom meeting feature and new zoom resource links should not exist simultaneously. This is a 1:1 replacement which should be swapped with a feature flag.
- Non-incident issues will no longer support zoom links, which the intention of the original feature. This is not a deprecation, but we should still announce the feature change.
- We will not restrict zoom meetings to 1-per-incident. We will not implement
/remove_zoom
. - We do not currently require the
project_id
on theissuable_resource_links
table. - We will clean up the existing metrics for zoom links, and track usage of resource links fresh.
- We should opt for
Reporter+
to add/remove resource links. - We'll build the widget for slack & generic links behind a feature flag, then build & switch over zoom behind a separate feature flag. This ensures the switch-over is 1:1 for zoom links, and also allows us to ship smaller iterations which provide value.
- We'll keep to the
IncidentManagement
namespace and relocate the module only if/when it expands to other issue types. - We'll need to get approvals, following the process for adding third-party trademarks to GitLab.
Rollout
We can roll out the model and backend as and when it's completed. The feature is only useful once front end hooks the API.
Feature flag
We will put this entire feature behind a development feature flag so that we can have the flexibility to change it without undergoing a deprecation process.
Metrics
TBA
Documentation
TBA
Issue breakdown
We can create 3 issues at higher level.
Frontend UI can be developed in parallel with backend and model tasks.