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
set all existing rows to have a version of 1 (also copy across values
to populate the new provider_details_history table in the upgrade
script)
in dao_update_provider_details bump the provider_details.version by 1
and then duplicate into the history table as a new row
(done manually as opposed to the decorator used in template_history
since this is only edited in this one place and the decorator is icky)
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
* to be used for auditing changes to provider details
* not hooked in yet
* also made provider_details.active non-nullable. set all existing null
provider_details.active to FALSE. none are set false on live so
should hopefully be fairly uncontroversial
* refactored NotificationHistory.from_notification and update from noti
to share with provider_details_history
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.
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.
- Problem was that on notification creation we pass the template ID not the template onto the new notification object
- We then set the history object from this notification object by copying all the fields. This is OK at this point.
- We then set the relationship on the history object based on the template, which we haven't passed in. We only passed the ID. This means that SQLAlchemy nulls the relationship, removing the template_id.
- Later we update the history row when we send the message, this fixes the data. BUT if we ever have a send error, then this never happens and the template is never set on the history table.
Fix:
Set only the template ID when creating the history object.
* Ensure we dont raise exception if e.cause does not contain a message
* Ensure we handle case where e.path may be empty
* Refactor existing tests to conform to new format
