This question was designed to make people feel like it was OK to submit
their request without getting the MoU signed. We reckoned that this was
the fastest way of getting their service live (because the MoU is the
bit that’s most likely to slow them down).
We now have a better way of telling people:
- if they’ve signed the MoU already
- or to contact us if they haven’t (which is what the majority of teams
seem to do now)
We were never actually using the answer to this question – we were still
checking for every service whether they had it signed.
So this commit removes this now-redundant question.
We were counting users who had the `manage_settings` permission. This
is the old name for it, therefore there would never be any users with
this permission, so the tick would never go green.
The new name for the permission is `manage_service`. This commit fixes
the error, and adds an extra safeguard against something like this
happening again.
This makes it easier to write a good message in the request to go live
submission. And encapsulating it in the `GovernmentDomain` class keeps
the view nice and clean.
When we process a go live request it’s a pain to have to go fishing in
the Google Drive to see if there’s a signed agreement in there. This
should make it easier when we know there’s already an agreement.
we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
platform_admin is a separate concept to permissions, so by removing the
checks for it from the current_user.has_permissions function, we can
simplify things greatly. We already record on the user whether they're
a platform admin anyway.
The free allowance affect the number of free text messages a services get per yer.
This allowance is being set properly when an organisation is created by not updated.
This PR updates the free allowance when the organisation type is updated.
The free allowance can also be changed if service has an exceptional free allowance.
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
We require that a user has a real reply-to email address before going
live. We can partially automate this by at least telling users who
haven’t done this.
This only applies for users that have email templates; we shouldn’t
bother users who aren’t going to send emails about this.
We need users to have created some templates before they go live, so we
can see what kind of messages they intend to send.
We can do this automatically based on the work done in
https://github.com/alphagov/notifications-admin/pull/1892
One of the things that we want to check before a service goes live is
that they have at least two team members with the manage service
permission. Anyone who can make a request to go live has this
permission, so that means one additional user is needed. This is what we
can automatically communicate to the user.
Under the hood this makes use of the logic added in
https://github.com/alphagov/notifications-admin/pull/1891
A lot of users aren’t reading or paying attention to the checklist on
the request to go live page. We think that we can get more people to
read it by putting it on its own page, where users won’t jump straight
to filling in the form.
This will, later on, let us make this page smarter by automatically
detecting if they’ve done the necessary things.
Notifications-api now needs the service_id to check the uniqueness of
the service name when trying to change it. This is to allow a user to
successfully change the pluralization or the case of their service name.
Users can choose whether to have these features on or off now. And
a platform admin can still use the same controls to switch the features
on or off on behalf of a user. There’s no need for the separate buttons.
Our support ticket analysis shows that the most common action request
after going live is turning on letters.
We just do this for any team that requests it – there’s no gatekeeping.
So we should just allow people to make the change themselves.
This will be a better experience for our users, and less work for us.
The design of the page replicates roughly what we have for international
text messaging.
When we first made this form you couldn’t send one off messages with
Notify. It’s interesting to us because it might help identity teams who
would benefit from email auth, or other features that we build in the
future for caseworkers.
Email auth is a new feature that currently we’ve only given to teams
who have contact us with a problem.
At the moment, we’re aware of all the teams that are sharing phone
numbers when they sign in. We think that in the future there will be
other teams who encounter this problem. So we should let them know that
they should contact us if they are having the problem.
At the moment we want to talk to teams before giving them access to the
feature, so that we’re confident it’s only going to teams from whom it’s
more secure than using a text message code.
`prefix_sms_with_service_name` is a computed attribute on the service
model. It’s where we get the value from, and the API does some work to
get it from the database, or derive it from the default SMS sender.
It can’t be updated, because it’s not itself a database column.
`prefix_sms` is the name of the actual database column. This is the
thing that we need to update.
This will go away eventually.
We’re extracting this from being determined based on what the sender
name is to its own setting.
This commit will let users set it independently.
Until the explicitly set it, it will still be determined based on
whether their default sender name matches the default for the platform.
