First click-through of the parents' clinic booking journey#223
First click-through of the parents' clinic booking journey#223
Conversation
|
Once you’re happy with the clinic booking flow, you can pop a link to it on the prototype homepage. |
|
|
||
| export const bookIntoClinicController = { | ||
| // Load the preset into locals | ||
| read(request, response, next, session_preset_slug) { |
There was a problem hiding this comment.
Worth taking a look at
manage-vaccinations-in-schools-prototype/app/controllers/parent.js
Lines 20 to 28 in fbfbd2a
Setting the serviceName and assetsName means you can give this parent facing flow it’s own name, use the standard (narrower) page width, and not show SAIS-facing navigation.
There was a problem hiding this comment.
Ah, thanks. Hadn't got to that, but was wondering why I had the SAIS team's navigation in the header.
There was a problem hiding this comment.
@paulrobertlloyd does the service name need to be non-localised?
There was a problem hiding this comment.
It could be, but so far this service name is not used in many other places.
| {{ checkboxes({ | ||
| fieldset: { | ||
| legend: { | ||
| text: __("clinicBooking.vaccinationChoice.vaccinations.label", firstName) |
There was a problem hiding this comment.
Perhaps add size: "m" to increase the prominence of this legend on the page
app/locales/en.js
Outdated
| hits: { | ||
| label: 'Choose one of the following:' | ||
| }, | ||
| tryAgain: 'None of these - try another town, city, or postcode' |
There was a problem hiding this comment.
| tryAgain: 'None of these - try another town, city, or postcode' | |
| tryAgain: 'None of these – try another town, city, or postcode' |
There was a problem hiding this comment.
Is that an em dash replacing a hyphen? Hard to tell in a monospace font.
Each booking, which will have a unique booking reference number, has one or more appointments. This corresponds to one or more children being booked into a clinic by the same parent and in the same booking flow. Models are not yet hooked up to anything.
Various aspects of the appointments could still be improved (e.g. choice of programmes), but some of it is limited by the lack of clinic session details in the models (e.g. start and end times, slot lengths, etc.)
Squash this commit. As it stands, data file generation fails with a circular reference. This is because I made the mistake of composing the objects I was creating in a hierarchy rather than using IDs as foreign keys. I'll fix that in the next commit.
In short, npm run create-data now runs without encountering infinite loops. Replaced aggregation of actual model objects with use of object IDs and getters to return the actual objects. Also in this commit, have improved the logic for matching children's ages to the clinic's programme(s) and choosing non-surprising parental relationships (albeit without attempting to make siblings have the same last name).
This replaces the previous use of Other to indicate foster carer status.
This is jsut based on the Move class/controller, so nothing major yet. Plus, I've commented out the Update method for now. Not sure yet whether I need to do the clinic appointments too. Suspect I will, of course, but need to get more comfortable with relative routes first.
Nothing more than a call to inspect on the response.locals
To be honest, not sure we should be using faker calls in the model or that we even need to pass the booking reference as a parameter to the constructor, but that tidy up can come later, if at all.
Previously, any pages trying to list the full set of records of a given type would most likely fall over when attempting to stringify the json, as no context was found in the array itself.
Out-by-one error.
Dummy view only at this point, dumping the JSON to the page.
Yes, it's only hard-coded, but it's needed for a research session.
One link per primary programme (aka session preset).
This commit is the start of work to support iteration through multiple children (or appointments) in the parents' clinic booking journey. It will allow us to map out the full wizard journey but still needs to be supported by dynamic generation of the appointment journey pages for each of the appointments we create (as well as dynamic generation of the health question pages for each of those appointments).
This commit moves the Parent object to the ClinicBooking, removing it from the ClinicAppointment (but adding parental relationship properties to the appointment). This should simplify various areas, removing the need to propagate contact details to multiple appointments in the same booking. The changes here required changes to the generation of fake data too and triggered a bit of fixing.
This isn't the best solution, but is only intended as a quick way to address the need for parental responsibility. See the comment in parental-responsibility.njk for a better proposed solution.
The dates are still hard-coded, but at least make sense now (copy-paste error spotted by a parent in a research call).
Still need to do the same for the health questions, but there are other missing pieces of the puzzle to address before I can get that working.
As requested in PR #223
This means swapping individual checkbox values for a Boolean or taking _checked out of arrays where there are multiple checkboxes - in both the booking and appointment models.
…nic booking Prior to this, the health questions presented were: - a hard-coded set of questions - shown for only one appointment - not attributed to a specific child
…le multiple vaccines
…next child Changes in this commit include: - confirmation button text of "Continue to next child" when entering the final detail of the previous child - change of title to mention "your next child" when entering chiuld details for 2nd and subsequent children Also got rid of some old, unused entries in en.js.
Apostrophes, curly quotes and em dashes in the clinic booking strings.
Start page and final confirmation page have XL-sized main headings, so the subheadings are accordingly L-sized. Elsewhere, it's L-size at the top level.
The heading text and the caption vary based on number of children and the number of the current child. The previous code worked fine locally, but initially had both of those values still set to zero on Heroku resulting in being asked for the "next child" on the first time through. As I couldn't quickly work out why the values weren't making it through (logging showed they always were coming through, on localhost), I've changed the logic slightly to avoid obviously wrong text in the page title.
Prior to this, values being set on response.locals in readForm (where the values were taken from the models on the wizard context) weren't coming through until one page later than expected. At least, not on heroku; it was fine on localhost. It seems the session data wasn't being fully flushed to the store on heroku before the next HTTP GET came through, so now I'm not performing the redirect until the session data has been fully saved.
Specifically, if we can't find any clinic sessions whose session presets match the clinic booking we've created, don't try to make any appointments in that booking (as the appointments would need a suitable session ID to hook up to).
Co-authored-by: Paul Robert Lloyd <me+git@paulrobertlloyd.com>
Parents' booking journey is in the
/book-into-a-clinicroute. Other, earlier routes/clinic-bookingand/clinic-appointmentwill likely be dropped in favour of that but are kept for reference for now.Note: various aspects are currently hard-coded, including:
Some of these things are part-coded, but need debugging.
Next steps planned:
getAppointmentQuestionPaths(booking_uuid, data.wizard)