Templates now have:
- a type (email or sms)
- a subject (if they are email templates)
We don’t want two completely separate view files for email and SMS, because they
would have an enormous amount of repetition.
So this commit adds
- different templates for SMS and email templates
- different form objects for SMS and email templates
…and wires them up.
This takes the original prototype version of this page, and, using the same
fake data (ie nothing is wired up):
- adds an invite users page
- adds an edit (and delete) user page
Both these pages allow the user to set another user’s permissions.
This commit adds images for the ticks and crosses, so we have control over their
appearance.
Since placeholders (almost) work now, it’s worth telling people what the syntax
is.
This commit also removes the ‘template type’ picker, since you can only create
SMS templates at the moment. This will be revisited when we start looking at how
you add an email template.
This commit extends the existing function to validate each row’s phone number
to also validate that all the required data is present.
It does this using the checking that the `Template` class can do when given
a template and a `dict` of values.
These give devices a hint (although don’t mandate them) to use a numeric keypad,
or a keypad with the `@` symbol visible when entering phone numbers or email
addresses.
Based on discussion with Pete.
Make the blue banner an ‘important’ banner (copied from Register to Vote, used
because it’s not as boxy and fits on the page better).
Remove the back button because you haven’t changed any data yet. If you need to
go back you can just press back or start again.
Make the filename stand out more.
Remove the ‘download example’ link. Will need to revist the best way of doing
this.
Make text messages consistently 2/3rd width.
Because burn your select tags[1]
This commit hard codes the markup for the time being until I can work out how
to get WTForms outputting the markup I want.
1. https://www.youtube.com/watch?v=CUkMCQR4TpY
WTForms sets the `id` of a `textarea` element to the variable name to which the
form control is assigned.
This conflicts with the page container, which is styled by targeting `#content`.
Copying what they’ve done on GOV.UK Pay, we should let users:
- generate as many keys as they want
- only see the key at time of creation
- give keys a name
- revoke any key at any time (this should be a one way operation)
And based on discussions with @minglis and @servingUpAces, the keys should be
used in conjunction with some kind of service ID, which gets encrypted with the
key. In other words the secret itself never gets sent over the wire.
This commit adds the UI (but not the underlying API integration) for doing the
above.
This page is exactly the same as the page for adding your first service, save
the heading text.
So all this commit does is:
- set up two routes (`/add-service`, `/add-service/first`) for each of the two
journeys and change the existing journeys to use the `/add-service/first`
route
- add logic to show different heading text depending on the journey
- add a link to the new (`/add-service`) route in the service chooser dropdown
This commit replaces the previous `StringField` used for collecting mobile
phone numbers with the `UKMobileNumber` field.
This means changing a few of the preexisting tests to have more realistic mobile
numbers so that they still pass.
This commit:
- improves the tests to check for specific error messages, rather than just
pass/fail
- makes the error messages more human, and more suggestive of what the user
needs to do to fix the error
This field does two things:
- validates the format of the phone number
- outputs a consistent representation of the phone number
Because of this I think it’s better represented as a new field type, rather
than individual validators.
I also think that it’s better to do this without regular expression(s), because
it makes returning the specific error easier.
This commit also adds basic pass/fail test for a series of valid/invalid
phone numbers.
This commit adds an extra page or field for confirming your current password
when making important changes
Name | Email address | Mobile number | Password
---------------------|-------------------|-------------------|------------
No password required | As second page | As second page | On same page as new password
This commit adds a page or series of pages for changing your:
Name | Email address | Mobile number | Password
------------------|-------------------|-------------------|------------
Enter new value | Enter new value | Enter new value | Enter new value
| Enter 2fa code | Enter 2fa code |
Return to profile | Return to profile | Return to profile | Return to profile
(each row is a page)
This macro:
- accepts a WTForm form field as a parameter
- renders a form field which follows the GOV.UK Elements patterns, both visually
and in markup terms
It then changes any page which uses either:
- the old, non-WTForms macro or
- the old, WTFforms `render_field` macro
…to use this new macro and removes both of the old ones.
It also adds the option to display hint text above the textbox.
At the moment the file contents are not persisted by checked in
memory.
The first and last three records are show if all are valid.
If there are invalid rows, they are reported and the user is
prompted to go back and sort out upload file.
The storing of upload result (i.e. validation of file) in session
will be removed in next story which is about persisting of file
for later processing.
Refactored the forms so that fields like email_address can be used in multiple forms.
Refactored form validation so that a query function is passed into the form to be run, this
way the form is not exposed to the dao layer and the query is more efficient.
This PR still requires some frontend attention. Will work with Chris to update the templates.
Found a way to create the token that does not need to persist it to the database.
This requires proper error messages, written by people who speak menglis good.
Start implementation for new-password endpoints.
Created PasswordResetToken model
ToDo: create and save token, send valid url to user,
check validity of token, update user's password, redirect to /two-factor.
