17 — Tester feedback tracker
Tester feedback comes in two shapes and ends up in the same place — the Swasti Feedback doctype on staging Frappe. Every item there has an SWF-2026-#### ID, an audit trail, and is referenced from app commit messages by ID.
Where reports come from
Track 1 — PM Excel (batched).
- File:
Feedback_Tracker_Swasti.xlsx - Owner: Akshat Verma · Editors: Fahimuddin Sayyed + testers
- Open it: Feedback_Tracker_Swasti.xlsx (SharePoint)
- Sheets:
Testing Feedback(bugs),Suggestions(feature requests),Legend(status vocab). - Dhwani-side columns: Layer (Frappe / App / Both) and Dhwani Status / Notes (our internal state, distinct from the testers’ Resolution column).
- We pull batches from this sheet into the KB as SWF-* tickets so they share the same triage / fix / verify pipeline as live form submissions.
Track 2 — Live KB feedback form.
- URL: swasti-kb-7930d5fc.pages.dev/feedback (Basic Auth)
- Anyone in the tester / PM circle can file a bug or suggestion directly. Submissions land as new rows on the Swasti Feedback doctype on staging Frappe.
- The KB feedback list also supports edit-in-place (title, description, severity, status, screenshots) without opening the Frappe desk.
How we work
- Frappe first. Every fix must work on the Frappe backend before the app implements against it — the doctype / API / permission is the foundation, the app mirrors it.
- We own the whole stack, including Frappe. Frappe/auth/permission items are not “DevOps’ problem” — they’re ours to fix. Nothing gets parked as out-of-scope just because it’s server-side.
- Triage each batch with the PM. Not every logged item is actioned wholesale; ambiguous calls (e.g. benefit-eligibility semantics) are confirmed before code changes. Items sort into: in-progress, needs-PM-input, and later-sprint enhancements.
Snapshot — 2026-06-05
KB tracker: 53 Done / 1 Open. The single remaining item is SWF-2026-00106 (workflow close on a specific option path) — blocked on a Frappe schema issue (mobile_created_at MySQL 1054 on the Livelihood Application POST). Tracked separately as Task #138.
What shipped this week
| Ticket | Module | What it was | What we did |
|---|---|---|---|
| SWF-2026-00108 | HS | Marital + Disabled + Age Months re-asked instead of inherited from member | Render as read-only imported rows from member profile |
| SWF-2026-00118 | HS | Numeric range hints placed in field placeholders were getting truncated on real phones | Moved range hints into section headers (BMI / BP / RBS / Healthy Days) |
| SWF-2026-00119 | HS Followup | Visit form didn’t carry the member’s identity once you started filling | Added census header (member name + village card) |
| SWF-2026-00120 | HS Followup | Visit 2 “side-effects?” question was hidden under “taking medication = No” | Hoisted out of conditional — always asked on Visit 2 |
| SWF-2026-00122 | HS | Expressed Illness was a single Select; PM wanted multi-select | Rebuilt as Table MultiSelect with Link-aware resolver provider; manifest entry + Custom DocPerm patch landed in lockstep |
| SWF-2026-00123 | HS Followup + Rescreening | Section numbering missing | Added 1.1–4.3 numbering, mirrored across both screens |
| SWF-2026-00124 | HS Followup | Orphan “If Others, please specify” fields with no matching parent option | Dropped |
| SWF-2026-00126 | Livelihood | Loan fully repaid wasn’t closing the parent workflow | Added parent close-gate on save (direct SQL UPDATE on docs__livelihood_application + on_update server hook) |
| SWF-2026-00127 | Livelihood | Avg Net Income + Loan Repaid being asked on Defaulted months they shouldn’t apply to | Skip-logic: gated on Regular / Irregular only; reorder Loan Repaid to end of section |
| SWF-2026-00128 | Livelihood | Option name “Defaulted, No payment made” misrepresented a delayed-but-paid scenario | Renamed → “Defaulted, payment delayed” + data migration patch v3_0._021 |
| SWF-2026-00132 | Home | ”Health Screenings” tile stuck at 0 even with screenings on members | Was counting against the dead V2 doctype name; switched to V3 + invalidate provider on save |
| SWF-2026-00133 | HS Followup | Saved + synced follow-ups kept showing “Pending sync” | Pre-compute current_status client-side (mirror of server’s _derive_followup_status); server re-derives identically on push |
| SWF-2026-00134 | Home | Quick-add FAB no longer fit the per-member flow | Removed |
| SWF-2026-00038 | Sync | Long-standing “Response syncing is failed” | Closed as covered by the current sync stack |
| SWF-2026-00139 | Livelihood | Repayment FU tappable before Goat Purchase FU | Sequence gate — Repayment locked with “Complete Goat Purchase first” until at least one Goat FU exists |
| SWF-2026-00140 | Livelihood | Defaulted, payment delayed was closing the workflow | Now derives “Nth Month Payment Delayed” (non-terminal); workflow closes only on loan_fully_repaid=Yes or visit 10. Frappe hotfix fbad7ce made loan_fully_repaid conditionally required to match the skip-logic. |
Earlier items (still Done)
The May–early June close-out included Member donor/partner/facilitator read-only (SWF-001), back-button sync logout fix, Scheme imported donor/IP names, searchable pickers, Marital options + eligibility aliasing (Unmarried → Single, Separated → Married, Not Applicable → no marital filter), disability certificate question, Member question numbering, Comfort-with-mobile option wrapping, Member detail Profile tab fields. All shipped to testers in builds through May 31.
Latent — worth checking before they bite
Three more reqd: 1 traps on Repayment FU JSON (amount_received, goat_insurance, repayment_date) — same Desk-vs-server pattern as loan_fully_repaid was. Working FUs happen to populate them, so the bug hasn’t fired yet. Switch to mandatory_depends_on + add server-side conditional checks in _validate_conditional_mandatory before the next tester batch where a skip-logic case might drop one.
Closed Frappe-side items
The earlier May report flagged login/reset (#4) and geography user permissions (#5) as Frappe items. Both addressed end-of-May — auth works, surveyor onboarding covered in note 16, geography scoping ships through child-form inheritance (P1 / A11 in the kickoff actions list).