The new taxonomy doesn't have a `notify_go_live_incomplete` tag. We
replaced this with `notify_go_live_incomplete_mou` because the only way
users can submit an incomplete request is if they do not agree to the
MOU.
These are the incomplete tags:
- `notify_go_live_incomplete_mou`
- `notify_go_live_incomplete_reply_to`
- `notify_go_live_incomplete_shared_email`
- `notify_go_live_incomplete_templates`
Of those, only the first one is applied automatically.
Requests to go live and email branding requests come through to Zendesk
with tags attached automatically.
With the revised taxonomy some of these tags need to be updated, as
summarised in this spreadsheet.
In addition, `notify_action` tag has to be added in each of those cases.
Old|New
---|---
`notify_request_to_go_live_complete`|`notify_go_live_complete`
`notify_request_to_go_live_incomplete`|`notify_go_live_incomplete`
`notify_action_add_branding`|`notify_branding`
`notify_request_to_go_live_incomplete_mou`|`notify_go_live_incomplete_mou`
`notify_request_to_go_live`|`notify_go_live`
– https://docs.google.com/spreadsheets/d/1o5ATsFsVK8Qpj7x8QvxX-SfEuBZ75028GEySVcdBFYU/edit#gid=0
– https://www.pivotaltracker.com/story/show/169842970
Because it means you often have to cast to string in your application
code just to get your tests passing.
The method being monkey patched is originally defined here: b81aa0f18c/src/werkzeug/routing.py (L1272)
Directly referencing the `ModelList` instances will let us more easily
make choices at the view layer about which kinds of events to show, and
is one less layer of indirection to jump through.
We store our audit history in two ways:
1. A list of versions of a service
2. A list of events to do with API keys
In the future there could be auditing data which we want to display that
is stored in other formats (for example the event table).
This commit adds some objects which wrap around the different types of
auditing data, and expose a consistent interface to them. This
architecture will let us:
- write clean code in the presentation layer to display these events on
a page
- add more types of events in the future by subclassing the `Event` data
type, without having to rewrite anything in the presentation layer
In some cases it’s not appropriate for teams to have GOV.UK branding.
But they all start with it by default, if we can’t make a better guess.
We should be more explicit about this to reduce the number of teams
sending emails with the wrong branding.
All we do via support is ask which organisation they work for and
manually assign their service to it. This commit makes that process self
service.
We think we have all the trusts and clinical commissioning groups
loaded into the database now.
This will make the go live process smoother for these teams.
We want GPs to be able to accept the agreement online. But at the moment
they don’t get automatically assigned to organisations. So we need to
let them enter the agreement accepting journey even if they don’t have
an organisation set up.
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
If we change our mind and decide whether a service should/should not be
counted in the list of live services then we should also drop the cache
which stores the count of how many live services there are.
It looks weird to have two different visual treatments for showing a
navigable hierarchy.
I reckon losing the slash won’t make things less folder like – Windows
for example uses chevrons as foler separators.
This makes it:
- nicer, by having access to sensibly named things like
`Service.trial_mode` instead of `service['restricted']`.
- less likely to write Jinja code like `service.trail_mode`, which would
fail silently if `service` was a dictionary
The data flow of other bits of our application looks like this:
```
API (returns JSON)
⬇
API client (returns a built in type, usually `dict`)
⬇
Model (returns an instance, eg of type `Service`)
⬇
View (returns HTML)
```
The user API client was architected weirdly, in that it returned a model
directly, like this:
```
API (returns JSON)
⬇
API client (returns a model, of type `User`, `InvitedUser`, etc)
⬇
View (returns HTML)
```
This mixing of different layers of the application is bad because it
makes it hard to write model code that doesn’t have circular
dependencies. As our application gets more complicated we will be
relying more on models to manage this complexity, so we should make it
easy, not hard to write them.
It also means that most of our mocking was of the User model, not just
the underlying JSON. So it would have been easy to introduce subtle bugs
to the user model, because it wasn’t being comprehensively tested. A lot
of the changed lines of code in this commit mean changing the tests to
mock only the JSON, which means that the model layer gets implicitly
tested.
For those reasons this commit changes the user API client to return
JSON, not an instance of `User` or other models.
This removes the edit_folder_permission checks from the code, enabling
the folder permissions for all services.
This also fixes folder-related tests to set up appropriate user
permissions.
This should only be merged right after alphagov/notifications-api#2428,
when all other permission stories are done.
At the moment you have to wait for whoever you’ve invited to accept the
invitation before you can go live. Since this check is mainly for the
benefit of the service, not us, we should trust that people’s intentions
are good when they invite someone.
So this commit also checks the invited users when counting how many team
members a service has.
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.
This is the first step of replacing the `domains.yml` file.
In order to replicate the same functionality we get from the
`domains.yml` file and its associated code this commit adds a
`Organisation` model. This model copies a lot of methods from the
`AgreementInfo` class which wrapped the `domains.yml` file.
It factors out some stuff that would otherwise be duplicated between the
`Organisation` and `Service` model, in such a way that could be reused
for making other models in the future.
This commit doesn’t change other parts of the code to make use of this
new model yet – that will come in subsequent commits.
Returns the data calculated by the API. Stored in Redis against a
hardcoded key so that no-one hammering the home page is directly hitting
the database.
Since we're calling `User.has_template_folder_permission` directly
in a few places (notably the `folder_path` template macro), we need
to check that the service has the feature flag enabled first. This is
usually done by the caller, but template macro doesn't have access to
`current_service`. To avoid passing it in each time the macro is called
we're adding a temporary check inside the method itself.
This commit can be reverted completely when we remove the service
feature flag.
Checks if the user has access to the template's parent folder and
either returns the template or a 403 response.
This method should be used instead of calling service_api_client from
the views.
User model is the most natural place for a permission check method,
however this means that we need to pass the full user object to
service model methods and TemplateList instead of user_id.
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.
When filtering by template type we should ignore any templates that
are inside folders user does not have permission for. Otherwise the
parent folder can show up as empty instead of not showing up at
all. This adds check for user_permissions to is_folder_visible on
the service model in admin.
TemplateList gets a list of templates in a current folder separately,
so we need to make sure `service.get_templates` checks for the
appropriate user permission
Putting the permission check in the get_user_template_folders allows
us to replace `all_template_folders` usage with the new method without
having to worry about the temporary service permission flag.
It should be:
- if they have said they are going to send by a certain channel, show
the extra required task(s) for that channel
- if they haven’t said, infer from which templates they have
We have a number of go live requests where people have said they’re
sending text messages, but haven’t changed the text message sender from
the default of `GOVUK` (we ask teams who aren’t central government to do
this). At the moment we don’t prompt them to, because we look at whether
they have text message templates as indicative of whether they’re going
to send text messages.
Now that we explicitly ask for the volumes of text messages they’re
sending we should use this to determine whether or not we prompt them to
change their text message sender because it’s a stronger signal of
intent than what templates they’ve set up.
We have a number of go live requests where people have said they’re
sending email, but haven’t set up a reply-to address. At the moment we
don’t prompt them to, because we look at whether they have email
templates as indicative of whether they’re going to send email.
Now that we explicitly ask for the volumes of email they’re sending we
should use this to determine whether or not we prompt them to set up an
email reply to address because it’s a stronger signal of intent than
what templates they’ve set up.
