Only users who work for government can accept the terms of use. This
will save us from having to email these requesters back telling them
they need to find someone else to submit the request.
We suggest people format their numbers with commas when telling us how
many things they’re going to send.
This causes problems when we paste these values into a spreadsheet,
because the commas get interpreted as column separators.
Adds caching for service data retention. This removes separate API
client methods to retrieve individual data retention records by id
or type in favor of a single method that fetches and caches all
retention settings configured for the service. This makes it much
easier to invalidate cache when settings change.
Lookup by id or type is provided by helper methods in the service
model.
WTForms coerces `None` as a choice to `'None'` as a string when
rendering form fields (form fields will only ever have string data
because that what the browser posts back).
But internally WTForms coerces `None` to mean an unset value, ie where
the user hasn’t selected a radio button:
283b280320/src/wtforms/utils.py (L1-L20)
We shouldn’t use `None` to mean two different things. And in fact we
can’t, because it in effect means that we’re always getting a value
for the `move_to` field, even if the user hasn’t chosen to move any
templates. Which results in some very expected behaviour.
If the browser posts the value of `<input value='None'>` to the server
it does so as a string.
We want to post a value of `None` (actually JSON `null`) to the API. To
do this we:
- set the value in the form class to `'None'` (ie a string)
- convert to `None` (as a type) afterwards
However seeing `x = 'None'` in code looks a bit like a mistake. So to
make sure it looks deliberate and clear what is happening this commit:
- makes a reusable constant for `'None'`
- adds a comment explaining why it’s a string
With the addition of template folders we need to filter templates
based on a combination of type and parent folder ID.
This replaces the existing `templates_by_type` method with
`get_templates`, which supports both type and parent folder filters,
avoiding a need to create specific methods for each use case.
We still need the templates property to exist in some way in order
to cache it, but it needs to be clear that it's different from
`.get_templates`. One option was to make it "private" (i.e. `_templates`),
and always use `.get_templates` in the rest of the code, but this requires
adding "include all folders" to `.get_templates`, which doesn't have an
obvious interface since `parent_folder_id=None` already means "top-level
only".
This will probably come up again when we need to look into adding
templates from nested folders into the page for live search, but
for now renaming `Service.templates` to `.all_templates` makes it
clear what the property contains.
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.
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.
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.
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).
At the moment we manually tag tickets as they come in so we can analyse
how many of each type we’re getting.
Further, we manually tag all the request to go live tickets once a month
to analyse how many are complete/incomplete.
All this tagging is useful, but quite time consuming. Notify already
knows this information and – using the Zendesk API – we can tag them
automatically.
I’ve checked with Holly and this is the taxonomy we want to use.
We don't show the sender addresses and letter branding on the settings page
if a service doesn't have letters enabled, so we should also hide the
postage for services that can't send letters.
(Postage can only be seen by Platform Admin users at the moment, but this will
change later).
Added a new row to the settings table, 'Post class', which shows the
default letter class of a service and is only visible to Platform Admin.
Also added a new page to enable Platform Admin users to change the
default letter class for a service - this only has two options at the
moment, 1st class only and 2nd class only.
We sometimes have to do this over support tickets as part of the go-live
process; now we’re directing people to add a sender (as part of the task
list) we can explain what it is in context.
Tests the new code that gets the brand type from
the email_branding model. Includes checks for a
service without the email_branding field set.
It also amends the test for a POST from that page,
removing mocking of the email_branding client.
This test runs against the default service which
has its email_branding field set to None so no
call is made to the client. It's testing the
brand_type values selected so doesn't need the
service to have an email_branding already set.
Since GDPR came into effect it’s less clear about whether we can
contact teams for user research purposes.
If we make people opt-in (or not) we know we’re safe to contact them (or
not).
Since we mostly care about how services are using Notify for real (ie
live services) or services that are considering adopting it (ie those
who have contacted us with a question) it feels like the go-live process
is the most appropriate place to collect this consent.
Now that we’re a more mature platform we don’t care so much about the
load that one service might put on our platform.
We do care about intended volumes for two reasons:
- modelling the benefits that services get from using Notify
- managing stocks of envelopes (while our letter volumes are small
enough that they could be skewed by one new service)
Changing to the ‘how many per year’ question also has the benefit of
mapping directly to the data we store in the ‘beta partners’
spreadsheet.
Currently we keep track of live services in the ‘beta partners’
spreadsheet:
https://docs.google.com/spreadsheets/d/1JYhE5sJaOJUVMPPDenO2eKqElC75Rygxb1_2mpRKy98/edit#gid=503930061
Every time a service goes live we need to enter some data into the
spreadsheet about that service. Most of that data is copied from the
request to go live ticket.
This commit adds a line to the ticket with all the data needed by the
spreadsheet. It’s in the same order as in the spreadsheet, and it’s
tab-delimted so it should paste right on in there.
