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
I personally think it’s more robust to have a test also cover the
counter-fact.
And it’s easy to understand what’s going on if you can see the valid and
invalid examples side by side.
Using a separate validator class to check for appropriate characters in
a text message sender means that we’re not doing this validation in a
different way from the other checks (length and required). So the code
is cleaner.
It’s confusing showing green ticks for cancelled invites. This commit
changes the appearance so that only pending or active users (ie those
that could actually do some damage) get green ticks.
Also fixes missing edit links caused by instances of `User` having
`.state` but instances of `InvitedUser` having `.status`.
Right now these are two separate lists. Which makes it harder to add
improvements that will make large numbers of users easier to manage.
Another thing we did for templates, when they started to get
unmanageable, was add a find-as-you type search. We’ve observed real
users interacting with this to great effect, so I think it makes sense
for users too.
Like for templates, it only shows up when there are more than 7, so that
it’s not clutter for teams who don’t have a lot of members.
Some teams have a lot of users now (I think the record is 172). So we
should make it easier for teams to manage large numbers of users.
This is the same change we made for templates (from most recent to
alphabetical) when the number of templates was getting unmanageable.
Sorted on email address because invited users don’t have a name (and
not sorted on both, because a lot of departments have a
`lastname.firstname` scheme for email addresses, but people generally
enter their names as `Firstname Lastname`).
