Backend: Support unfurling private and confidential links

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Work on this issue
• Close this issue

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:
  1. there is an active integration linked to the group/project, and
  2. the integration is associated with the Slack workspace of the request, and
  3. 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.