Backend models + DB:
- Adds tenant_id to 13 more parent tables: service_areas, routes,
collection_teams, trucks, trips, qr_code_batches, qr_codes,
collection_logs, dumpsite_releases, payments, daily_collection_stats,
weekly_route_performance, monthly_store_sales.
Child tables (route_stops, trip_stops, team_members,
truck_location_history, etc.) inherit scoping via their parent
relation — they aren't queried directly in production code.
- HasTenant trait applied to all 13 models, plus tenant_id added
to each fillable. Creating any one of these now auto-fills
tenant_id from Tenancy::current().
- BatchGenerator's bulk QrCode insert was bypassing model events
(and therefore the HasTenant creating hook). Now sets tenant_id
inline from the just-created batch's tenant_id, which itself
goes through the trait. Fixes "0 codes returned for resident in
same tenant" regression.
Backfill:
- SanPascualTenantSeeder extended to backfill all 18 tenant-aware
tables. Idempotent — only updates rows where tenant_id is null.
Production live data: backfilled 1 route, 1 team, 1 truck, 3
trips, 1 batch, 200 codes, 5 collection logs.
Tests:
- TestCase base now creates a default "TEST-LGU" tenant in setUp,
sets it as Tenancy::current(), and attaches X-Tenant-Code on
every JSON request. Tear-down clears the tenant.
- UserFactory defaults tenant_id to Tenancy::current()->id, so
factory-created users land in the test tenant.
- Net result: 202 tests still passing, no per-test changes
required.
Phase A scope (5 tables) + Phase B scope (13 tables) = 18 of the
~22 tenant-aware tables. The remaining child tables (route_stops,
trip_stops, team_members, truck_location_history, household_members,
trip_timeline_events, store_purchases, store_sales) are scoped
implicitly through their parent.
What's still un-tenant-aware:
- Admin web (Blade-based) — single-tenant context for now
- Driver/scanner endpoints — they currently rely on the bearer
token's user.tenant_id, which works correctly via ResolveTenant's
fallback. No action needed.
- Super-admin onboarding UI — Phase C.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
daily_collection_stats, weekly_route_performance, monthly_store_sales
aggregation tables. Aggregator service is idempotent — wipes the slice
and re-inserts. php artisan reports:aggregate (default: yesterday) for
the nightly cron. Admin endpoints: daily-collection / trip-performance
/ store-sales chart series + totals, compliance.csv stream of dumpsite
releases (DENR-style), POST rebuild for on-demand aggregation.
Payments, notifications, and live tracking sub-modules of Module 13
are deferred per scope.
164 feature tests passing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
