_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
With the upgrade of pep8 to 1.7.0 module imports are required to be at the top of the file,
meaning I had to add a noqa line to some of the init files. Are those init files wrong or is pep8 too strict.
This commit adds a 3 screen tour, similar to those used on GOV.UK Verify
and Passports.
We guerilla tested this on Friday, and it really helped users to build a
mental model of how Notify works, so that when they’re playing around
with it they have a greater sense of what they’re aiming to do. This
makes concepts like templates and placeholders click more quickly.
https://www.pivotaltracker.com/story/show/116710119
Each service on the list is linked to the dashboard page of the service.
The platform admin user can see/edit templates, see/invite users, see/edit service settings.
The platform admin user can not send messages, see/edit api keys and developer docs.
This commit only deals with acceptance by
users who are already in system.
Changed invite client to return invited user objects
instead of dictionaries.
Added commented out test. fixed up fixtures to return invited user
object for invites
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.
Because a user can have multiple services, they need a way to navigate between
them. Normally they can use the ▶ Switcher to do this, except when:
- they first sign in
- they are on a page which isn’t associated with a service (eg user profile) in
which case we can’t use the switcher because it won’t know what the ‘current’
service is
So this commit adds a new page with a (fake) list of services.
There are now quite a few frontend components in the app.
It’s good to have a reference for them to:
- document for developers what patterns are available and how they are used
- check for regressions
- when working on one variation of a pattern you can check that your changes
don’t break other variations of it
- when changing the arguments to a pattern you can check that this doesn’t
change the expected arguments already in use
This commit adds a single page (`/_styleguide`) which has examples of all the
patterns.
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.
Adds the pages and wires them together, so that it’s possible to click
through them.
The wording is not quite English, but attempts to be an rough description of
what the consequences are for each of the four actions.
- adds a table of recent activity to the job page, which is shared by the
dashboard page
- uses the same filename and message template as the first job shown on the
dashboard
- sets the time of file uploads/message delivery/message sending to always
match ‘just now’
This mocks out a data structure for a job’s messages, and renders this data:
- on the notification page, as a table, which links through to…
- …the page for an indidivual message
This commit:
- replaces links that look like buttons with forms and submit buttons
- splits the view code for SMS into its own file
- moves the routing into the Python by adding handling for `post` requests
- uses Flask’s `url_for` to generate URLs, rather than hard coding them (so that
it’s easier to change the URLs)
- chages the URLs for sending text messages
Includes validation for gov.uk email address, mobile number with +44, password at least 10 char.
Form validation errors will be added to template in a later story.
User is created when form validates.
