Add individual snippets reminders for slack/hipchat #18

Open
csilvers opened this Issue Jan 19, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@csilvers
Member

csilvers commented Jan 19, 2016

Right now we send a personalized email to a person who hasn't written snippets, saying "They are due tomorrow!" But for chat, we only send a generic message. It would be nice to support a 1-on-1 message from snippet-bot to those users who still need to submit snippets. (It could also be on sunday night, or we could do monday a bit before snippets are due.)

Implementation-wise, I think what we would do is to look at app-settings to see what chat services are enabled, and for each such service put a field on the user-settings which is something like " username" or other id. Then we'll use that to send the 1-on-1 message.

@mroth

This comment has been minimized.

Show comment
Hide comment
@mroth

mroth Jan 19, 2016

Contributor

@csilvers for Slack at least, it could be fairly simple to look this up via API—Slacklib is already doing the opposite in Slacklib._get_user_email_cached(), but we could do a query that was the reverse of this to automatically get the proper user ID. Although, this of course assumes you have a 1:1 mapping between user emails on Slack and GAE, but we do already use this assumption in other places in the code.

Of course, If we wanted to remove this assumption, we could maybe have it be a profile field like you mentioned, but try to auto-instantiate it with the value of this lookup as the "default" the first time?

Contributor

mroth commented Jan 19, 2016

@csilvers for Slack at least, it could be fairly simple to look this up via API—Slacklib is already doing the opposite in Slacklib._get_user_email_cached(), but we could do a query that was the reverse of this to automatically get the proper user ID. Although, this of course assumes you have a 1:1 mapping between user emails on Slack and GAE, but we do already use this assumption in other places in the code.

Of course, If we wanted to remove this assumption, we could maybe have it be a profile field like you mentioned, but try to auto-instantiate it with the value of this lookup as the "default" the first time?

@csilvers

This comment has been minimized.

Show comment
Hide comment
@csilvers

csilvers Jan 19, 2016

Member

@mroth -- I like your idea of auto-populating the settings page!

I still haven't thought through what happens if slack gets enabled as a site-wide setting sometime after the snippet deployment system (as indeed happened to us). Does every user need to go back to /settings and re-click save?

Member

csilvers commented Jan 19, 2016

@mroth -- I like your idea of auto-populating the settings page!

I still haven't thought through what happens if slack gets enabled as a site-wide setting sometime after the snippet deployment system (as indeed happened to us). Does every user need to go back to /settings and re-click save?

@mroth

This comment has been minimized.

Show comment
Hide comment
@mroth

mroth Jan 20, 2016

Contributor

Hmm, I've been thinking about this more and I am thinking that in the default case, there will probably be a 1:1 mapping, and we would want the system to be resilient to email address changes automatically. If we repopulate a setting then there is the danger of it getting out of sync when someone changes their email (e.g. one more place to have to change it), versus the cached API lookup which should always be somewhat up-to-date.

If that was the case, maybe the best default behavior is assume a 1:1 mapping, but the user setting becomes a checkbox w/ field for "override slack username" or something like that? (We could also punt on it until it becomes an issue.)

Contributor

mroth commented Jan 20, 2016

Hmm, I've been thinking about this more and I am thinking that in the default case, there will probably be a 1:1 mapping, and we would want the system to be resilient to email address changes automatically. If we repopulate a setting then there is the danger of it getting out of sync when someone changes their email (e.g. one more place to have to change it), versus the cached API lookup which should always be somewhat up-to-date.

If that was the case, maybe the best default behavior is assume a 1:1 mapping, but the user setting becomes a checkbox w/ field for "override slack username" or something like that? (We could also punt on it until it becomes an issue.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment