alphagov / email-alert-frontend

Serves email alert signup pages on GOV.UK

Email alert frontend

A frontend for creating and managing email subscriptions.

Features

Signup

This app provides three routes for signing up to email:

• A /email-signup?link=/:base_path route [example]. This route supports signup to several types of content. It was originally specific to the taxonomy (despite the generic name), and then got re-purposed for other document types.

• A legacy /:base_path/email-signup route [example]. Each of these routes corresponds to a content item with an email_alert_signup schema. At the time of writing, /foreign-travel-advice/* still uses this route.

• A /email/subscriptions/new route [example]. This route enables any other application to offer a fully customised email signup experience that is not reliant on the content store. It is used by apps like finder-frontend, where a new subscriber list is created from the combination of selected filters.

In order to verify the email for a new subscription, we send a verification email using Email Alert API. The email contains a link with a unique token for the subscription. Clicking on the link completes the signup process.

Manage

This allows the user to list, modify and delete their subscriptions [login]. It uses a similar, but separate email/token process to authenticate a user, establishing a session for them to make their changes.

Nomenclature

• Tags and Links - strings that uniquely define a list to subscribe to

Technical documentation

This is a Ruby on Rails app, and should follow our Rails app conventions.

You can use the GOV.UK Docker environment to run the application and its tests with all the necessary dependencies. Follow the usage instructions to get started.

Use GOV.UK Docker to run any commands that follow.

Running the test suite

$ bundle exec rake

Publishing Routes

There are six routes provided by this app: /email-signup, /email-signup/confirm, /email/unsubscribe, /email/subscriptions, /email/authenticate and /email/manage. If you are deploying this app to a new environment, you will need to publish these routes using Special Route Publisher

Testing account pages

Some pages are only accessible once a user has logged-in, using a link sent in an email. To test these pages locally, you will need to make a temporary change to the controller code to bypass authentication. If testing on a deployed branch, see the documentation on receiving emails from in Integration and Staging.

Licence

MIT License

email-alert-frontend's Issues

Dependabot can't resolve your Ruby dependency files

Dependabot can't resolve your Ruby dependencies.

As a result, Dependabot couldn't update any of your dependencies.

This could have been caused by a git reference having been deleted at the source, by an out-of-sync lockfile, or by a bug in Dependabot.

To help diagnose the issue, please try running bundle update --patch locally. If no errors occur, get in touch and we'll help dig into it.

You can mention @dependabot in the comments below to contact the Dependabot team.

Create Heroku app and pipeline to aid UI reviews

Email alert frontend needs a Heroku app representing master and a pipeline for reviewing changes to UI and components.

Missing phase banner CSS

The https://www.gov.uk/email/manage page (and its subpages) uses the phase banner component but it seems as if the styles for this component are missing. Looks as if they were removed a while ago.

Header menu link overlap between desktop and mobile

The links in the header when signed into pages like https://www.gov.uk/email/manage overlap each other, as shown below when the menu is expanded. This seems to happen below the desktop breakpoint (768px) and mobile (640px).

Issue moving through app

There is an issue within this app as it's interacted with using the example page links

Starting
http://email-alert-frontend.dev.gov.uk/email-signup?link=%2Fgovernment%2Forganisations%2Fgovernment-digital-service

As you move through the app the actual URL changes which generates an error page
http://www.dev.gov.uk/email/subscriptions/new?topic_id=government-digital-service

GOV.UK Elements conflicting CSS causing padding issues.

The way GOV.UK Elements styles #content conflicts with our styling with the #wrapper.

This results in too much padding around the page.

Seems like there may be some similar issues with the custom margins on the expanded inputs too. Would recommend keeping the pattern as described in GOV.UK Elements and trying to update the pattern upstream.

Can reproduce when testing on smaller viewports e.g. mobile, tablet

Publishing Frontend Support: https://trello.com/c/SDaspypN/45-gov-uk-elements-conflicting-css-causing-padding-issues

CSS and JS not optimized

What

We should optimize the CSS and JS served directly from Smart Answers, we should do this by:

• Minify CSS
• Minify and "Uglify" JS

Why

We are currently serving larger asset sizes than required to end users, optimizing the CSS and JS should improve performance on the frontend.

Use content_id for breadcrumbs

In the current state, titles and links for breadcrumbs need to be manually created by the publishing App.
This should be refactored to use the links array so we get links and titles being kept up to date.

Cookie overflow problems

We're seeing relatively frequent cookie overflow problems reported in Sentry - we should be sanitising the cookie code so that if these are exploit attempts we just reject them silently, and if they're not we work out what we're doing to cause them.

https://govuk.sentry.io/issues/5082661786/?alert_rule_id=283775&alert_timestamp=1712737444613&alert_type=email&environment=production&notification_uuid=38e5d9c6-2667-4f17-8bdc-42687ee97bef&project=202221&referrer=alert_email

Wrong error message shown when setting frequency of new subscription

When you try to create a new subscription but don't initially select a topic, the wrong error message is shown on the page to select a frequency after you choose a topic. I think this is because of how Rails handles flash messages.

Email Address Present in Query Params

As part of #639, @kevindew identified that we include the user's email address in plaintext form in the query params of the "View, unsubscribe or change the frequency of your subscriptions" link.

This means the user's email address will be present in logs, which isn't ideal. Although for analytics we filter emails before the reach GA, this would be difficult to replicate for logs.

We should consider how we can avoid having plaintext emails in the query params for managing subscriptions. There are a couple of approaches we could take here:

• Don't include it in the first place. This would mean the user has to enter their email manually as part of signing-in, which would increase of overhead for this workflow.

• Encrypt the email in a (non-expiring) token. This would require changes to the frontend (to accept the token) and the API (to change it in emails). We would also need to support the old behaviour.

If we're going to include verifiable/encrypted information in the "View, unsubscribe or change the frequency of your subscriptions" link, it may be simpler to support direct sign-in, with a suitable expiry.

Missing startup documentation

What?

Viewing this app for the first time and starting up in isolation (to resolve an a11y issue) it's not clear that the typical Frontend startup process outlined in the docs does not apply to this app.

In order to startup this app and to be able to move through example pages and have them render, this app has to be started using Docker and the --live flag.

$ govuk-docker up email-alert-frontend-app-live

Why?

Without starting the up via this method, the app from a Frontend POV is unusable and you run into many errors.
Eg you cannot use /.startup.sh or docker without live data.

PR conversation with @kevindew around updating the README advised that it would be more desirable to get consensus with startup documentation across many apps and is most likely a wider topic. Updating docs as suggested above would be misleading and would age badly