Service contact details are needed if the upload document permission is
enabled - this used to be a link but services can now choose to use a
link, email address or phone number. The form to add or change service
contact details now gives these options and validates the data according
to the type of contact details provided.
When validating phone numbers we can't use the existing validation
because we want to allow landlines too, so there is a basic check that
the phone number is the right length and doesn't include certain
characters.
Since we have added a new, 5th permission the existing permissions
should be relabelled so that the five make sense as a coherent set.
We especially want to make sure that:
- the labels work against the checkboxes and against the tick/crosses on
the manage users page (a long time ago this page was layed out
differently so didn’t have space for full labels)
- there is no confusion between usage and reports
This commit also:
- re-adds a line about what all users can see (‘sent messages’) but
continues to omit the additional bullet points about templates and
team members (because we think this is clear enough from reading the
permissions)
- refactors the `Form` subclass so that the content and order of the
permissions only have to be defined once
- brings back the ‘permissions’ legend on the `fieldset`
Our research and prototyping around ‘basic view’ found that:
- a lot of users who send messages rarely or never look at the dashboard
(yet it’s the first page they see when they sign in)
- team managers like the idea of taking away things that users don’t
need in order to make the interface simpler
We’ve disentangled the simpler way of sending messages from being part
of ‘basic view’. This means we can give managers the option of taking
away the dashboard as an independent choice, not something that’s
wrapped up in a separate ‘view’.
I think that this checkbox is a more straightforward proposition than
‘basic view’ ever was (despite all the work we did to explain it and
develop the nested checkbox pattern). In research users would often
explain the feature back to us as being about hiding the dashboard – we
should try to make Notify operate in terms of concepts that come
naturally to people wherever possible.
Sometimes when setting up a service you might have a few very similar
templates, in which only a small amount of content. Or you might even
have a few of services, which are used by different teams but have
similar templates.
Copy and pasting, especially from one service to another, is a pain.
This commit makes it easier by allowing users to copy an existing
template when choosing to add a new one, instead of starting from
scratch.
- name
- email
- phone number
- services
- last login
- failed login attempts if any
The view can be accessed from results of find_users_by_email
logged_in_at added to User serialization on admin frontend as
a part of this work
This included:
- creating a new form SearchUsersByEmailForm with validation
on its search field
- introducing 400 status to the view if the form does not validate
- fixing the POST request data structure in the tests (it was
incorrect before and uncaught due to lack of validation and mocking
the response from the API.
Most people’s names, especially in government are in the format
firstname.lastname@department.gov.uk. This means that you can pretty
reliably guess that their name is ‘Firstname Lastname’.
When users are invited to Notify we know their email address already.
So this commit pre-populates the registration form based on this guess.
This is a nice little detail, but it should also stop the browser
pre-filling the name field with someone’s email address (which I think
happens because the browser assumes a registration form will have an
email field).
This commit adds radio buttons to the ‘basic view’ page. This will let
users choose whether basic view is on or off for their service.
As before, this page will only be linked to if a service already has
basic view, so this commit does not launch the new feature.
We are not consistent about this. We use ‘manage service’ on:
- the page listing all the users
- the request to go live checklist
We use modify service on:
- the page where you edit a team member’s permissions
- the page where you invite a new team member
This commit changes the latter to be consistent with the former.
‘Caseworker’ was a bad name because it:
- suggested that Notify might be expanding into case management
- may or may not map to someone’s actual role, in a confusing way (this
is why ‘manager’ is also a bad name)
‘Basic view’ is the best name we could come up with because:
- it describes the purpose of feature, not the user
- a ‘view’ changes what you can _see_ as much as it changes what you can
do
Admin remains a good word – in research users self-describe their use
of Notify in using it. This commit makes the name ‘admin view’ to match
‘basic view’.
This also means we can hide the legend for this fieldset because the
choices are self-explanatory.
This commit changes the form that the user sees when inviting or editing
another user, if the service has the ‘caseworking’ permission set.
This will allow creating a new type of user, one who only has the
`send_messages` permission, without the `view_activity` permission.
We are doing this because we think there are a number of services with a
lot of users who don’t need to see the dashboard, or the other team
members, and that we can make a simpler interface for these users.
There are three parts to a ‘user’ form:
- the email address
- the permissions
- the auth type setting
This commit breaks them up into abstract classes so that they can be
composed more flexibly in future commits.
We’ve had a user who’s said:
> Seems configured callbacks cannot be removed once they’re set as the
> fields have a presence check. Is that intentional?
This means it’s not working as they expect. Rather than have to go and
change stuff in the database for them, let’s make it work as they’d
expect.
Only lets you clear the form if you remove both the token and the URL.
Added a page which lets users with the 'manage_service' permission change the
contact link for their service. There are no links to this page yet
since only services using document download will need to set a contact
link.
At the moment branding is an undocumented feature. We get a bunch of
support tickets from teams asking its possible.
This commit:
- lets people know it’s possible, and what the options are
- is the first step towards making this process as self-service as
possible
In some cases we will be able to infer a user’s organisation from there
email address, and Google image search their logo. So the experience for
them is that they press a button and government just sorts it out for
you (also known as "the dream").
In other cases we will have to get back to people asking for a copy of
their logo, or to find out about their service, but this is what we have
to do at the moment anyway.
If we know the code won’t pass the validation on the API side, we might
as well tell the user before even passing it to the API.
So this commit:
- adds some more validators to the field
- rewrites the validation function on the form to actually call the
field-level validators before hitting the API 🤦♂️
- refactors the tests to be parametrize, which means they can be
shorter, easier to read, and more comprehensive
we reckon users will like to see gov reply-to email addresses because
it will improve their confidence in the email.
however, some services, for a few complex reasons, don't want a gov
reply to address. rather than add their specific domains to the
whitelist for signups etc, just make reply tos allowed from any domain.
We vet reply-tos before services go live anyway.
We strip most whitespace as of:
https://github.com/alphagov/notifications-admin/pull/1701
However we are still getting some bad email addresses through, for
example one that had a leading zero-width space character. This means
that the user sees a validation error; really we should just deal with
the mess for them.
So this commit also includes characters without Unicode character
property "WSpace=Y" (which includes zero-width space) to those which are
stripped from form submissions.
List taken from here: https://en.wikipedia.org/wiki/Whitespace_character
See issue and discussion here: https://bugs.python.org/issue13391
If you have a placeholder called `((phone number))` in your email
template, and you try to send a one-off message then the form input will
attempt to validate your ‘phone number’.
This is not helpful if you’re trying to put a landline number in your
email, for example.
This only affects messages being sent through the one-off interface.
This commit makes the form be aware of template type, which fixes the
problem.
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.
Having SMS senders that start with 00 can cause issues with Firetext due
to Firetext's validation rules, so we shouldn't allow SMS senders to start
with 00.
Firetext treats a double 00 at the start of the senderID as an international
prefix, so removes them. A sender of 00447876574016 would become 447876574016.
Under Firetext's validation rules, an SMS sender of five 0s (00000) would
become 4400. This is because the first 00 are removed (as the international
prefix). The third 0 is seen as the start of a phone number, and becomes 44,
leaving the final 00 = 4400.
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
previously we were just using the wtforms builtin email validator,
which is much more relaxed than our own one. It'd catch bad emails when
POSTing to the API, resulting in an ugly error message. It's easy work
to make sure we validate email addresses as soon as they're entered.
