The add new templates page now has option to add template folders.
Tweaked wording of other options and h1 to clarify options since it's
not all about templates any more.
Added api client and stuff for it
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.
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.
- 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
We’ve learned of a change implemented today by the UK mobile
network operators, to stop allowing text message sender names
of 3 or less characters.
Adding this validation will not affect existing senders, only those
users trying to add to or update their senders.
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.
When there is a uniqueness constraint on a DB column you can still have
multiple null values.
You can’t have multiple empty string values.
We are trying to save the domain as empty string when creating or
updating a new branding. This means that it’s currently not possible to
create or update a branding with no domain, because the uniqueness
constraint is violated.
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
At the moment we transform what the user gives us, so if someone enters
`digital.cabinet-office.gov.uk` it will automagically be saved as
`cabinet-office.gov.uk`. This happens without the user knowing, and
might have unintended consequences.
So let’s tell them what the problem is, and let them decide what to do
about it (which might be accepting the canonical domain, or adding a
new organisation to domains.yml first).
When saving an email branding it’s possible we might not enter the
canonical domain for an organisation into the domain field. Because
we’re going to use the canonical domain to look up the brandings this
will cause a mismatch.
Rather than validate this and show an error, let’s just save the correct
thing instead. From the user’s perspective this means everything will
just work (ie a user with a given email address will automatically get
the right branding for their organisation).
We should make sure we’re not putting typos in the branding list. We can
validate what gets entered here against our known list of public-sector
domains.
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.
Selecting a branding just takes you to a new page, it doesn’t change
any state.
Links are generally the way you go from one page to another on the web.
This commit improves the code that previews a hex colour when setting up
or changing an email branding.
Specifically it:
- refactors the Javascript to conform to our patterns (module pattern,
preprocessed with Gulp)
- makes the code work when there are multiple colour previews on one
page
It also does some visual prettifying, because I couldn’t help myself…
Service contact details are needed if the upload document permission is
enabled - this used to be a link but services can now choose to use a
link, email address or phone number. The form to add or change service
contact details now gives these options and validates the data according
to the type of contact details provided.
When validating phone numbers we can't use the existing validation
because we want to allow landlines too, so there is a basic check that
the phone number is the right length and doesn't include certain
characters.
Since we have added a new, 5th permission the existing permissions
should be relabelled so that the five make sense as a coherent set.
We especially want to make sure that:
- the labels work against the checkboxes and against the tick/crosses on
the manage users page (a long time ago this page was layed out
differently so didn’t have space for full labels)
- there is no confusion between usage and reports
This commit also:
- re-adds a line about what all users can see (‘sent messages’) but
continues to omit the additional bullet points about templates and
team members (because we think this is clear enough from reading the
permissions)
- refactors the `Form` subclass so that the content and order of the
permissions only have to be defined once
- brings back the ‘permissions’ legend on the `fieldset`
Our research and prototyping around ‘basic view’ found that:
- a lot of users who send messages rarely or never look at the dashboard
(yet it’s the first page they see when they sign in)
- team managers like the idea of taking away things that users don’t
need in order to make the interface simpler
We’ve disentangled the simpler way of sending messages from being part
of ‘basic view’. This means we can give managers the option of taking
away the dashboard as an independent choice, not something that’s
wrapped up in a separate ‘view’.
I think that this checkbox is a more straightforward proposition than
‘basic view’ ever was (despite all the work we did to explain it and
develop the nested checkbox pattern). In research users would often
explain the feature back to us as being about hiding the dashboard – we
should try to make Notify operate in terms of concepts that come
naturally to people wherever possible.
