alphagov / email-alert-api Goto Github PK

In 2019 we added an endpoint to send a single email: #935.

I suspect the endpoint is unused, and leaving it is just a source of confusion, especially since we have other means to send bespoke email, which seem to be more popular in practice.

Should we only be allowing requesting in JSON format for this application? Am I correct in assuming that all GOV.UK APIs accept only JSON requests? If so perhaps this should be enforced within email-alert-api. Currently our tests are all accepting HTML type requests and do not reflect how we communicate with this application from places such as specialist-publisher.

This is a central issue to document the proposal to remove this feature from the email system, for the following reasons:

• It only works for topic taxons.

• It only works if the unpublished taxon was redirected.

• It is not monitored, so we don't know if the functionality works.

• It renders email using ERB, unlike the rest of the system.

• It arbitrarily culls any lists that refer to other taxons as well.

• We have no evidence it meets user needs.

It's also entirely undocumented, yet occupies a large part of the email system. Since the Notifications team is pausing, we think it will be faster to just remove it now, rather than try to document it and remove it later.

The general problem of dead lists is documented here as GOV.UK Tech Debt. Rather than keep a flawed solution, we've agreed at a product level that it makes sense to tackle this problem comprehensively, from scratch.

So that the ordering of tag values doesn't matter (in either subscription or notification APIs), we should:

• validate (in the model) that the values of tags stored associated with each tag type are sorted and uniqued.
• sort and uniq the tag values in the controllers.

As part of alphagov/email-alert-frontend#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.

Is it possible to use this service from a *.service.gov.uk site which isn't www.gov.uk - it looks to be exactly what we need to notifying our users when updates happen to our service (www.trade-tariff.service.gov.uk)?

Thanks in advance

GOV.UK has now twice unilaterally decided to change my email preferences. I set them how I wanted them, stop bloody second-guessing me! And why is it so painful to change them anyway? Surely the "we've changed your email preferences" email should have a link to change them back, rather than a link to where I type my email address, press submit, and then get another email telling me to reset my email preferences.

It's apparently doing this to "make the number of emails you get more manageable.". The number of emails I get is perfectly manageable, at less than one a day. Why is it doing this? I get more emails from this spammy piece of nonsense and then having to get another email to reset my preferences back to how I want them, than I do actual emails with content.

Please reverse this ill-conceived feature.