Skip to content
This repository has been archived by the owner on Jul 12, 2023. It is now read-only.

Support for Twilio messaging service #1526

Merged
merged 25 commits into from
Jan 7, 2021
Merged

Conversation

whaught
Copy link
Contributor

@whaught whaught commented Jan 7, 2021

Proposed Changes

  • Twilio provides a service to manage one or a pool many phone numbers and rules about how to use them. This requires passing an identifier instead of a from-number. See: https://www.twilio.com/docs/messaging/services
  • Adds support for a messagingServiceSid instead of a from-number
  • Note: I'd like to test this against Twilio, but trial accounts don't get these - I hear they cost more.

Release Note

Added support for Twilio messaging services

@googlebot googlebot added the cla: yes Auto: added by CLA bot when all committers have signed a CLA. label Jan 7, 2021
@whaught
Copy link
Contributor Author

whaught commented Jan 7, 2021

/hold

This may not be a good idea if we wish to steer users away from this feature of Twilio. Hold for discussion.

Copy link
Member

@sethvargo sethvargo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a paid Twilio account for testing. Ping me on chat and I can walk you through how to access it.

pkg/database/migrations.go Outdated Show resolved Hide resolved
@sethvargo
Copy link
Member

My high-level feedback is that a MessagingServiceSid is basically a "from" number. The only functional change is the query parameter key that gets sent. From a UX perspective, I think it would be better to use the existing "from" number field (updated some text in the UI). Then, it's trivial for us to detect if the value is a phone number or from number (MSIDs always start with MG).

@whaught
Copy link
Contributor Author

whaught commented Jan 7, 2021

My high-level feedback is that a MessagingServiceSid is basically a "from" number. The only functional change is the query parameter key that gets sent. From a UX perspective, I think it would be better to use the existing "from" number field (updated some text in the UI). Then, it's trivial for us to detect if the value is a phone number or from number (MSIDs always start with MG).

I have merged them into one field in the UI - I've left the placeholder as "from number" but updated the small text detail

ID: "00083-AddTwilioMessageSid",
Migrate: func(tx *gorm.DB) error {
return multiExec(tx,
`ALTER TABLE sms_configs ADD COLUMN IF NOT EXISTS twilio_messaging_service_sid varchar(255)`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was trying to say: I don't think we want a new field/column at all.

  • Make sure from can handle 255 characters
  • Add something in sms.go:
    if strings.HasPrefix(from, "MG") {
      q.Add("MessagingServiceSid", from)
    } else {
      q.Add("From", from)
    }

That should dramatically reduce complexity and avoid boolean logic for if msid else from.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure - expanded the existing db column instead.

Copy link
Member

@sethvargo sethvargo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

There's two nits: one on migration and one about docs. Feel free to do those here and add your own LGTM or a followup.

},
Rollback: func(tx *gorm.DB) error {
return multiExec(tx,
`ALTER TABLE sms_configs ALTER COLUMN twilio_from_number TYPE varchar(16)`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not rollback the size change, that will lose data unnecessarily.

Copy link
Contributor Author

@whaught whaught Jan 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure - we do have similar rollbacks when we've done this in the past:
eg: "ALTER TABLE verification_codes ALTER COLUMN long_code TYPE varchar(20)",
which may also be scary and destroy data

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yea we shouldn't roll back to a smaller column

pkg/sms/twilio.go Show resolved Hide resolved
@google-oss-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sethvargo, whaught

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-robot
Copy link

New changes are detected. LGTM label has been removed.

@sethvargo sethvargo added the lgtm label Jan 7, 2021
@google-oss-robot google-oss-robot merged commit a6c6186 into google:main Jan 7, 2021
@whaught whaught deleted the raw-errors branch January 7, 2021 18:00
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cla: yes Auto: added by CLA bot when all committers have signed a CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants