Transactional email and SMS about govflow HOT 12 CLOSED

This work has started in #17

At time of writing the PR provides wrappers for sending email and sending SMS around send grid (a Twilio company) and Twilio respectively. Accounts last Twilio and SendGrid with API Keys are required - see the .env.template for what settings are required.

The PR also provides a simple way to send test emails and sms to self, using the appropriate TEST_TO_* settings, and the modules in the CLI directory.

All the logic for sending still needs to be done. Notes:

• all Service Request statuses that are "closed" should send a message
• message goes to email or sms, dependent on user's provided details
• the admins of the system probably need to optionally be able to customize the message sent
• once a message has been sent for a service request, don't allow other messages to be sent for the service request (lock messages)

The above is probably enough for the MVP, but as we develop out the workflows feature, sending messages will get more complex, including:

• sending multiple messages at stages of the service request handling
• receiving responses to sent messages (eg: it is not fixed, here is a photo to show you)

from govflow.

Update: Agreed yesterday to use the core SMS and email integration for all transactional messaging- i.e. to StaffUsers and public users alike.

For StaffUsers:

• If StaffUser is admin, email the staff user when each new service request hits the inbox
  • verify: what is our API to check if a staff user is an admin
    • @amirozer do we get this information from our internal integration? On the open source code, we can add a boolean field to indicate admin status
• For each assignment of a request to a staff user, email the staff user that they have been assigned
• When each service request is closed, email both the assigned to staff user and the staff user admin, to say the issue has been closed.
  • we could possibly drop this step, but, because any staff user could set an issue to closed, not only an admin or the assigned to user, I think it is probably useful.

For Public Users:

• If we do not have contact details, we can't send a message
• Because we do not verify the validity of contact details, we may not ever be able to deliver a message
• If the public user provides email and sms, use email. if email is not deliverable, fall back to sms
• If a public user only provides one of email or sms, then use that
• When the public user submits a request (i.e.: it hits our inbox), then message the public user to confirm receipt of the request. This also allows us to close down on the delivery strategy and to know if a message is deliverable, and we persist that information (i.e: a scenario where a user submitted sms and email, we tried email and it was invalid, so we fallback to sms and it delivered, then, we know that the communication channel for this user on this request is sms)
• when a request is closed, then email the public user. the email message is slightly modified based on the type of closed status. for example, closed as in "fixed" indicates that, closed as in "can't confirm" the issue indicates that, closed as in "invalid jurisdiction" indicates that.

Implementation notes:

• The server will have templates for each message (email and sms of each message type) which could be customizable in future but for now are not
• Message sending code will be structured in a way that we can refactor this functionality in some nearish future to use a queue, but for now we will send the messages using twilio and send grid apis in the request / response cycle, when a request triggers a state change that requires a message to be sent.
• There is the possible issue of closed tickets having a message sent, but then the ticket being reopened or moving states and then triggering additional messages to public users. I think the simplest way to avoid sending undesired messages is to manage that at the service request level and not the message level, i.e.: if a service request moved to a closed state, it cannot be re-opened.

from govflow.

Hey, the flow sounds great!

Regarding determining who should get every single ticket - We do have a role of an Admin, this is for example the person who can invite other users to the platform. I can return it from the Staff Users repository.

Regarding closed tickets - I support the option of not allowing to re-open a ticket. I'd check that with Williamsburg in advance. WDYT @idoivri ?

from govflow.

Also required #12

from govflow.

Quick summary, things look good so far in progress, but we definitely need to solve:

1. #12 - open/closed state of different statuses
2. Will we assume closed service requests cannot reopen - I will assume yes unless we discuss otherwise.
3. Our discussions to date around admin users has been about "admin users for the system", and not "admin users who are staff users for a given jurisdiction". For now, I am just assuming all staff users are admin users. If there is a nice solution for this on our internal closed codebase, I can model the staffuser object in govflow on that, otherwise, I'll leave it as is for now.

I am sure there will be other edge cases and design decisions we need to make before the branch is actually ready to merge, but I will have it for review in the next days.

from govflow.

Regarding closed tickets - I support the option of not allowing to re-open a ticket. I'd check that with Williamsburg in advance. WDYT @idoivri ?

I'm okay with not allowing this

from govflow.

@amirozer @pwalsh what about unsubscribing from e-mails / SMSs?
I think we need to be able to disable sending of e-mails / SMS so as not to spam users.

from govflow.

See #17

from govflow.

what about unsubscribing from e-mails / SMSs?

@idoivri we can use SendGrid and Twilio functionality for that so we don't have to implement expiry tokens and maintain lists of unsubscribes for emails and for phones directly - I mean, we probably want to do that eventually, but it is a lot of work.

Let me know if you both agree with the following and I'll do there minimal required changes to enable it:

1. For SMS, we use Twilio's built-in stop word support. So, we append to each message, a statement like "Respond with STOP" to unsubscribe from these messages. Respond again with START at any time to resubscribe".
2. For Email, I am pretty sure that SendGrid can automatically add an unsubscribe link to the bottom of each email - will check.

Doing it like this means our system does not "know" about subscribe or unsubscribe state, but we can build that out later, by either managing all the logic ourselves in Gov Flow, or, by using SendGrid and Twilio APIs to update our own lookup tables based on the data that they have.

from govflow.

Relying on third party services for unsubscribing sounds great, just make sure we can get the list of unsubscribed numbers/email addresses so we can migrate in the future and manage that as part of Govflow. Thanks

from govflow.

Additional tasks:

• Make sure that link to service request on internal dashboard goes directly to its detail view
• Add unsubscribe link to email
• Add unsubscribe action to sms

from govflow.

Done in #17

from govflow.