Users who work in local government can’t have GOV.UK branding on their
emails. And only those working for Companies House (for example) can
request the Companies House branding.
This commit adds:
- new choices of email branding, which offer the name of the branding,
rather than the style
- logic to filter this list to only the applicable options, based on
what we know about the user, service and organisation
This is a change from the previous approach which put the onus on users
to figure out the style of branding they wanted, when we might already
know that a lot of the options weren’t available to them, or would be
inconsistent with the branding of other services in their organisation.
There’s a couple of places where we’re looking up the label for the type
of organisation.
Having this repeated in multiple places means it’s more likely we forget
to update one of these places when making a change.
This commit looks up from the tuple in the organisation model, which is
where other code references this stuff from. This is only possible now
that we don’t have duplicate keys (ie GP practice doesn’t share a key
any more).
It’s possible to delete default letter contact blocks because there is a
fallback – having a blank letter contact block. This is different to SMS
senders and reply to addresses.
For this to make sense it also means:
- adding the ‘blank’ letter contact block to the list of letter contact
blocks
- having a way of setting the default back to being blank
The service organisation type will either be the same as the org type of
the service's organisation or will be set by a user when creating a new
service. This removes the ability to change it from the platform admin
settings table.
At the moment we have a blanket rule that users can’t archive their own
services, to prevent someone accidentally deleting a real live service,
because that would be Very Bad.
But the tickets we get from users asking us to delete services are for
services they set up when they were just trying out Notify. There’s not
much harm in letting users delete these services, the consequences of
doing so are much lower than those of deleting a live service. And it
should mean fewer support tickets for us to deal with.
Since we added template folders the templates page has had a ‘medium’
sized heading, where other pages have stuck with a ‘large’ size.
This commit rationalises the decision around which pages have which
heading size:
- ‘navigation’ pages (eg templates, team members, email reply to
addresses) have medium sized headings
- transactional pages (ie ones which have a green button) keep the
larger heading size
Most of the content of our ‘settings’ tables is in the value, not the
key. The value is in the middle column. So we should allocate the most
space to the value.
The previous layout was based on the premise that most pages divided the
grid like this:
```
_______ _______ _______ _______ _______ _______ _______ _______
| 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 |
| | | | |
| 2/8 | 2/8 | 2/8 | 2/8 |
| | | | |
|–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––|
| | | |
| | 3/8 | 3/8 |
| | | |
| |–Label–––––––––––––––––|–Value––––––––––––Link–|
| | | |
|_______________|_______________________|_______________________|
```
This was because a lot of pages had a left column for emails, and a
right column for text messages, so it felt consistent for tables to
always default to 50% of the width of the main column.
This consistency has faded with time, especially as we added letters.
So this commit changes these tables to allocate more space to the
central column, but still sticking to the grid like this:
```
_______ _______ _______ _______ _______ _______ _______ _______
| 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 | 1/8 |
| | | | | | | | |
| 2/8 | 2/8 | 4/8 |
| | | |
|–Navigation––––|–Main column–––––––––––––––––––––––––––––––––––|
| | | | |
| | 2/8 | 3/8 | 1/8 |
| | | | |
| |–Label–––––––––|–Value–––––––––––––––––|–––Link|
|_______________|_______________|_______________________|_______|
```
Since there’s more space to display the value of a setting this commit
also truncates settings that are too long to fit in the width of the
column (for example a long email address) rather than the previous
behaviour of truncating them. This all just makes things look a bit
cleaner.
We shouldn’t be making services live without an agreement in place. In
order to have an agreement in place we need to know what organisation
operates the service.
If a service comes along but belongs to an organisation we don’t know
about then we should create that organisation. This commits removes the
link, which should force this to happen.
Settings looked at `domains.yml` when users were making go live requests
or email branding requests.
This will allow us to remove the `domains.yml` file, by using
information about organisations that is now stored in the database
instead.
We keep getting people requesting branding when they already have the
branding they want set. Seems like they don’t realise we’re doing it
automatically. This might help.
Adds a front end for:
https://github.com/alphagov/notifications-api/pull/2417
> Sometimes we have to make a few services for what really is one
> service, for example GOV.UK Pay and GOV.UK Pay Direct Debit. We also
> have our own test services which aren’t included in the count of live
> services. We currently count these as one service by not including
> them in the beta partners spreadsheet.
When we get a request for new branding it’s helpful to quickly see what
the service’s current branding is, so we can get a better sense of why
they want to change it.
Most of the existing platform admin buttons on the service settings
page used to issue GET requests to switch service settings. This
means they weren't protected by CSRF. On top of that as our number
of service permissions increases over time a lot of buttons on the
page made it hard to work with.
To fix these issues we replace most of the buttons with rows in the
platform admin settings table. Each setting has a 'Change' link that
leads to a page with an On/Off switch form.
This removes "research mode" switch completely since we're planning
to deprecate it in the future and we don't expect to switch any new
services into research mode at the moment.
Most service permissions are now handled by a shared endpoint that
is parameterized with the permission name. Some permissions that
require some additional logic before they can be toggled (like document
upload, which requires setting a contact address) have separate
initial endpoints that redirect to `set_service_permission`.
"Archive", "Suspend" and "Resume" actions are kept as buttons since
they display a confirmation banner (which is a CSRF-protected form)
and they're not easily represented as an On/Off switch.
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 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.
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
Inheriting from `dict` has some unexpected side effects that don’t
happen with plain object. The one we want to avoid right now is that
a dict doesn’t seem to implement `__dict__` in a normal way, which
is required by `werkzeug.utils.cached_property`.
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.
