Autojoin channels based on signup flow information

[hollomancer]

As a user, I want to autojoin a Slack channel corresponding to my military status (milspouse / active duty), so that I have a new user experience tailored to my current life situation.

Product Requirements

• (MVP) Users on signup that identify as a military spouse autojoin #milspouses.
• Users on signup that identify as active duty autojoin #active-duty.

[brownnrl]

I'm new here, but this looks liked a combined feature between the backend passing the e-mail plus the military status. Either the backend or the pybot will need to keep an association between the status and the channel.

It looks like the pybot is using the undocumented user invitation referred to in this SO post. So if the backend could pass the e-mail and an optional status, then the pybot could take that and associate that with the correct channel id's to include on the invitation.

[brownnrl]

So initially, when the slack invitation is created the user profile may not have the military status information.

The user can update their profile at any time to change their current status with incremental updates to their profile. They can also change their status before signing onto slack via their e-mail link, or not update their profile and log onto slack.

So check would be performed after both a slack ID is given from the bot to the back-end or the front end communicates a status update to their profile. If the check was successful that both slack id and military status exist in the DB, then a call the python bot would be made invite the user to the associated channel.

For after invitation joins, a python bot would invite a user to the channel via the slack API channels.invite. However, the python bot would need to be a member of that channel according to the documentation. It would need to sit on activeduty and milspouses.

It looks like milspouses is a shared channel, so I don't know if adding the bot to the channel would be permitted?

[mdaizovi]

Sounds fun. If it can wait until the weekend I'd like to have a crack at it.

[brownnrl]

@mdaizovi I committed the WIP I have so far and on OperationCode/operationcode-pybot#110 on my fork and my pybot fork. I was just going to put some better unit/integration tests on it tonight.

It's not really complete. In the pybot I don't do channel invitations just extended the the existing messages when slack-id and status is present and changes. I haven't tested it actually working with Slack in the loop.

I'll be out camping this weekend and won't be able to work on it after tonight. If you want to take it from there this weekend and review/clean up/scrap and rework/change/test and put a PR together, I'm cool with that if you want to team up or take it over yourself.

[brownnrl]

Ok, I did the test last night and pushed that up just not in the commit above so it looks like it's working in my local environment. I won't be able to work on this anymore until later next week.

@mdaizovi did you want to take it over from here with the pybot changes too? I didn't get a chance to write any tests for pybot. You can take credit for both if you want. If not, I'll pick it up again later next week. :)

[mdaizovi]

Hey @brownnrl , I'm very happy to collaborate with you on this but it looks like you've done most of the work! I apologize for my non-response, hard to find time after work and familiarizing myself w/ codebase. I do have a few things 'd like to add, so I'd love to do them this week, but if you get to it first, no problem, there will be other issues.

[brownnrl]

No worries. I'd actually prefer to collaborate with you. After work time flies with family stuff, but I would like to contribute, help others contribute, and learn from how other people tackle issues.

I think that the ticket on this side is fairly complete, but the pybot changes are still incomplete on the other side. I have had the front end and back end communicating, but I don't have experience simulating the pybot locally (I haven't tried). As I said before, I don't have any unit / automated integration tests implemented for the pybot changes.

If you have any roadblocks I'll be happy to take a second look too. We can also connect on the opcode slack as well.

[mdaizovi]

Great! I'm not finished, but this is what I'm thinking: the user should be auto joined, so some of the status data should be included in the initial invite, and then also sent as a message if the status changes. Also, we should try to abstract a little so that if more status channels are added it's easy to add this functionality. I haven't finished yet, nor have I tested it, and I think the dicts could be put in a better place, but this is where I'm thinking we should go with it. Your thoughts?

[brownnrl]

On your first point, the problem I discovered with including it in the initial slack invite is that the military status information might not be present when the slack invite is sent out.

Currently, a new user signs up with email / password / name / zip code. Then the back end at that point sends the initial slack invite and email confirmation. Then the new user can login, join the slack, confirm their e-mail, and can update their profile with status. All of those things can be done independently. So they could update their profile first and not have a slack id, or join slack but not have annotated their status. So if you wanted it to be on initial invite, you'd have to change the front end as well perhaps by including military status in the initial form. But for a first pass, it probably isn't necessary.

If we use the channels.invite to use the pybot to invite them to the channel in place of where you have your commit then whenever they get around to both updating their military status and joining the slack the new user would maybe get a special message and an invite.

On your second point, an abstraction of all the functions that should be performed when a new user joins is a good idea.

However, all that needs a few tests in the pybot code to confirm those abstractions work as intended before we do any pull requests. It would also be nice to try it out with slack in the loop before a PR, but I don't have much experience in that area. Maybe I'll ping the slack channel later in oc-python-projects to see how they normally test new pybot features. I saw a pybot channel for that purpose, so I'm guessing that is how.

[mdaizovi]

I see. Well I bet we could get the background task to wait about a minute before sending the invite, and then we could check status. I bet 99% of people keep going, filling out their status, and never changing it, and also don't care if their email comes immediately after signup or a minute after signup, so it would be cool it we could just wait a minute to catch them. Once again I have to wait until weekend to implement this, but I bet we can ge something smooth and elegant going here.

[brownnrl]

Cool. Yeah, delaying the task would probably catch most. Using updates would catch the rest.

Let me know if you want any help with implementation or tests after this weekend. Likely won’t be able to touch it this weekend but will have time Monday.

[brownnrl]

@mdaizovi Hi mic, did you get a chance to work on this over the weekend? Let me know if you want any help.

[mdaizovi]

Yeah kinda. I really want to watch the signup flow go but each of the readmes only describe that repo, I haven't seen one that describes getting a full working local dev env set up. I forked and cloned all 3 of the main repos and kind of had one going with just a local virtual environment, but when I tried to run front end and back end and create a user as if in production, I'm getting a lot of errors (sentry, KeyError: 'SLACK_TOKEN', etc...) I bet I wouldn't get if I set up docker or whatever it is I'm properly supposed to do. Do you know if this document exists, or do I need to just figure it out?

[brownnrl]

It looks like they have a test slack. https://github.com/OperationCode/operationcode-pybot/issues/69

We can get a test token either via that or create another slack test channel. Probably best to get a recommendation from someone that owns the process on oc-python-projects channel.