Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Slack integration. #1505
This adds Slack integration via their incoming webhooks API, which we're allowed to use on our TTS Slack. Right now it just notifies its default channel when a price list has been submitted:
Clicking on the words "price list" will take the user to the "unreviewed price list change" admin page.
We are intentionally not exposing too many details about the price list in the Slack message because we don't want to accidentally include PII or anything else like that.
This PR also adds a
The "CALC" link takes the user to the homepage of the CALC deployment.
The name of the slackbot is set to the default
Ok, I talked to Alex Bisker about this yesterday and she said she'd get back to me today--she doesn't think it should be a big deal though, particularly since we're still in the ATO process so it shouldn't be hard to add to the SSP if absolutely necessary.
Btw, the signals thing is actually a Django thing, not a Python thing (Flask has a very similar architecture though, as do lots of other libraries).
Ok, I've further loosened our mypy config because if we don't, there are some compelling use cases we're missing out on.
In the case of this PR, for instance, I wanted to make sure all call sites of
However, adding type annotations to all the call sites would alert us to this problem: try changing the call signature of
This kind of annotation is only easy, however, if we change mypy's defaults to be more lax about modules that don't have type annotations. Otherwise we start having to make type stubs for all kinds of stuff in django and other third-party libraries and it just becomes a lot more work than it's worth.
@jseppi even if we don't get the ATO mod for this in the very near future, do you mind if we merge it but just leave it disabled in prod? It seemed like Aidan and all the other folks I talked to didn't think of it as an actual security concern, so it seems like we should be able to get the paperwork resolved eventually, and it'd be nice to not have to keep this PR in-sync with
Code looks great! I have a few questions about how the Slack integration works, but I'll read up on that if you don't want to fill me in.
I assume the "feature-flagging" to not have this enabled until we are ATO-cleared is to just leave
signals seem sweet! We should use those for the email sending behavior post-
SubmittedPriceList-review and post-bulk-upload-processing
Actually can you confirm that providing
username in the webhook API call actually works? The docs are giving me pause that it would:
Keep in mind that incoming webhooks packaged as Slack apps cannot override the default channel, username, or icon associated with the webhook.
Hmm, that says "packaged as Slack apps" though--I'm not sure if ours will be packaged as Slack apps? I think that requires us to actually create a Slack app, whereas the way 18f's hooks work is by just telling the admins the incoming webhook name and then they add it to 18f's list of incoming webhooks here: https://gsa-tts.slack.com/apps/A0F7XDUAZ-incoming-webhooks
I think another way of distinguishing between non-appy "incoming webhooks" and apps that have "incoming webhook" functionality is that the latter can be shared and easily added to multiple Slacks across the whole Slack ecosystem, not just TTS's Slack. We might prefer that option if we added functionality to CALC that allowed, say, a CO or Data Administrator to ping them on their Slack of choice whenever an event occurred, rather than emailing them. And the UX from their end would probably be super simple, kind of like authorizing a third-party app to use your GitHub account--i.e. it wouldn't require them to manually fill out the webhook form on their Slack's admin screen and paste a weird URL into it or something.
I think it's understandable that such "webhooks packaged as apps" not be able to override the default username or icon because that could easily lead to spoofing--e.g. imagine a CO installing the CALC app to notify them on Slack, but then the CALC app suddenly starts posting messages to it masquerading as GitHub or something. It's less of a concern with non-appy webhooks I think, because it's admins who install webhooks, and it's assumed that the webhooks are scripts that they or other trusted people wrote.
Heck I dunno, I could be totally wrong.
Anyhow, though, I tested this integration out by making my own personal Slack and configuring my CALC dev instance to use a webhook I configured on it. I can give you access to the Slack and go over it if you want.
Oh sorry, I didn't realize you were looking at that--that must have been confusing! Yeah, before I knew about non-appy incoming webhooks, I thought I'd have to create an app, so I made that... but then once I found out about the non-appy way to do it, I forgot to delete the app. I've done that now.