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.
If passing in `redact_personalisation` to the template update endpoint,
we should mark that template permanently as redacted - this means that
we won't ever return the personalisation for any notifications for it.
This is to be used with templates containing one time passwords, 2FA
codes or other sensitive information that you may not want service
workers to be able to see.
This is implemented via a separate table, `template_redacted`, which
just contains when the template was redacted.
Including:
- url to push the inbound sms to
- bearer_token to be added to the header of the request.
The services will be expected to manage these properties.
The structure has been flattened, so I need to create a new endpoint, start using that endpoint, then change the name back.
Added template_id and version to the get job stats by id.
This is because 7days should be the amount of data in that table so don't restrict.
Note not all queries do this in the same way and a pivotal bug has been raised to align this. This is a bug fix as right now the numbers are out in prod.
A job only ever has one notification type.
This is the first deploy, where the columns are added and populated.
Next a data migration will happen to populate these new columns for the older jobs that do not have the values set.
Then we stop populating the old columns and remove them.
This refactoring of the table structure will make the queries to the table much easier to handle.
two endpoints:
* get all inbound sms for a service (you can limit to the X most
recent, or filter by user's phone number [which will be normalised])
* get a summary of inbound sms for a service - returns the count of
inbound sms in the database, and the date that the most recent was
sent
Same as how we ignore ‘send yourself a test’ messages (see:
d8467bfc3c). The dashboard gets clogged
up with one off messages otherwise, which affects:
- performance
- users ability to find their jobs
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 😩
In the future we might want to validate email addresses before
attempting to search by them. But for a first pass we can just return
no results when a user types in something that isn’t an email address
or phone number.
It definitely better than returning a 500.
