Ezra/311 partner shipment status updates

[ezraexe]

Description

When there were entries in the database that didn't have both teh donorShippingNumber AND teh hfhShippingNumber, it would skip and return the default status. This change implements a fix to prevent the partner from seeing the hardcoded default status and the actual status.

Resolves ticket number: #311

Explain what your code changes:

shippingStatusService - removing lookupPairs and using the existing validPairs instead because that's what we are looking for
distributionService - removed the if conditional that checks for both shipping numbers
allocationService - removing lookupPairs and using the existing shippingNumberPairs because that's what we're looking for
signOffService - simplified the if conditional to just do the check for hasShippingIdentifier

List the steps you took to test your code:

Used a db script with 3 different entries where:

• One has only donorShippingNumber
• One has both shippingNumbers
• One has only hfhShippingNumber

These items were then linked to Hope Medical Center as the partner and confirmed that all of the items would show the actual status rather than the default status.

Checklist

• The ticket is mentioned above
• The changes fulfill the success criteria of the ticket
• The changes were self-reviewed
• A review was requested

[netlify]

✅ Deploy Preview for hope-for-haiti ready!

Name	Link
🔨 Latest commit	77ff238
🔍 Latest deploy log	https://app.netlify.com/projects/hope-for-haiti/deploys/69c6fcced64d4200074a3255
😎 Deploy Preview	https://deploy-preview-313--hope-for-haiti.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[greptile-apps]

Greptile Summary

This PR fixes a bug where partner-facing shipment status views would fall back to the hardcoded default (WAITING_ARRIVAL_FROM_DONOR) for line items that had only one of the two shipping numbers set. The fix removes the over-restrictive filter that required both donorShippingNumber and hfhShippingNumber to be present before querying ShippingStatus, and replaces it with the looser hasShippingIdentifier guard that passes as long as at least one identifier exists.

Key changes:

• shippingStatusService & allocationService: Removes the lookupPairs intermediate filter that was narrowing valid pairs to only those with both fields, and now uses the already-hasShippingIdentifier-filtered set directly in the findMany OR query.
• distributionService: Replaces the if (tuple.donorShippingNumber && tuple.hfhShippingNumber) guard with a normalizeShippingTuple call before the unconditional findFirst query.
• signOffService: Drops the redundant && tuple.donorShippingNumber && tuple.hfhShippingNumber portion of the conditional, relying solely on hasShippingIdentifier.

Areas to address:

• allocationService.ts and signOffService.ts do not call normalizeShippingTuple before building the database query, unlike distributionService.ts which does. An empty-string shipping number in the database would not be converted to null, potentially causing a lookup miss. Using normalizeShippingTuple consistently across all four services would close this gap.

Score: 88/100 — The fix is correct and well-tested. The only deduction is for the normalization inconsistency across services and minor trailing whitespace.

Confidence Score: 5/5

Safe to merge — the fix correctly broadens status lookup to items with only one shipping number, and all remaining findings are minor style/consistency suggestions.

All identified issues are P2: one inconsistency around missing normalizeShippingTuple calls in two services (won't cause bugs for well-formed data, since Prisma fields don't return empty strings unless they were stored that way) and one trailing whitespace. No logic errors or data integrity risks are introduced.

src/services/allocationService.ts and src/services/signOffService.ts — consider adding normalizeShippingTuple before building DB queries for consistency with distributionService.

Important Files Changed

Filename	Overview
src/services/allocationService.ts	Removes the lookupPairs filter that required both shipping numbers; now queries with any valid pair. Pairs are not normalized before querying (unlike shippingStatusService), a minor inconsistency.
src/services/distributionService.ts	Replaces the dual-shipping-number guard with a normalizeShippingTuple call; correctly queries for items with only one shipping number. Minor trailing whitespace on line 392.
src/services/shippingStatusService.ts	Removes lookupPairs filter and uses already-normalized validPairs directly; the ?? null is redundant but harmless since validPairs is already normalized.
src/services/signOffService.ts	Simplifies condition to hasShippingIdentifier(tuple) and uses ?? null for the query; tuple is not normalized via normalizeShippingTuple, a minor inconsistency with other services.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Line Item from DB] --> B{hasShippingIdentifier?}
    B -- No --> C[Skip / use default status]
    B -- Yes --> D[normalizeShippingTuple\ndistributionService only]
    D --> E[Query ShippingStatus\nWHERE donorShippingNumber = X\nAND hfhShippingNumber = Y\nnulls become IS NULL]
    F[allocationService\nsignOffService\nshippingStatusService] -->|?? null only| E
    E --> G{Record found?}
    G -- Yes --> H[Use stored ShipmentStatus]
    G -- No --> I[Use default: WAITING_ARRIVAL_FROM_DONOR]

Loading

_{Reviews (1): Last reviewed commit: "same changes as distributionService" | Re-trigger Greptile}

[greptile-apps]

Pairs not normalized before query

shippingNumberPairs is constructed directly from Prisma model fields and filtered with hasShippingIdentifier, but is never passed through normalizeShippingTuple before being mapped into the query. This means an empty-string shipping number (e.g. "") would be sent to the database as "" rather than null, potentially failing to match a ShippingStatus record that was stored with null.

By contrast, shippingStatusService.ts explicitly normalizes its pairs before querying:

const validPairs = shippingNumberPairs
  .map((pair) => normalizeShippingTuple(pair))
  .filter((pair) => hasShippingIdentifier(pair));

For consistency and safety, normalize the pairs here too:

Suggested change

	OR: shippingNumberPairs.map((pair) => ({
	donorShippingNumber: pair.donorShippingNumber ?? null,
	hfhShippingNumber: pair.hfhShippingNumber ?? null,
	})),
	OR: shippingNumberPairs.map((pair) => {
	const normalized = normalizeShippingTuple(pair);
	return {
	donorShippingNumber: normalized.donorShippingNumber,
	hfhShippingNumber: normalized.hfhShippingNumber,
	};
	}),

The same pattern applies in src/services/signOffService.ts (line 207), where the tuple is also not normalized before being used in the findFirst where clause — normalizeShippingTuple(tuple) should be used there as well.

[greptile-apps]

Trailing whitespace

There is a trailing space after the semicolon on this line.

Suggested change

	const normalizedTuple = normalizeShippingTuple(tuple);
	const normalizedTuple = normalizeShippingTuple(tuple);

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[ND68]

clean fix, nice work