If the templates page contains text messages and emails then there’s two ways it
could be structured:
- into two sections, all text messages first, then all emails
- emails and text messages interleaved, sorted by date
I think the second one is better. Imagine a situation where you mostly do emails
but have a few text messages. You’d have to scroll past the text messages to get
to your emails. Every time.
I reckon that the most commonly accessed templates will be the most recent ones.
- initial versions kept it out of this class but updated as lots of duplication and errors as config
set up in multiple places and not all picking up credstash.
This commit’s parent introduces a Node-based way of managing front end assets.
Nothing else is needed in the app, specifically not Flask Assets. Flask itself
automatically routes requests for `domain.tld/static/*` to the files in
`app/static`.
This also removes all the Ruby stuff.
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
As a first guess placeholders can be added to messages with the
`((placeholder))` syntax.
This commit adds a Jinja template filter to convert strings containing
said-formatted strings into HTML, which can then be styled to highlight which
parts will be substituted in messages.
Main thing that was missing was including the main CSS file in the template.
There are a few hacky bits here, like moving the whole of toolkit inside the
stylesheets directory.
Would arguably be cleaner using something that isn’t Flask Assets, but that’s
something for later.
When a person registers with a valid mobile number and email address,
a code will be sent to each. That person can enter the verify codes and continue to the add-service page.
The post register endpoint will send a random 5 digit code via sms and another via email.
If either code fails to send, the user will not be created and the person can register again.
The codes are saved to the session cookie, and expire in 1 hour.
Another iteration of this story will save the codes to a database.
