In future changes, services will be able to control whether their text
messages will be prefixed with the name of their service.
This commit:
- adds a column to store the value of that setting
- makes the service model take notice of it, if it were to have a value
set
It doesn’t:
- provide a way of setting the value of this column
Currently the column can have three values:
- `None` – ignore it (this is what all current services will start as)
and continue to determine whether to prefix messages by looking at the
sender
- `True` – always the service name to the start of text messages
- `False` – never add the service name to the start of text messages
In the future we’ll migrate all services to be either `True` or `False`,
the `None` will go away and all services will have direct control over
the setting.
If the service is sending messages from GOVUK, then its messages should
be prefixed with the service name. Right now this logic is:
- worked out separately in the admin app and API
- isn’t aware of multiple senders
This commit moves the logic to one place (the service model). It does
this in a slightly naive way, in that it only looks at the default
sender, not the actual sender of the message.
In the future this will go away because we’ll move it to being a setting
that’s controlled independently of the service name. But this is the
first step towards that.
fixup! Add prefix SMS with service name to service model
- moved get_current_financial_year_start_year from service.utils to dao.date_utils
- Moved logic for data persistence from rest to dao when updating records in db
NotificationStatistics was added as a spike but didn't work out as expected. This is finally removing all that unused code.
I'll drop the table in the next PR
Instead of retrying if there are genuine errors, only retry if there are
errors which are unexpected as otherwise the retries will happen and
fail for the same reason e.g. that the message has changed format and
will require a code update.
- Updated process_ses_results to only retry if there in an unknown
exception
- Update test and assert that there is a retry there is a unknown
exception
In preparation for moving the SNS notification to an SES queue remove
the HTTP errors codes and arguments as the method will now be run by
a celery task. Also made the callback http method return more generic
codes as this will be removed in the longer term.
- Removed errors and arguments returned from process_ses_response
- Updated tests
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.
When a service is allocated an inbound number and they only have one SMS sender, then update that SMS sender to the inbound number.
That way they will not have more than one SMS sender and will not have to choose to use either one.