MoJ O2 Transition Project – Ministry of Justice
Academies Financial Reporting Division – Department for Education
Money Claims Service Line – HM Courts & Tribunals Service
HR and Organisational Development – Calderdale Council
Family & Civil Service Line – HM Courts & Tribunals Service
Electronic Patient Discharge Questionnaire – Public Health England
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.
If a PR is going to fail because tests aren’t passing then you:
- should know about it as quick as possible
- shouldn’t waste precious Jenkins CPU running subsequent tests
This commit adds the `-x` flag to pytest, which stops the test run as
soon as one failing test is discovered.
Sometimes you just wanna run some tests directly using the `pytest`
command. But you’re in a new shell, and have forgotten to do
`source environment_test.sh`. The screen fills with red, and your day
just got a little bit worse.
This commit will stop this from ever happening again, by making the
setting environment variables part of running Pytest. It does this with
a plugin called pytest-env[1].
pytest.ini is the standard way of configuring pytest. Creating this file
where it didn’t exist before changes the behaviour of pytest, in that
it will now look for tests in the same directory as the file, rather
than defaulting to the `tests/` directory. So we also have to explicitly
configure pytest[2] to tell it that it should only look in this
directory. Otherwise it gets lost in the weeds of `node_modules`.
1. https://github.com/MobileDynasty/pytest-env
2. https://docs.pytest.org/en/latest/customize.html#confval-testpaths
It’s weird that `/services/<service_id>` returns `404`. The home page
for every service is the dashboard – should be possible to get there
from any other page just by stemming the URL.
Also makes it consistent with organisations, which will have
`/organisations/<org_id>`.
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.
We had a user report that the ‘inbound messages’ part of their dashboard
was appearing for a split second then disappearing.
This was caused by the Javascript on the page throwing an exception as
it was trying to re-render this part of the page. This meant it gave up
and rendered nothing.
The exception was caused by passing `undefined` as the second argument
to `.insertBefore`. This is acceptable in most browsers, but not older
versions of IE. This is fixed in the latest version of diffDOM (the 3rd
party library we use to do the AJAX stuff) by defaulting the second
argument to `.insertBefore` to `null`, which is acceptable in old IE
versions.
See the fix here: 8833d87e9d
We have found repeatedly in research that our users don’t know what
‘beta’ means. In this situation they come up with their own
interpretation of what it means, for example that:
- certain features are not available to them
- Notify as a whole is not available to them
- they are using a ‘different’ version of Notify to those using it for
real
In the most severe cases this ambiguity actively dissuades users from
adopting Notify. We know this from support tickets and user research;
there are probably a host of other teams we haven’t spoken to.
Here’s a quote from a user research session just last week:
> Once we’ve got the facility to receive inbound messages […] that’s not
> available to us at the moment with a beta account
From support tickets:
> We see that the service is still in beta mode – can we assume
> uninterrupted service reliability and performance?
> we do not have a .gov.uk email address any longer but I was wondering
> if we would be able to utilize the notify system which is currently in
> beta
> We are currently using the BETA version, are we able to switch to the
> TEST version so we can add other numbers to send SMS to?
> I have previously enquired about this option [receiving text messages],
> but thought it was still at Beta stage. If we can set it up so that
> notify handles the responses that would be great.
> [after going live] Should I see the wording LIVE on the login screen
> as I still see BETA.,....
> Also I note that you are a BETA service just now and that to use the
> service we would need a .gov.uk email address. We don't have this, is
> there any way that [redacted] could use the service as I note that one
> of the teams have an account?
---
This commit removes the beta badge from Notify, and hopefully with it
the confusion it’s causing our users.
