store layouts

[dblatcher]

What does this change?

• makes a new data type for Editions Layouts - representing the arrangement of newsletters on https://www.theguardian.com/email-newsletters for the different editions (UK, US, AU, INT, EUR) of the page.
• defines an abstract class for a service to manage the storage of the editions layouts and an 'in memory' implementation using a static set of initial test data
• adds an API route to manage request from the UI to get and update the Editions Layouts from the UI
• adds a new permission to control a user's ability to do updates (only available to "developer).
• builds UI pages to display the layouts and allow user with the permission to edit them (using the existing JsonEditor component - with a view to developing more user-friendly UI later)

How to test

Run locally, with the "developer" permissions set in .env.local (see main readme for setup):
USER_PERMISSIONS={"[email protected]": 0}

go to http://localhost:4200/layouts to see the main UI - you should be able to create and edit layouts

shut down the app, change the user permission level to :
USER_PERMISSIONS={"[email protected]": 3}

run the app again and you go to go to http://localhost:4200/layouts - you should have read-only access

How can we measure success?

This moves towards having the arrangement on the /email-newsletters page controlled from the newsletters tool, rather than requiring PR's in the DCR repo.

subsequent PRs:

• creating an s3 based implementation of the LayoutStorage class to allow the changes to be persisted. Adding the deployment options / config to use that in CODE/PROD builds
• [frontend repo] - read the layout data and cache from the newsletters API, include it in the data posted to DCR
• [dcr repo] - use the layout data from frontend instead of the hard coded copy
• designing a user-friendly layout editor so editorial can self-serve changes
• update which users have permissions to use the new editor

Have we considered potential risks?

Before merging, should modify this branch so it won't result in the new /layouts UI pages being made live with the current config - this can be done by editing apps/newsletters-api/src/register-ui-server.ts

It should be safe to have the newsletters API publish the /layouts routes (with the test data), but we can modify the branch to exclude them if prefered.

Images

Accessibility

• Tested with screen reader
• Navigable with keyboard
• Colour contrast passed
• The change doesn't use only colour to convey meaning