Modify a change note in Publishing API, Content Publisher or Whitehall
Spelling mistakes can creep into change notes, and we are often asked to correct them. The instructions below cover doing this task in Whitehall, Content Publisher and Publishing API.
Whitehall
Whitehall supports modifying change notes directly from the UI. The feature is hidden from publishers, but available to anyone with GDS Admin
permissions.
Content 2nd Line can modify the change note themselves by:
- Appending
/change_notes
to the URL of the admin screen, so that the URL looks something like:https://whitehall-admin.publishing.service.gov.uk/government/admin/editions/<edition-id>/change_notes
- You may need to swap out the portion after
/admin/
, for the wordeditions
. For example,https://whitehall-admin.publishing.service.gov.uk/government/admin/publications/1389309/change_notes
won’t work, buthttps://whitehall-admin.publishing.service.gov.uk/government/admin/editions/1389309/change_notes
will.
Note that adding a change note is not supported in the UI. Instead, you’d need to use the app console and do something like:
ed = Edition.where(id: <relevant id>).first
ed.state = "draft"
ed.save
ed.update(minor_change: false, change_note: "Change note", major_change_published_at: Time.new(2022,12,21))
ed.save
ed.state = "published"
ed.save
Content Publisher
Content Publisher has a set of rake tasks for adding, deleting and editing change notes.
Publishing API
Updating change notes in Publishing API is rarely adviseable and should ONLY be done if unable to do so from the corresponding publishing app. This is to mitigate the risk of Publishing API being overwritten by the publishing app later on. Thoroughly explore your publishing app first, to see if such functionality exists (we’ve documented Whitehall and Content Publisher above), and if it doesn’t, consider building the feature in! However, in an emergency, you can edit the changenote directly in Publishing API.
Connect to the Publishing API console:
govuk-connect app-console -e production publishing_api/publishing-api
Find the document:
document = Document.find_by_content_id("YOUR_CONTENT_ID_HERE")
Find the document’s live edition:
live_edition = document.editions.live.last
Check the edition’s details hash for the change history:
live_edition.details[:change_history]
If this is empty, you’ll need to follow method 1. Otherwise, follow method 2.
Method 1 (update an individual ChangeNote)
Fetch the change notes for the document:
change_notes = ChangeNote.joins(:edition).where(editions: { document: document }).order(:public_timestamp)
Select the relevant change note manually, or by searching for the note text:
change_note = change_notes.find_by("note LIKE ?", "%SUBSTRING OR FULL CHANGE NOTE TEXT%")
Update change note:
change_note.update(note, "NEW NOTE")
Finally, [send the document downstream] using the content id.
Method 2 update the details.change_history
Fetch details for edition:
details = live_edition.details
Ouput change history:
details[:change_history]
Select relevant change note manually, or by seaching for the note text:
change_note_index = details[:change_history].find_index { |change_note| change_note[:note] =~ /SUBSTRING OR FULL CHANGE NOTE TEXT/ }
Check the returned change note is correct:
details[:change_history][change_note_index]
Update change note:
details[:change_history][change_note_index][:note] = "New note"
Update edition:
live_edition.update(details: details)
Finally, send the document downstream using the content id.
Troubleshooting
The steps below helped us in a situation where the change note was present in the content item
in both Whitehall and publishing-api, but was not being reflected on the page itself. We
found this was due to the content-store not being in sync with the publishing-api. This can
happen in staging
due to an issue with the overnight data sync.
Things we tried:
- purge the page from cache
- check the Sidekiq monitoring queue to see if the document is stuck somewhere in a queue
- look in Kibana - there might be some with the status
409
which might be due to the content-store thinking it’s got more up to date data than the publishing-api - compare the
payload_version
in publishing-api and content-store in the console, if the request from publishing-api is lower it will be ignored (also see this doc on publishing-api messages)