Validate each document tab form separately [WHIT-3214]

[eYinka]

What

Move the edition validation off of the edition model on to the configurable form object, and validate each form independently. Make sure that all forms are validated before the edition can be published.

In the scope of this implementation:

• Errors for the form are rendered to the user at the top of the page and next to the invalid form field, with a link from the top of the page to the invalid form
• Any edition tab’s form can be saved regardless of the validity of the other tabs
• All edition forms are validated before the “Publish” button is displayed to the user, and any errors are displayed to the user on the summary page.
• Only a globally valid edition is updated in Publishing API
• Users can see a hint text letting them know draft previews may be out of date if an edition has invalid tabs

Why

• Accelerates future development of configurable document types with a more appropriate abstraction
• Decouples form validation and attributes from the Edition model

Visual Changes

Testing

Experiencing the full benefit of this work is tricky, because you will almost never have a saved multi-tab edition in bad state unless you manually manipulate the data.
Currently, the only way to access dynamic tabs is by saving the document tab first, which means the draft is fully valid before any subsequent updates can be made. Therefore, it's not inherently clear that we are scoping validations per tab.

For anyone that wants to give it a go locally, an easy way is to configure a document type (like topical event) with "send_change_history": true, then:

• Redraft a published topical event - this should surface the change history form on the document tab.
• Without filling the change history form, try to save another tab (i.e Social media links) with invalid data. You should only see errors related to social media tab and nothing about the invalid change history should be displayed. Also you will be able to see a summary of the invalid tabs on the edition summary page.
• Alternatively, you can grab a draft edition and manipulate the data by doing the following:

# Grab the edition
edition = Edition.find(INSERT_EDITION_ID)

# Manipulate the block content by setting the body to nil and storing an invalid social media link
new_content = edition.translation[:block_content].merge("body" => nil, "social_media_links" => [{ "url" => nil, "social_media_service_name" => "Facebook" }])

# Persist the data
edition.translation.update_column(:block_content, new_content)

Future Improvements:

• When all document types have been migrated to using config-driven tab forms, we should be able to remove validate_block_content and scoped_block_content from has_block_content.rb.
  TabForm will then be the single point for handling all block_content validation. For now, it's fine to keep the validation in both places because not all tabs are currently fully config-driven, and edition.valid? is called in several places that don't go through TabForm.
• Add title and summary to the documents schema of all config driven document types
• In the spirit of maintaining consistency, enforce adding a label to each form in document type configurations.
• Maintain a single way to access the documents tab. Currently, it is accessible via /standard-editions/:id/edit and /standard-editions/:id/edit?current_tab=documents. The latter is necessary for validating only the documents tab while the former will assume full edition validation.

JIRA

---

⚠️ 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.