We are using the notify queue in this iteration because that queue is a low volume queue with it's own dedicated workers. This just saves us from building a new queue at this point, and a new queue may not be necessary.
- Added the `simulate` notification logic to version 2. We have 3 email addresses and phone numbers that are used
to simulate a successful post to /notifications. This was missed out of the version 2 endpoint.
- Added a test to template_dao to check for the default value of normal for new templates
- in v2 get_notifications, casted the path param to a uuid, if not uuid abort(404)
We’ve seen quite a few developers encounter the `Invalid token: expired`
error message when they’re getting started using the Notify API. When
this happens they either raise a support ticket or ask for help on
Slack.
In every case this has been because the clock on their
machine/environment/container isn’t accurate. The error message doesn’t
help them figure this out.
This commit adds extra detail to the error message so they can fix the
problem without having to come to us for help.
If the template is marked as priority the notification will be sent using the `notify` queue.
The `notify` queue is a low volume queue, messages here will not be queue behind a large job and should be delivered with in a more consistent time frame.
- Added templates.process_type and templates_history.process_type column.
- Added a template_process_type table to handle the enum for templates.process_type, initial values are normal and priority
https://www.pivotaltracker.com/story/show/135429147
while it's nice to use the decorator to signify fixtures with side
effects, it has unfortunate problems of completely overriding any
fixtures you've declared in the funcargs - so isn't really suitable
for our usecase where we often have other fixtures we rely on to
return values to us.
So for consistency, let's remove this and stick to using funcargs
to define our fixtures
when you invoke the fixture `sample_user`, it does two things: it
creates the user in the database, but also returns the user, a useful
object that you may want to manipulate or reference in your test.
however, when you invoke the fixture `notify_db_session`, it doesn't
do anything - rather, it *promises* to clear up the database tables
at the end of the test run.
because we have no need of the notify_db_session object in our tests
(indeed, for a long time this fixture just returned `None`), using
`pytest.mark.usefixtures('notify_db_session')` brings attention to the
fact that this is a side-effect fixture rather than a data setup
fixture. Functionally it is identical to passing as a parameter
note that all of these tests have to be checked to ensure that they
still call through to notify_db_session (notify_db not required) to
tear down the database after the test runs - since it's no longer
required to pass it in to the function just to invoke the sample_user
function
this create_user function can be imported for use in creating specific
users in your tests, for example
```
from tests.app.db import create_user
def test_create_user_persists_to_database(notify_db_session):
user = create_user()
assert User.query.count() == 1
```
this has the benefit of not requiring you to pass the notify_db and
notify_db_session fixtures around, and separating custom object
creation from the fixture dependency trees to aid clarity
I started with sample_user since it has no downstream dependencies, but
the intention is to push this out to all db fixtures eventually. This
is a total conversion, but can be rolled out in a non-breaking manner
by keeping arguments in the fixture, and passing them through to the
new db function - then tests can be updated to use the create_* instead
of sample_* functions as and when you want to
brings in a fix to InvalidEmail/Phone/AddressExceptions not being
instantiated correctly. `exception.message` is not a python standard,
so we shouldn't be relying on it to transmit exception reasons -
rather we should be using `str(exception)` instead. This involved a
handful of small changes to the schema validation
The financial year start April 1, 00:00 BST and our dates are stored as UTC.
Added a test for get_april_fools.
Added some test more test data for get_billable_unit_count_per_month.
cloudfront caching isn't set up on those environments yet, so continue
to use flask for now - in the future we'll want to revert this once
those environments are up and running properly
When the start_date and end_date query argruments exists in the request,
the query will return the results from the NotificationHistory table for the given date range.
We will need to check the performance of this query, but this will only be used by the platform admin page.
it now switches utils.template.Template type, since the base Template
type now no longer has a subject attribute.
updated test case to use `sample_email_template_with_placeholders`
instead of `sample_email_template`
branding in emails was previously hosted from admin app - this changes
the url to be static.{domain}/images instead of {domain}/static/images,
which redirects to cloudfront.
some manipulation of the URL was required to make sure it still serves
locally rather than returning "static.localhost:6012" for example.
(if ADMIN_BASE_URL is localhost it just returns the old /static/
path)
also was able to remove DB interaction from a test. woo!
The reason for doing this is to ensure the tasks performed for the Notify users are not queued behind a large job, a way to
ensure priority for messages.
6th task for story: https://www.pivotaltracker.com/story/show/135839709
The reason for doing this is to ensure the tasks performed for the Notify users are not queued behind a large job, a way to
ensure priority for messages.
5th task for story: https://www.pivotaltracker.com/story/show/135839709
The reason for doing this is to ensure the tasks performed for the Notify users are not queued behind a large job, a way to
ensure priority for messages.
4th task for story: https://www.pivotaltracker.com/story/show/135839709
the provider details tests were previously very stateful - they
would update a value, and then because provider_details is a "static"
table that is not wiped by the notify_db_session fixture, the tests
were forced to make a second update that reverted that change. if the
test fails for whatever reason, the provider_details table ends up
permanently modified, playing havoc on tests further down the line.
this commit adds the fixture `restore_provider_details` to conftest.
this fixture stores a copy of the contents of ProviderDetails and
ProviderDetailsHistory tables outside of the session, runs the test,
and then clears the table and puts those old values in
this means that the tests have been cleaned up so that they do not
do operations twice in reverse. they've also been cleaned up
generally, including fixture optimisations and such
the first argument to ANY logger.____ function is ALWAYS cast to a
string and used as a format argument for ALL remaining arguments
using %s formatting. even `logger.exception`, which just logs as
normal and then appends the stack trace.
so we shouldn't be passing `e` into logger.exception - just
`logger.exception('something went wrong!')`
also de-duplicated a test
- note this is an unexpectedly big change.
- When we create a service we pass the service id to the persist method. This means that we don't have the service available to check if in research mode.
- All calling methods (expecting the one where we use the notify service) have the service available. So rather than reload it I changed the method signature to pass the service, not the ID to persist.
- Touches a few places.
Note this means that the update or create methods will fall over on a null service. But this seems correct.
Goes back to the story which we need to play to make the service available as the API user so that the need to load and pass around services is minimised.
