feat: link scanned barcodes and medicine IDs to incident reports

[anshul23102]

Summary

Connect medicine scanner data to counterfeit incident reports for better tracking and verification.

Problem

When a user gets a suspicious result in the medicine scanner and clicks "Report", the system cannot link the scanned barcode or database medicine entry to the final incident report. This disconnects the scanner workflow from the reporting workflow.

Solution Implemented

Backend Changes (POST /api/reports)

• Extended createReportSchema with two optional fields:
  • scannedBarcode: z.string().optional()
  • medicineId: z.string().uuid().optional()
• Updated Supabase insert to store these values:
  • scanned_barcode
  • medicine_id
• Changes are backward compatible (fields are optional)

Frontend Changes (ReportWizard)

• Added useSearchParams hook to read URL query parameters
• Extract barcode and medicineId from URL on component mount
• Store extracted values in component form state
• Include barcode and medicineId in submitReport payload
• Conditionally include fields only if present

Data Flow

1. User scans medicine, gets suspicious/fake result
2. Clicks "Report" which navigates to /report?barcode=XXX&medicineId=YYY
3. ReportWizard reads query parameters and stores them
4. User fills report details through wizard
5. On submit, barcode and medicineId are included in payload
6. Backend stores these values linking the scan to the report
7. Incident report now has full traceability to scanner result

Testing

• ReportWizard extracts query parameters correctly
• Report submission includes barcode and medicineId when present
• Reports submitted without parameters still work (backward compatible)
• Barcode and medicineId properly stored in counterfeit_reports table

Fixes #1202

GSSoC 2026 Contribution

[anshul23102]

Updated PR with test mock fix: Added anonymizeIp to the reportValidation.service mock to prevent test failures. The implementation is working correctly and ready for review.

The CI failures appear to be related to pre-existing rate limiting in the test infrastructure, not my code changes. The core feature (linking barcode/medicineId to reports) is sound and backward compatible.

[anshul23102]

Root-cause analysis on the failing checks, since CI is red but the failures are not from this PR:

This PR changes only 4 files (reports.ts, reports.test.ts, ReportWizard.tsx, lib/api.ts), adding two optional fields and one test mock.

Build & Test (reports.test.ts): The failing cases return 429 (the anti-amplification rate-limit safeguard) or hit supabase.from(...).select(...).eq(...).eq is not a function in the PATCH status existence check. Both come from earlier commits already on the base branch, not from this change. I verified on a clean checkout of the base: reports.test.ts fails 5 tests there. On this branch it fails 4, because the anonymizeIp mock added here actually fixes one previously-failing case. So this PR strictly reduces the failure count.

quality-check (lint): The 3 errors are @ts-nocheck in admin/AnalyticsCharts.tsx and admin/CacheStatsCard.tsx, and an unused DEFAULT_RADIUS_KM in map/MapView.tsx. None are touched by this PR and all pre-date it.

The barcode/medicine linking itself is complete and backward compatible. Could a maintainer confirm whether the base-branch test/lint failures should be fixed here or tracked separately? Happy to open a focused follow-up PR to green them up.

[github-actions]

🎉 Congratulations @anshul23102! Your Pull Request "feat: link scanned barcodes and medicine IDs to incident reports" has been successfully merged by @dipexplorer.

Thank you for your valuable contribution to SahiDawa! 🇮🇳
If this was for GSSoC 2026, your work is officially merged and valid. Keep up the great work and feel free to claim other open issues. 🚀

Follow us on LinkedIn: https://www.linkedin.com/company/ratloopz/ to get shoutout