Update 27 November: we're aware of a few teething issues arising from the recent change to supporting detail pages, and are working on fixing those as fast as we can. Here's a list of the known issues.
Issues affecting publishing tool users:
- Quick links to find and edit supporting pages are missing from their parent policies in some cases. We're working on a fix right now. Meanwhile, you can still find any supporting page by filtering the document list by type: "supporting pages" and /or keyword...
- ...but not if you're also filtering by your organisation. If you've got an active filter for organisation, then you won't be able to see any supporting pages in the list right now because we haven't set them to be directly associated to an organisation.We're currently working on a fix for this one too. Until that ships, make sure you don't have an active organisation filter when looking up a supporting page.
- Supporting pages with attachments don't have an "alternative format provider" email set. They used to inherit this value from the policy they were part of, but on decoupling them we didn't migrate this info across, which has introduced validation errors. A fix for that is on preview and will ship tomorrow.
Issues affecting end users:
- Change notes for supporting pages don't appear anywhere, and updates to supporting pages aren't captured in any atom feeds or email alerts. We'll work on restoring that in the coming days.
Those are all the issues we know about so if you find anything we've missed here, please raise a support request. Apologies for any frustration we've caused, we do try to keep it to a minimum.
Original post of 20 November follows.
We've made a big change to the way policy detail pages (aka "supporting pages") are created and retrieved for editing. Publishers in ministerial departments will want to read this post closely so they understand how this works now.
Previously, the main overview page for a policy and the additional pages which appeared under under the "detail" tab were treated as a single entity in the publisher. You would create the supporting pages as a part of the policy, and move the whole set of pages through workflow steps (draft, submitted, published) as a single thing.
Now, supporting pages have been split off from policies to become a document type in their own right. You can edition them, submit and publish supporting pages as separate entities from their parent policy pages.
There are a bunch of benefits to you from this change, explained further down in this post.
Where to find stuff now
To create a new supporting page, there's now a link in the "New document" tab:
And to find existing supporting pages in order to edit them, there is now an option in the documents filter:
Remember, supporting pages should correspond to the list of actions on the main policy. You should also make sure the policy is up to date, and refers to all the supporting pages, with inline links to get users straight to them.
Why we changed it
While there was a lot to be said for the concept of the policy as a single entity, there were a number of improvements we needed to make to supporting pages which - taken together - added up to a decision to split the format out as its own thing and re-use all the existing functionality we have for other document formats.
Doing that also has the benefit of simplifying the code to help make future development easier.
The pressing needs that drove us to do this now were:
- the need for inline images on detail pages. You can add these now, where they meet a user need
- the need for supporting pages to have separate entries in the site search
- the need to prevent two editors working on different parts of the same policy from accidentally publishing each other's half-finished work
But there are other benefits that came for free, such as:
- you can now schedule supporting pages to be published at specified future times, and limit access to drafts
- you can now associate supporting pages to more than one parent policy. In other words, you can share a detail page across multiple policies. We expect use of this to be rare
- you can now preview draft supporting pages
- you can now see editing history and add editorial remarks for the supporting pages separately from their parent policies
And it means in future it should be easier to make further changes, such as allowing translations on supporting pages.
Is it better?
We hope you like what we've done here. Feedback at our last show and tell session suggests this will be a welcome change, but as ever we'd love to hear from more users about what you think of this change, both good and bad.
Featured image by B_Zedan