Backend: Process Slack chat unfurl events (public links only for issues + MRs)
This issue builds on the events API prepared in #358676 (closed) to process Slack link unfurl events &6389.
Limitations
To iterate on link unfurling, this issue stops short on a few aspects:
- Only links to public things will be unfurled. Links to private and confidential things will be done in #358683.
- Only Issues and Merge Request links will be unfurled (this is being clarified in #337481 (comment 907440946)).
Proposal
- Configure our development Slack app according to these steps.
- Build on the existing Slack events API endpoint to process the chat unfurl event on a queue.
- Identify the object from the URL (we may be able to use
Gitlab::ReferenceExtractor
to do this, see !105655 (merged) as an example of identifying objects from their URIs) - Only unfurl links to public things. Private and confidential things will be unfurled later in #358683.
- Post back to the Slack API
chat.unfurl
method usingSlack::API.post
.
An example of the Slack Block Kit code to make a merge request view is in this comment #337481[Unfurling_states_-_issues.png] (comment 730095948). See also the Design UX issue #337481.
Availability & Testing
Suggestion:
- add higher level unit or request specs that assert the correct response content is being sent to the slack hook for requests from slack. (issue and merge requests)
- Future state: write e2e tests against Slack app.
Considerations that may already be considered:
- Edge cases and empty states - Example: (20 assignees on an issue, or no assignees, long issue or MR titles)
- Consistency between Slack app / Slash commands
- For slash commands, consider how a self-hosted instance with relative urls will generate links.
Edited by Luke Duncalfe