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
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
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.
We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
value (as in other browsers)
Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
hack[2] used to ensure the top edge of the button is clickable doesn’t
work. We’re seeing this bug[3] affect real users in research.
1. We inhereted our buttons from Digital Marketplace, here is me making
that change in their code: 8df7e2e79e (diff-b1420f7b7a25657d849edf90a70ef541)
2. 24e1906c0d (diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79)
3. https://github.com/alphagov/govuk_elements/issues/545
We pin pointed the problem to a bad loop that was calling the format_phone_number_human_readable 216 for 25 rows, yikes.
This PR fixes that performance problem.
In research we saw developers having difficulty getting back to Notify once they’d
navigated to the documentation.
One way we think this might be alleviated is by keeping Notify open in the same tab,
and having the documentation open in a new tab.
It’s polite to tell users that this is going to happen.
`rel=noopener` stops the site we’re redirecting people to (Github) have script
access to the orginal Notify tab (see https://mathiasbynens.github.io/rel-noopener/ )
original Notify
We have a team who want their (short) web address as the text message
sender. This commit updates the validation of text message senders to
allow `.` as a valid character, which is currently blocking them from
doing this.
We can be fairly confident this works because:
- the team are sending large volumes of messages already with their
existing provider
- we’ve tested it with all combinations of
- both our text message providers
- an Android phone and n iPhone
