[go: up one dir, main page]
Skip to content

Design: Embedding content in Issues

We should add a primitive to GitLab Issues, the concept of embedding or "unfurling" content. This would be useful for a few cases:

This would provide more interactivity and information than simply pasting in a link. For example with Zoom we could utilize the API to:

  • Display whether the call is active or not
  • How many participants, potentially who they were
  • A link to the recording and transcript, if one was made
  • ... and more

Proposal

For this issue we should come up with the design pattern for how these embeds should work. I imagine this should include:

  • Guidelines for how detection should work (URL detection, quick actions, etc.)
  • How should they look? (Size, visual cues, etc.)
  • What types of interaction should we allow? (Buttons? Hovers? etc.)

Detection

Content should be able to be detected in 3 ways:

  • File extension / MIME type for uploads
  • Quick-action command, like /zoom <meeting id>
  • URL detection, like https://gitlab.zoom.com/<meeting id>

Styling

  • Do we need to have a standardized border/display so that it is easy to discern that this is embedded content?
  • Should we standardize on a single size, multiple sizes, or allow the embedded content to determine the size?

Interaction

Ideally we would allow full interaction, but I imagine that can get complicated with how the code makes calls back to GitLab.

I would propose that we at least support general hover-over capabilities, for content like a metrics chart for example.

Security

We need to be very mindful of security of these plugins, as it is possible it could be abused by some users to access data they should not have access to. For example Errors can sometimes contain sensitive information, and access to their details should be controlled.

Commenting

It would be interesting if the embeds could eventually also log comments to the issue. This would be helpful for additional context and auditing. For example Pagerduty could add a comment and @ mention the on-call.

This should probably not be in the MVC, though.

Proposal

Initially we could have a simple set of minimum permissions, namely requiring Developer access or above to view and embed content.

Based on demand, we could allow a minimum permission per embeddable type:

  • Minimum permission required to embed content
  • Minimum permission required to view embedded content

Implementation

While this is most important for Issues, the underlying support for embedding should be present in all issueable types: MR's, Epics, Issues, etc.

Edited by Aaron K. White