Backend: Support unfurling private and confidential links
This issue is to unfurl private and confidential links and builds on the work to unfurl (public only) links in Slack #358677 and render them nicely #358679 (closed).
High-level flow
graph LR
A[In Slack, a user<br>posts GitLab link] --> Z[GitLab receives<br>event]
Z --> D{Is link to<br>a private/confidential<br>object?}
D -->|No| E[Unfurl link]
D -->|Yes| K{Does the integration setting allow<br>unfurling private/confidential links?}
K -->|Yes| E
K -->|No| G[Do nothing]
Proposal
- Add a setting to the
Integrations::GitlabSlackApplication
integration as per the designs #339906. - For private/confidential things, only unfurl if all of these are true:
- there is an active integration linked to the group/project, and
- the integration is associated with the Slack workspace of the request, and
- the integration has the option to unfurl private/confidential things checked
- For private/confidential things, the Block Kit response (see #358679 (closed)) should have an additional lock item. See the design UX #339906 (designs).
See also
- Design UX issue #339906
- For history and context, see this discussion thread #339906 (comment 895310637).
Availability & Testing
Suggestion: consider adding new request specs that assert intended responses from the GitLab project given a a Slack request to unfurl against private/confidential/internal project.
Note: We should also consider testing against projects that reside in internal and private groups.
Edited by Luke Duncalfe