Skip to main content
Last updated: 6 Aug 2024

publisher: Homepage

Popular links are the links that are present on GOV.UK under 'Popular on GOV.UK'. These links are maintained through this Mainstream Publisher app.

Popular links can be accessed and edited via the 'Homepage' link on Signon, for this we need the 'homepage_editor' permission inside the Mainstream Publisher app.

More context on homepage permissions

Signon by nature expects each link on the dashboard to link to a separate app, whereas the popular links editor lives inside the Mainstream Publisher app. The Homepage link on signon integration was generated by running the below command in signon kubernetes (refer to the signon usage documentation for details).

rake applications:create name=Homepage description="Responsible for creating contents for homepage" \
     home_uri="https://publisher.integration.publishing.service.gov.uk/homepage/popular-links" \
     redirect_uri="https://publisher.integration.publishing.service.gov.uk/homepage/popular-links/auth/gds/callback"

We do not store the secrets generated by this command and just rely on the secrets already configured for Mainstream publisher. This makes Homepage appear as an app in signon, but it's really just a link to a page in Mainstream Publisher. This also means all the permissions related to the Homepage "app" can only be managed through Mainstream publisher. Hence, in order to get access to the Homepage "app" we need the homepage_editor permission for the user in Mainstream Publisher.

Questions

Why is this being added directly to the Signon landing page?

The functionality itself will sit within Mainstream Publisher. However, we’ve made the decision to take an experimental approach and show the Homepage link within the main signon page. We’ve decided to trial this as we believe that users should simply be able to select what action they want to perform, rather than having to understand what app they need to use to accomplish a task. There are some challenges to this approach as it differs to the way we normally approach the navigation within our apps, but the homepage edit permission will be limited to a small group of users, so we feel it’s a low risk way to learn more about this approach through user testing.

link_collection

Currently our use case is only to allow publishing of popular links and not any other content on the homepage, though in the future we might want to allow other content on the homepage to be published via Mainstream Publisher. Implementation-wise, we have investigated and understood how to allow publishing of popular link as a separate content item and link it to the homepage, and we think it is a simple approach to take at this point in time. If we want to allow other content items on the homepage to be publishable we can still create each of them as a separate content item and publish them separately, or move to a strategy of publishing homepage as a single content item. Though this strategy will require us to investigate more on how that can be done and understand the complexity and feasibility of it.

There are a few reasons why we chose to keep it synchronous: a. Allows us to give user real-time feedback in case of Publishing API failures. b. Allows us to handle and rescue Publishing API errors in desired ways. eg: handle a 'Cannot publish already published' error to give the user appropriate feedback. c. Unlike other editions which store their content-id in Artefact, popular links stores its content-id in PopularLinksEdition. This means that publish_service.rb (which is used to publish all editions) can't be used as-is to publish popular links because it reads edition's content-id from its artefact, which basically means we would have to introduce some logic to understand if the edition is a PopularLinksEdition or some other edition type, and based on that read content-id from the edition's artefact or from the PopularLinksEdition itself.

Worth Reading

PR with details of the schema changes made for popular links inside Publishing API.