Because some people don’t know they can put their own logo on letters:
> The HM Government Logo is at the top of the letter and we can't see
> a way of putting the [organisation] logo on
> We are intending to use the letter template feature for the first time
> and wondered whether the branding is configurable or whether the HM
> Government header is the standard default.
> Can we replace HM Government logo with our own in the letter? IF yes,
> then how?
> I don't seem to be able to set the branding on the letters to be
> [organisation]. it's always HM government. Is there something that
> needs enabling for this account?
No-one actually wants the HM Government logo (no-one is sending real
letters using it). So we should leave the space blank and put a button
there prompting people to add their own logo.
it wouldn't show search if there were under a certain amount of letter
or email branding options - however we know there will always be more
than that amount so lets remove some complexity.
Also, rename the SearchTemplatesForm because it can search anything -
it just prompts you to search by name is all.
new code is copied stylistically from the email branding patterns.
Instead of `service.dvla_organisation`, there's now
`service.letter_branding` and `service.letter_branding_id`. However,
unlike email branding we're not currently showing a preview of the
logo. That can come later when we work out how we want to do it.
We were getting all letter logos from a method in the email branding
client. Since we will be adding more client methods to deal with
letters, it makes things clearer to separate the email and letter
branding clients.
We are moving from the postage being set on the service to being set on
the template. Once a service has been migrated to have the new
permission they should no longer be able to set the postage at a service
level, only at the template level.
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.
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
WTForms lets you pre-populate a form’s value by passing it in as an
argument to the constructor.
This will be good for us because it will let us access that value in
the constructor later on.
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.
We have a lot of places in settings where we update something by passing
in the `service_id`. `current_service` already knows about `service_id`,
so it’s cleaner to encapsulate these updates inside the model.
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.
The API should always return something in the JSON for a property, even
if it’s just `None`.
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
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.
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.
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.
There’s something that feels a bit off about not being able to see the
name of the currently-selected branding when you land on the page.
Putting it at the top also means that you can easily switch back to it
if you change your mind.
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.
