CCM-20032: Letter Variant SupplierId Not Honoured#634
Conversation
430dc4e to
1086bb7
Compare
1086bb7 to
30c7f1f
Compare
6955ecc to
0ef1446
Compare
0ef1446 to
51cd442
Compare
c7ff230 to
2b34aa3
Compare
2b34aa3 to
197426d
Compare
| }); | ||
| } | ||
| return { | ||
| supplierAllocations: filteredAllocations, |
There was a problem hiding this comment.
I'm just trying to understand the logic of this change. The ticket says:
All volume group and supplier allocations logic should be applied before applying this filter
But it looks like you're skipping the getSupplierAllocationsForVolumeGroup step here - is that correct?
There was a problem hiding this comment.
Yes - if we have a supplier specified on the letter variant, the allocation is going to them regardless of the allocation percentage. That will only come into affect for other letters in the volume group that do not have a supplier Id on the variant
| test.describe("Letter Variant Tests", () => { | ||
| test.setTimeout(180_000); // 3 minutes for long running polling | ||
|
|
||
| test("Verify that supplierId on letter variant takes pecedence over volume group", async () => { |
There was a problem hiding this comment.
Minor typo: pecedence -> precedence
| volumeGroupId: volumeGroup.id, | ||
| letterVariantSupplierId, | ||
| }); | ||
| const filteredAllocations = supplierAllocations.filter( |
There was a problem hiding this comment.
Am I right in thinking there will only ever be one supplier allocation per supplier? If so, it might be clearer to use find here rather than filter
|



Description
Context
Type of changes
Checklist
DT3-Specific Checklist
Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.