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 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.
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`).
Letters is now a mature enough feature that we should:
- be raising awareness amongst our users that it’s a thing we offer
- not have letters be a surprise to anyone creating a Notify account for
the first time
Shouldn’t be merged until:
- [ ] https://github.com/alphagov/notifications-api/pull/1600
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.
One of the things that came out of the support analysis was that people
were asking how much inbound SMS costs. There wasn’t a significant
volume of these requests, but the fix seems low-effort and
non-disruptive enough that we should do it.
Content by Thom.
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.
Spreadsheets start at row 1 (the header row), and the values don’t start
until row 2. The row numbers in our URLs start at 0, which is a concept
that only makes sense to programmers.
It’s more predictable and consistent to make the number in the URL match
the row number displayed on the page when previewing the spreadsheet.
We’ve heard from some users, especially those sending letters, that
they’d like to check that a spreadsheet they’ve uploaded has populated
the template correctly.
My reckon is that seeing just one row of the spreadsheet populate the
template isn’t enough to give people confidence that everything’s
working properly.
This commit adds links to all but the currently-previewed row. Clicking
that link will populate the preview with values from that row. These
pages already exist; they were created in this PR:
https://github.com/alphagov/notifications-admin/pull/1696
VCAP_SERVICES is not set on PaaS if no services are bound to the
application, so we need to check for VCAP_APPLICATION to parse the
application name and environment.
We're no longer using user-provided services for application secrets
so we can remove the cloudfoundry_config code responsible for parsing
VCAP_SERVICES.
flake8-print is a flake8 plugin that checks for `print()` statements in
Python files.
This should save us having to manually spot these when reviewing pull
requests.
The `--enable=T` flag needs to be set until this bug is fixed:
https://github.com/JBKahn/flake8-print/issues/27
When we’re doing user research we often:
- start the task by inviting the participant to a service on Notify
- have them use a prototype version of the admin app, hosted on a
different domain
Currently we can’t do both of these things together, because the invite
emails always send people to notifications.service.gov.uk (because it’s
the API that sends the emails, and the prototype admin app points at the
production API).
This commit changes the admin app to tell the API which host to use when
creating the invite links.
Depends on:
- [ ] https://github.com/alphagov/notifications-api/pull/1515
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
Email addresses in invites should be case insensitive. This is to stop
the bug where a user creates their account using a lower case email
address (e.g. user1@gov.uk), but is then invited to a service using
their email address in a different case (e.g. USER1.gov.uk) and sees
an error message telling them that they can't accept an invite for a
different email address.
