On this page
What to testFor Quality
What to test
The fix is in handleNewOnlinePayment() (PAYMOB branch), packages/server/src/resolvers/mutations/mutationUtils/onlinePaymentsUtils.js:196. Test at the level of whatever calls it — generateOnlinePayment, collectDiagnosticFees, addNewAppointment, savePatientDetails — with a PaymentOption whose provider is PAYMOB.
Core cases
| # | Setup | Expected outgoing email to Paymob | ||||
|---|---|---|---|---|---|---|
| 1 | Patient has no email; caller passes no email arg | online_payment@dentolize.com | ||||
| 2 | Patient has an email; caller passes no email arg | Patient's email | ||||
| 3 | Patient has no email; caller explicitly passes an email arg (e.g. typed into the Generate Online Link form) | The explicitly passed email | ||||
| 4 | Patient has an email; caller passes a different explicit email arg | The explicitly passed email (explicit always wins — `email | fallback, args.email | invoice.patient.email` upstream) |
Case 1 is the one this PR fixes — verify it doesn't throw and that the resulting request actually reaches Paymob's payment-links endpoint with a non-empty email field (mock the axios call and assert on postData.email if testing at the unit level).
Where to check it end-to-end
Any of the four entry points work for a manual/e2e check, but the invoice flow is the most direct:
- A
PaymentOptionconfigured withprovider: PAYMOBmust exist for the
test company (requires the onlinePaymentActive / onlinePaymentEnabled company flag — this is plan-gated, so confirm it's on for whatever environment you're testing in, it was off in the current sandbox used for this doc set).
- Pick or create a patient with no email.
- Open one of their invoices, click Generate Online Link, leave Email
blank, fill in phone only, submit.
- Before this fix: request could be rejected by Paymob (missing
email
field). After: request should succeed and a link should appear on the invoice's Online Payments tab.
Regression checks — make sure these still work unchanged
- Geidea, Fawry, Stripe payment link generation, with and without a
patient email — none of their code paths were touched, so behavior should be identical to before this PR. Worth a quick smoke test to confirm no cross-branch regression was introduced.
- Paymob with an email present — the top-level
emailfield and the
shipping_data.email field should both equal the real email, same as before (the shipping_data edit was a no-op simplification, not a behavior change — verify it stays that way).
shipping_dataomission — when email is blank,shipping_datashould
still be entirely undefined (not sent), per the surrounding email ? {...} : undefined ternary, which this PR didn't touch.
Edge cases worth a second look
- Very long or malformed real patient emails — unaffected by this PR, but
adjacent code (EmailField.js caps at 200 chars, validates type: email on the frontend) — the backend doesn't re-validate, so a check that a bad email doesn't silently corrupt the Paymob request is a pre-existing gap, not something this PR introduced or fixed.
- Concurrent link generation for the same invoice — out of scope for this
PR, not affected by this change.