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.
Shows a count of how many folders that user can see - this doesn't do
anything smart with parent folder stuff, it's just "how many checkboxes
are ticked on the edit page".
* doesn't show if service has no folders
* doesn't show if service hasn't got folder permissions enabled
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.
We were already invitializing InvitedUser with folder_permissions
(defaulting to None), but this removes the default and adds
folder_permissions to the serialize method. Folder permissions should
now always be returned from api, either as an empty list or a list of
UUIDs.
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.
The `folder_permissions` property has no effect and is not used yet, but
it needs to be added before we add a `folder_permissions` column to the
`InvitedUser` model in notifications-api. This is because we initialize
the InvitedUser class with the response from notifications-api.
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.
We get a bunch of requests to go live where people have told us they're
going to send email but there is no email reply-to address present.
These come from 2 scenarios:
1. when there are email templates, and no reply to address – but they
ignore the checklist
2. when there are no email templates (yet) but they provide anticipated
volumes for email
At the moment we only auto-check for a reply to address when they have
email templates. And because the question about anticipated volumes
follows the checklist, you'll get a checklist that passes (reply
addresses not required as no templates present) - but your future intent
that differs (reply address IS required because you have anticipated
volumes).
So let’s bring the request for anticipated volumes into the checklist,
that way we can dynamically add the requirement for a reply to address
if they say they will send email but don't have templates yet.
We should begin storing it in the database against the service to stop
people having to re-enter it each time they try to complete the go live
screens.
This also means moving the ‘consent to research question’ along with
the questions about volume, because
- we want people to answer both before going live
- we don’t want to clutter up the summary page by asking questions there
too
Currently when you load the ‘edit user’ page (which has a URL like
`/service/<service_id>/users/<user_id>`) we check that:
- you belong to the service represented by `service_id`
- you have permission to edit users on this service
We don’t check that:
- the user represented by `user_id` belongs to this service
This means that if you could somehow determine another user’s `user_id`
(which I don’t think is possible if you don’t already have the manage
service permission for that service) then you could:
- edit their permissions on your service (weird, but wouldn’t have any
effect)
- change their email address (bad)
This commit adds checks to return a `404` any time you’re looking at a
service and trying to do stuff to a user who doesn’t belong to that
service.
We can’t add this check to the API easily because there are still times
that we want to get/modify users outside the context of a service (eg
platform admin pages, or users who have no services).
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.
Sometimes, when filtering the view by template type, the message was
saying the folder was empty, when really it should have been saying that
there were no templates of the ‘type’ you’re looking for, eg:
> There are no email templates in this folder
This was because it was looking at the filtered list of templates, not
all templates to determine whether a folder was really empty.
It’s a bit rudimentary to only show the current place in the hierarchy
and the parent. You lose a sense of how deep you are.
But we can’t just show the full path, because it can be arbitrarily
long. So what this commit does is show the full path, but truncates the
display of any items. Further-up than the current folder or its parent.
This also helps disambiguate between folders and templates, because
folders are always shown with the folder icon.
This probably won’t affect many teams, because we don’t anticipate a lot
of deep nesting.
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.
