Spike multi-page architecture

[ChrisBAshton]

TODO:

• Publish all draft child documents when publishing parent doc.

  • NB, we ONLY want publish child editions FROM THE PARENT EDITION. Don't allow independent publishing.

• When creating new edition of parent (and its children), duplicate the EditionRelationships accordingly.

• Currently, org associations are copied from parent to child when parent is updated. We need to also copy from parent to child on child instantiation.

• Hide 'about' page from http://whitehall-admin.dev.gov.uk/government/admin/standard-editions/choose_type?group=all

• Surface child page validation errors on parent page (maybe? But think perf issues if we're calling valid?(:publish) on a doc with >10 child pages). We at least need to do this when publishing.

• Add callback to re-present parent page if child doc is updated (even just draft updates, so the draft preview of parent page will be updated)

• Update the PR description below, accordingly.

Context

We need to support multi-page architectures for config-driven documents, in a way that scales for our requirements and in a way that solves the myriad of problems our existing implementations have.

MVP for multi-page architecture:

• A StandardEdition edition can have 0..* child documents.
• Creating a new parent edition draft automatically creates a new draft of its children.
• We should have the data to be able to surface proper 'diffs' between versions of parent documents, including their children. So each parent edition should probably be linked to specific editions of its children - not their document IDs.
• There is one publishing workflow, one set of associations, one changelog (all done via the parent)
• Roughly speaking, this is how HtmlAttachments currently work.

But built flexibly enough to accommodate a future where:

• Allow publishing of child pages in isolation
• We may want to ship independent associations, changelogs and publishing workflows, e.g. be able to freely make a 'major' update to a child document. (In that world, we don't necessarily need to create a new draft of all child editions on parent edition draft creation - just copy the IDs forwards).
• Roughly speaking, this is how Manuals currently work.

What this spike does

• Adds way of expressing child doc relationship in the schemas
• Adds "ChildDocuments" concern which is pulled into StandardEdition
• Sets up EditionRelationships table to power the children and parent_edition attributes in StandardEdition::ChildDocuments
• Adds "Child documents" section to parent edition UI
• Reuses "Choose type" workflow (duplicated) to choose child doc to create
• Reuses "New edition" page - with conditionals - to show UI for creating the child doc, omitting irrelevant sections like Associations/Settings, and adding a confirmation at the top of the form that we are creating a child document associated with a specific parent document.
• Supports creating a child Topical Event About Page (and surfacing this on the parent edition)
• Strips out irrelevant parts of the UI

What it doesn't cover:

• Coordinated publishing (i.e. clicking Publish on parent should also publish its children)
• Coordinated validation (i.e. it should not be possible to publish a parent if any of its children are invalid)
• Edition lifecycles (i.e. creating a new draft of the parent should also create new drafts of its children, and update the EditionRelationships accordingly. But also need to NOT create new editions of children that are already withdrawn etc.)
• Inheriting the organisation associations and change histories of their parents, at publish time.
• Child Edition variances, and how to enforce them:
  • Topical Event About page - 0..1. Fixed slug about, variable title.
  • Corporate Information Pages - 0..n. Fixed types/slugs (like 'About'), and fixed title(?)
  • Manual Sections - 0..*. Reorderable.
• Hiding child pages from other areas of Whitehall (e.g. Search, 'My draft documents')
• Tests

Screenshots

New section for child documents, on parent page:

Choosing child document screen;

Filling in the child document page:

Child document surfaced on the parent page:

Invalid child document making it impossible to publish the parent doc:

Why

We know we'll need to support topical event about pages in the near future. That will be our first foray into multi-page architecture in the config-driven world. This PR is a playground to explore some ideas / complexities to do with that.

---

⚠️ This repo is Continuously Deployed: make sure you follow the guidance ⚠️

This application is owned by the Whitehall Experience team. Please let us know in #govuk-whitehall-experience-tech when you raise any PRs.

Follow these steps if you are doing a Rails upgrade.