Use v2 promos table #3327
Use v2 promos table #3327
Conversation
|
|
||
| export type Promo = z.infer<typeof promoSchema>; | ||
|
|
||
| export const appliedPromotionSchema = z.object({ |
| promoCode: string; | ||
| }; | ||
|
|
||
| export const validatePromotion = ( |
There was a problem hiding this comment.
this file stays very close to the v1 implementation: https://github.com/guardian/support-service-lambdas/blob/main/modules/promotions/src/v1/validatePromotion.ts#L21
| return parseResult.data; | ||
| }; | ||
|
|
||
| export const getDiscountRatePlanFromCatalog = ( |
There was a problem hiding this comment.
copied from v1/getPromotions.ts
|
|
||
| const dynamoClient = new DynamoDBClient(awsConfig); | ||
|
|
||
| export const getPromotion = async ( |
There was a problem hiding this comment.
replaces the v1 getPromotions function: https://github.com/guardian/support-service-lambdas/blob/main/modules/promotions/src/v1/getPromotions.ts#L14
| } from '@modules/internationalisation/schemas'; | ||
| import { z } from 'zod'; | ||
|
|
||
| export const promoProductSchema = z.enum([ |
There was a problem hiding this comment.
I realise this was not introduced in this PR but we should be using the product catalog values for this.
There is a schema called productKeySchema which lists these here:
Possibly we could add another schema which is a subset of these as not all will be discountable, but we should really try and work with the same product names across our whole code base.
There was a problem hiding this comment.
The complication is that in the promo tool the concept of PromoCampaign groups several product rate plans into one "product", e.g. Newspaper.
This promoProductSchema is only relevant to PromoCampaigns. At the level of individual promo codes we map direct to a set of rate plan ids
There was a problem hiding this comment.
Perhaps we could make this clearer by inlining this enum in the promoCampaignSchema
| ? validatePromotion(promotions, appliedPromotion, productRatePlanId) | ||
| : undefined; | ||
| const validatedPromotion = | ||
| appliedPromotion && promotion |
There was a problem hiding this comment.
I think we should fail at this point if we have an applied promotion but not a promotion as that will mean we have told the user they are getting a discount which they will not then get.
There was a problem hiding this comment.
Good spot. I've pushed a commit to handle this in validatePromotion
We're migrating to a new promos tool, with a new Dynamodb table and a simplified schema.
The old tool/table is still in use. Data is currently being sync'd from the v1 table to the v2 table.
Currently we have v1 and v2 versions of the schemas:
This PR adds equivalent functions to replace the use of the v1 table:
It also refactors the zuora code to use the v2 versions.
The biggest change here is that instead of performing a full scan of the promos table, it now gets the specific item by
promoCode. This wasn't possible with the old schema because each item could have many promo codes nested in it.This is why
getPromotionsis being replaced bygetPromotion.This code is used by support-workers.
Once this is released we can update support-workers to use it.