Also removed an extra query to services.
The query has been refactored to use an outer join to services on the notifications or notification_history table.
The expectation is that this change will improve the performance of the trial/live-services pages for platform admins.
International SMS is a mature, documented feature now. There’s no reason
it shouldn’t be available to everyone. If it’s turned off by default
then we’re relying on people finding it in the settings page to know
that it exists (which we found in research the other week that users,
who would have benefitted from having international SMS, were failing to
do).
This also fixes the problem whereby users signing up for Notify with an
international phone number (eg those working abroad for the Foreign and
Commonwealth Office) couldn’t get through the tour because they weren’t
able to send themselves the example text message (see
https://www.pivotaltracker.com/story/show/150705515).
This will need to be refactored after the deployment of api and admin and after the update script for existing services using inbound numbers has been executed.
I updated the InboundSms and TemplateRedacted model to include an index in the db.
Dropped service_permissions.updated_at column since we are not auditting the table
Replace labels by adding a key kwarg in the model for status.
We still need this as sqlalchemy attmempts to look for `notification_status`
on the model (Notification/NotificationHistory). To achieve true ORM mapping
(map status -> notification_status) we need the key kwarg.
More here:
http://docs.sqlalchemy.org/en/latest/core/metadata.html#sqlalchemy.schema.Column#key
Since the version classes hinge on delicately preserving the session,
we need to take lots of care to ensure that we don't accidentally flush
half-way through. By joinedloading the template_redacted beforehand,
we prevent a flush which would inadvertantly remove the Service object
from the session, while it's still waiting in line to be versioned.
sqlalchemy default doesn't appear to work correctly when there is a
difference between the DB schema and the code (ie: during a migration)
in this case, lets just set sms_sender ourselves.
we can't write unit tests for this because this only happens when the
db is in an inconsistent state 😩
We now have a new column in the database, but it isn't being
populated. The first step is to make sure we update this column,
while still keeping the old enum based column up to date as well.
A couple of changes have had to happen to support this - one irritating
thing is that if we're ever querying columns individually, including
`Notification.status`, then we'll need to give that column a label,
since under the hood it translates to `Notification._status_enum`.
Accessing status through the ORM (i.e., my_noti.status = 'sending' or
similar) will work fine.
