22 lines
1.2 KiB
Markdown
22 lines
1.2 KiB
Markdown
|
---
|
||
|
|
name: Donate semantics
|
||
|
|
description: How donations affect a request's collectedAmount and status in the EHSAN POC.
|
||
|
|
---
|
||
|
|
|
||
|
|
# Donate accounting & pipeline transition
|
||
|
|
|
||
|
|
On `POST /requests/:id/donate`, the server **adds** the donation to `collectedAmount`
|
||
|
|
(never overwrites it), clamps the applied amount to the remaining target, rejects
|
||
|
|
non-finite/non-positive amounts and cases that are not `published` / already funded.
|
||
|
|
A case only transitions out of `published` into the closed-loop pipeline (`donated`
|
||
|
|
→ delivered → … → whatsapp_sent → closed) once `collectedAmount >= requestedAmount`.
|
||
|
|
|
||
|
|
**Why:** opportunity cards show a crowdfunding-style progress bar with collected/remaining.
|
||
|
|
An earlier handler overwrote `collectedAmount` and force-advanced to `donated` on any
|
||
|
|
donation — fine when all published seeds started at 0, but it silently corrupted totals
|
||
|
|
and made partially funded cases vanish from `/requests/published` after one donation.
|
||
|
|
|
||
|
|
**How to apply:** keep at least one seed case nearly fully funded so the closed loop is
|
||
|
|
trivially demoable with a single preset donation. Frontend (`donate.tsx`) must also
|
||
|
|
validate finite/positive amounts and clamp to remaining before submitting.
|