Set 'hide support messaging' cookie for one time contributors

[rupertbates]

What are you doing in this PR?

We want to stop working out user benefits from what products they have and instead delegate that to the user-benefits api.

As part of this work we no longer want to set a cookie to inform dotcom that a user has made a one time contribution, but instead set the 'hide support messaging' cookie which tells DCR & support-dotcom-components to show fewer support asks.

This PR works in combination with: guardian/dotcom-rendering#13037

[github-actions]

Deploy build 12657 of support::stripe-patrons-data to CODE

All deployment options

• Deploy build 12657 of support::stripe-patrons-data to CODE
• Deploy parts of build 12657 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[github-actions]

Size Change: -8 B (0%)

Total Size: 2.23 MB

ℹ️ View Unchanged

Filename	Size	Change
./public/compiled-assets/javascripts/[countryGroupId]/events/router.js	90 kB	0 B
./public/compiled-assets/javascripts/[countryGroupId]/router.js	265 kB	0 B
./public/compiled-assets/javascripts/ausMomentMap.js	108 kB	0 B
./public/compiled-assets/javascripts/contributionsRedirectStyles.js	20 B	0 B
./public/compiled-assets/javascripts/digitalSubscriptionLandingPage.js	235 kB	0 B
./public/compiled-assets/javascripts/downForMaintenancePage.js	70.4 kB	0 B
./public/compiled-assets/javascripts/error404Page.js	70.3 kB	0 B
./public/compiled-assets/javascripts/error500Page.js	70.3 kB	0 B
./public/compiled-assets/javascripts/favicons.js	617 B	0 B
./public/compiled-assets/javascripts/paperSubscriptionCheckoutPage.js	174 kB	0 B
./public/compiled-assets/javascripts/paperSubscriptionLandingPage.js	87.2 kB	0 B
./public/compiled-assets/javascripts/payPalErrorPage.js	68.6 kB	0 B
./public/compiled-assets/javascripts/payPalErrorPageStyles.js	20 B	0 B
./public/compiled-assets/javascripts/promotionTerms.js	73.3 kB	0 B
./public/compiled-assets/javascripts/subscriptionsLandingPage.js	72.6 kB	0 B
./public/compiled-assets/javascripts/subscriptionsRedemptionPage.js	127 kB	0 B
./public/compiled-assets/javascripts/supporterPlusLandingPage.js	307 kB	-8 B (0%)
./public/compiled-assets/javascripts/unsupportedBrowserStyles.js	20 B	0 B
./public/compiled-assets/javascripts/weeklySubscriptionCheckoutPage.js	171 kB	0 B
./public/compiled-assets/javascripts/weeklySubscriptionLandingPage.js	87.1 kB	0 B
./public/compiled-assets/webpack/136.js	2.17 kB	0 B
./public/compiled-assets/webpack/187.js	21.4 kB	0 B
./public/compiled-assets/webpack/344.js	2.01 kB	0 B
./public/compiled-assets/webpack/643.js	22.4 kB	0 B
./public/compiled-assets/webpack/706.js	107 kB	0 B

_{compressed-size-action}

[github-actions]

Deploy build 21921 of support:support-workers-mono to CODE

All deployment options

• Deploy build 21921 of support:support-workers-mono to CODE
• Deploy parts of build 21921 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.

[tomrf1]

Thinking through some scenarios:

1. a user already has the gu_hide_support_messaging cookie from a recurring product. They then make a single contribution. Does it matter that it's overwritten by one with an expiry? I think not, because DCR will overwrite it next time it talk to MDAPI.
2. a user makes a single contribution, then later signs into an account with a recurring product. Again, DCR will overwrite it.
3. a user makes a single contribution, then later takes out a recurring product. The cookie is replaced by one with a 24 hour expiry, and after that the user must sign in.

Does this all sound right?

[rupertbates]

Thinking through some scenarios:

1. a user already has the `gu_hide_support_messaging` cookie from a recurring product. They then make a single contribution. Does it matter that it's overwritten by one with an expiry? I think not, because DCR will overwrite it next time it talk to MDAPI.

2. a user makes a single contribution, then later signs into an account with a recurring product. Again, DCR will overwrite it.

3. a user makes a single contribution, then later takes out a recurring product. The cookie is replaced by one with a 24 hour expiry, and after that the user must sign in.

Does this all sound right?

Yes, this is all correct I think. The cookie set by support-frontend will cover the 90 days period which we give one time contributors until they sign in, from that point on the mdapi/user-benefits response takes over and they need to remain signed in to receive the benefit.

[prout-bot]

Seen on PROD (merged by @rupertbates 9 minutes and 32 seconds ago)

• Keep an eye out for the post deployment Playwright smoke tests github action
• If the tests have failed, the post deployment test runbook should help troubleshoot.

Sentry Release: support-client-side, support