Clinic booking fixes#232
Merged
malross merged 4 commits intoclinic-bookingfrom Mar 25, 2026
Merged
Conversation
This commit also introduces the Child object (without a context) on the ClinicAppointment object, replacing the unmatchedXxxx properties.
paulrobertlloyd
temporarily deployed
to
mavis-protot-clinic-boo-jg5cs4
malross
added a commit
that referenced
this pull request
Mar 26, 2026
* Fix generateClinicAppointment * Move the check answers page before the health questions. * Fix dob decoration in clinic booking * Allow use of a previously entered address in clinic booking This commit also introduces the Child object (without a context) on the ClinicAppointment object, replacing the unmatchedXxxx properties. --------- Co-authored-by: Paul Robert Lloyd <me+git@paulrobertlloyd.com>
malross
added a commit
that referenced
this pull request
Mar 26, 2026
There are still quite a few hard-coded pages in here -- including the check answers page, and the list of vaccines to offer a child (which should be based on a matched patient's vaccs history) -- but it's been enough to do research with. There are also more changes planned for the flow, to make it easier for parents with multiuple children needing to be booked in while not making it confusing for the majority having only one. Full commit message history follows... * Add models for clinic bookings and appointments 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. * Generate fake data for clinic bookings and their appointments 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.) * Data generation functions for clinic bookings and appointments 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. * Improvements to generation of faked clinic bookings 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). * Create fake parents with the Fosterer relationship This replaces the previous use of Other to indicate foster carer status. * Add initial routes and controller for clinic bookings. 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. * Add dump-only views for show and list on clinic bookings Nothing more than a call to inspect on the response.locals * refactor: De-duplicate the clinic booking reference generation 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. * Allow inspect() to remove context from arrays as well as single records 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. * fix: Generate expected number of fake clinic bookings Out-by-one error. * fix: redirect to correct route format after updating a clinic booking * Add clinic appointment faked data, routes and controller Dummy view only at this point, dumping the JSON to the page. * Move parent details for clinic bookings into clinic appointments And make them into full Parent objects, so that we get all of the other properties that I'd missed and can lean on things like summaryRows in the views. * Present details of a single clinic appointment in a new view This doesn't yet include any option to edit the values. I'm just exploring how to get values showing right now. * Show the details for a single clinic booking This is just a first pass at the UI. Styling and spacing need work, and the buttons don't actually go to any sensible routes, but that can come later. * Add the primary programme to a clinic booking and its routes There are other supporting changes in this commit e.g. addition of a slug to the SessionPreset objects, but part of the work in the /start view for book-into-a-clinic is likely to be abandoned; I'd gone too far down the route of copying the consent start page design and not been following my own journey design. I'll fix that. * Create views for early pages in the clinic booking journey There's also a lot of fleshing out of the book-into-a-clinic controller and its routes, though there's still work to do to get the child_index parameter sorted. Either that or I'll drop that part of the route and rely on session data to track it instead. Probably the latter. Note that one particular element that almost certainly won't work in the view right now is the use of array indexing in the inputs' decorate values. I may want to store the current appointment separately somehow and only add it to the booking model when complete and moving onto the next child's appointment. May need a separate route defined for the starting page of the appointment sub-flow, where I can create that object, just as I do for the booking object in the <preset_slug>/new route. * Fix content in the parent's clinic booking journey Prior to this, there were plenty of %s values still appearing in the page, esp. for the child's name. This commit signals a shift in the booking vs. appointment paradigm on the wizard context. I'm now holding 2 models on this wizard context in this journey: one ClinicBooking and one ClinicAppointment. The latter will be built over the course of the appointment-related pages and only when that's complete will it be added to the booking. One thing this gives us is the appointment's UUID, which we can use in the routes rather than a child_index. The logic to get the appointment UUID into the routes will need changing when it comes to looping to the second appointment, but it essentially ignores the wizard journey's paths.next to build the URI of the first appointment step with the appointment_uuid injected. Maybe there's a better way to do this, but I don't know it yet. Accordingly for the changes to the set of models held on the wizard context, we're now also recording form values in req.body.booking or req.body.appointment, with those values being propagated to the relevant model in updateForm. * Add more views to the parents' clinic booking journey Note: this is not a working journey yet, but I'm committing before I end up adding an overwhelming amount in one go. (It's already too much, to be honest.) Changes in this commit: * Addition of clinic-finding and slot-booking views, plus parent detail views and health questions. Health questions not working yet due to selection of vaccines not binding properly (need to investigate correct use of decorate for checkboxes()) * Introduction of a transaction object in the wizard context, for tracking transient journey data that doesn't need to be stored in the model e.g. number of children, location entered for search, etc. This will still need to be keyed to the booking uuid to avoid multi-user conflicts, however. * Various page text fixes, including access to the current child's first name for inclusion in question titles * Tenative change to how parent details are stored, as we really need to store them on the parent object in all appointments, not just one. So there's a parentTel getter/setter pair in ClinicBooking now that I might need to replicate for all relevant properties of the parent; or perhaps just offer a Parent object getter/setter pair and push changes to the ClinicAppointment objects (though what we should get back for parental responsibility is another matter, as that varies by appointment) * Minor: typo fixes and comments around clinc booking Pausing the dynamic health question stuff for now, to focus on hard-coded health questions that can be used for imminent research. * Hard-code health question sequence for clinic booking Still uses the health-question.njk view, but the journey definition is hard-coded rather than using the code to generate the sequence of views. This is for expediency, as I need to hook up the addition of appointments to the booking and sort out the looping and reestablishment of the appointment uuid in the route. * Add hard-coded check answers page for clinic booking This doesn't yet include the health questions, but will probably need to. Some redesign to be done there. * Add confirmation page for clinic booking journey * Use correct heading levels on clinic booking check answers page * Move clinics' health questions to after booking confirmation This is based on a quick review with Ben Weedon and follows the pattern established by the ethnicity questions in the consent parent journey. * Fix the forking for health questions in clinic booking * Caption all appointment pages of the clinic booking journey I've moved away from the somewhat poorly-focused "Child 1 of 2" wording to be clearer that the page is: 1. part of the appointment process 2. for a specific, fully-named child I might yet take use of the child's first name out of other parts of the pages. * Use HPV, not MMR, immune system health question. Yes, it's only hard-coded, but it's needed for a research session. * Fix misplaced HTML in clinic booking's check answers page * Fix all linter issues in clinic booking * Add homepage links for booking into clinic journeys One link per primary programme (aka session preset). * Create all appointment models in advance for clinic bookings 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). * Reorganise the parent details for clinic bookings 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. * Add a parental responsibility block in the clinic booking journey 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. * Fix hard-coded date order in clinic booking The dates are still hard-coded, but at least make sense now (copy-paste error spotted by a parent in a research call). * Hide SAIS team navigation in parent's clinic booking journey * Fix branching around parental responsibility in clinic booking * Fix the branching for contact preferences in clinic booking * Iterate over multiple appointments in clinic booking journey 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. * Increase prominence of vaccine choice heading in clinic booking As requested in PR #223 * Sanitise any _unchecked values coming from the clinic booking process 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. * Fix linter issue with unused class import * Show health questions for chosen vaccines for all appointments in clinic 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 * Clarify the need for 3 doses of the HPV vaccine in contexts that handle multiple vaccines * Clarify the points at which clinic booking subjourneys move onto the 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. * Typography improvements Apostrophes, curly quotes and em dashes in the clinic booking strings. * Consistent heaading sizes in the clinic booking journey 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. * Show correct header on child name page in clinic booking 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. * Format clinic booking references as codes. * Avoid race condition with session storage in clinic booking 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. * Make clinic booking data generation more robust 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). * Fix generateClinicAppointment (#230) Co-authored-by: Paul Robert Lloyd <me+git@paulrobertlloyd.com> * Clinic booking fixes (#232) * Fix generateClinicAppointment * Move the check answers page before the health questions. * Fix dob decoration in clinic booking * Allow use of a previously entered address in clinic booking This commit also introduces the Child object (without a context) on the ClinicAppointment object, replacing the unmatchedXxxx properties. --------- Co-authored-by: Paul Robert Lloyd <me+git@paulrobertlloyd.com> * Fix linter warnings and remove/tidy up TODOs. * Prefer forEach over index-based for loop Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com> * Prefer forEach over index-based for loop Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com> * Don't use abbreviations for variable names Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com> * Use English, not class names, in parameter descriptions. Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com> * Favour the appHeading macro over hard-coded HTML Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com> * Rename createInContext to match repo conventions Also fix errors from suggested changes commited in PR #223 --------- Co-authored-by: Paul Robert Lloyd <me+git@paulrobertlloyd.com> Co-authored-by: Paul Robert Lloyd <paulrobertlloyd@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes to allow parents to reuse the home address entered for earlier children in a multi-child booking.