When you land on the page it’s good to be able to quickly see what the
currently-set value is, before you change it.
This is unnecessarily hard if the selected item is buried half way down
the page. This commit moves it to the top.
Currently the brandings have non-deterministic sorting, which means
the order changes from page load to page load. This makes it hard to
find the item you’re looking for.
This commit sorts them by the name of the branding, same as for email
brandings.
These helper functions for modifying a service permission were just
floating around loose in the view code.
A much better home for them is on the model. This will also make it
easy to reuse them in other views if we ever need to.
In trial mode you can’t send letters. But it’s still useful to be able
to build up a letter to see how it work.
Best place to put this error is before someone tries to send a letter
for real.
We didn’t used to allow this because it wasn’t really possible with the
old DVLA set up and we didn’t think there’s a need.
We think it’s possible now because, even though it’s cumbersome, it’s
better than the manual process.
There’s a lot of code in service settings which:
- talks to the API directly through the clients
- passes that information through to the Jinja template
By encapsulating this logic in the service model:
- the Jinja template can access the data directly
- the logic can be reused across multiple methods
This commit is the first step to disentangling the models from the API
clients. With the models in the same folder as the API clients it makes
it hard to import the API clients within the model without getting a
circular import.
After this commit the user API clients still has this problem, but at
least the service API client doesn’t.
Making people use a property is a sure way to make sure they’re spelling
the name of the property correctly, and allows us to easily swap out
properties that call through to the underlying JSON, and properties
which are implemented as methods.
This means we can have a method on the service model which hits the API
(or Redis) but can be called multiple times (within the context of a
request) without making multiple network requests.
It does this by storing the results of the method on the object’s
internal `__dict__` the first time the method is called.
We do a lot of logic around choosing which templates to show. This logic
is all inside one view method.
It makes it cleaner to break this logic up into functions. But this
would mean passing around variables from one function to another.
Putting these methods onto a class (the service model) means that
there’s a place to store this data (rather than having to pass it around
a lot).
Making this code more manageable is important so that when we have
templates and folders it’s easy to encapsulate the logic around
combining the two.
`_get_current_service` is a function which gets called every time
`current_service` is referenced in a view method or Jinja template.
Because the service model was getting initialised inside this function
it was being reconstructed many times in one request. On the service
settings page, for example, it was getting initialised 43 times, adding
about 200ms to the response time.
This commit moves its initialisation to the point where we’re getting
the data from the API, which only happens once per request.
We already have tests for the
/services/<service_id>/notifications/<notification_type> page, but these
were not testing the page when there were failed notifications, so this
adds a test for the page in this situation.
Once all our users have upgraded to the latest clients they won’t need
this. The latest clients only use the combined key and service ID.
Discuss: when can we safely remove it?
At the moment we show precompiled letters that have failed the
validation as having been sent. This is confusing.
We should communicate it as having been cancelled (rather than failed),
with the implication being that Notify has come along and cancelled the
letter before printing it. I think this is conceptually what makes the
most sense.
From the user’s point of view any letters that show up as cancelled
probably need to be fixed and resent, so it makes sense to group them
with the same name.
At the moment we are manually cancelling letters for people when they
ask us to. Once’s we’ve done this there is no indication that it’s
happened except for the date going red on the list of letters.
This commit adds some error messaging and styling to show when a letter
is cancelled.
Letting people cancel their own letters will be a future enhancement.
We were passing both dvla_org_id and filename to template-preview
temporarily while we switch to only using filename. Now that
template-preview is set up to use filename, we can stop sending the
dvla_org_id too.
One of the changes this pulls in is encoding of
periods in the token used for new password
requests.
In real-life the resulting URL is build by
concatenating the base url with the token so it
isn't processed further.
The test for new password requests builds the URL
with url_for. This encodes the result returned so
the periods are encoded twice.
We now pass through `filename` to the Template Preview `/preview.<filetype>'
endpoint in addition to the `dvla_org_id`. Template Preview will be
changed to only use `filename`, and once this has been done, we can change
the code to only pass through `dvla_org_id` instead of passing through
both pieces of information.
- add get/post view
- create a pdf upload form
- add a template where user can upload the file
- check boundaries of the letter by calling template-preview
- display banner messages with boundaries validation result
- display pages of the document, with visible boundaries overlay
if the document did not pass validation, and without overlay
if they do pass validation
Updated the 'get_sum_billing_units' function to no longer multiply the
billing units by the rate multiplier. The billing_units that come from
notifications-api already consist of the billable_units * rate_multiplier.
The rate_multiplier is also not returned from the api response anymore.
Also updated the billing mocks since these were not mocking the right fields in
the JSON responses from the API billing endpoints, and added the new
'postage' field which will get returned from the monthly-usage endpoint
in notifications-api.
We’ve had a support ticket saying:
> Hi, where a letter goes over to two sides, is there a way in the
> 'Preview' screen (or anywhere else) that I can see page two? I can
> see page one OK, but can't work out how to see what's generated on the
> second page.
Whether you’re about to send 1000s of letters – or just want to preview
how one will look – it’s probably useful to be able to see more than
just the first page.
Pytest is deprecating the direct calling of fixtures. One fixture that
we call directly quite a lot is `fake_uuid`. Since it just returns the
value of `sample_uuid()` we can either call that instead (where we need
a fixed value) or generate a new UUID each time (where a fixed value is
not needed).
2/3 of our incomplete requests to go live are incomplete because the
Data Sharing and Financial Agreement isn’t signed.
We reckon we can be pushier about this by saying it’s ‘incomplete’ where
we know the agreement is signed.
Where the agreement is signed we should confirm this, rather than make
the line disappear. This is so it makes more sense to someone who sees
it as ‘incomplete’, signs it, then comes back to the page.
If we don’t know whether or not the agreement is signed we should wait
until someone has got in touch with us by requesting to go live to
figure it out. So that’s why we’re not showing that line at all.
This tag was not showing up in the call to the Zendesk API because the
return value of a generator is not included as a member of that
generator (on things `yield`ed from it are).
