gracepress/technical-services-exchange
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add mobile work order API

Browse Source
This commit is contained in:
Codex
2026-07-10 18:22:13 -05:00
parent 71434c1ac4
commit eb9456e1bd
12 changed files with 775 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/FORWARD_PHASE_PLAN.md
+16 -5
View File
@@ -32,7 +32,6 @@ The goal is not to clone Field Nation. The goal is to keep the useful operationa
- Job posting now has structured scope and support certification fields, but the creation UI should be refined into reusable templates and stronger validation before real marketplace use.
- Provider and buyer directories use text-based filters instead of normalized category, skill, coverage, remote, rating, and reliability filters.
- Work-order lists are card-based and lack the dense assigned/available-work table that worked well in Field Nation.
- Work-order detail now supports contact/support failure logging and first-class change requests, but schedule update requests, running-late records, post-work tag verification, and general report-problem records still need a dedicated workflow.
- Work-order detail now supports contact/support failure logging, first-class change requests, and post-work provider tag verification; schedule update requests, running-late records, and general report-problem records still need dedicated workflows.
- Disputes and votes now have reason codes, but quorum rules, visibility rules, and deeper evidence timelines still need a future pass.
- Reviews exist, but there is no review response, report flow, edit window, moderation queue, category definitions page, or imported/native reputation distinction in the UI.
@@ -541,6 +540,18 @@ Provider-protection rules:
- Every mobile action should leave an audit trail visible to the provider.
- Support/contact failures should be as easy to log as check-in.
Implementation status:
- Completed first implementation pass.
- Added `/api/v1` mobile-safe work-order endpoints behind Sanctum auth and API throttling.
- Added token ability gates for `jobs:read`, `work-orders:read`, `work-orders:write`, `work-orders:upload`, and `disputes:write`.
- Added participant authorization on work-order detail and every work-order action.
- Added mobile actions for status transition, checklist update, message send, evidence upload, contact/support event logging, running-late notice, schedule-update request, and dispute opening.
- Added `work_order_mobile_events` as an audit trail for mobile actions.
- Added optional latitude, longitude, accuracy, and occurred-at fields to mobile action records with explicit privacy copy in API payloads.
- Added baseline HTTP security headers and an explicit `api` rate limiter.
- Verified with Windows `php artisan test`.
## Phase 12 - Notification Preferences And Event Channels
Purpose:
@@ -718,10 +729,10 @@ Provider-protection rules:
## Recommended Immediate Sequence
1. Phase 11A: mobile-safe API endpoints for onsite work-order actions.
2. Phase 12A: notification preference UI and event-channel controls.
3. Phase 13A: audit logs and moderation/operations queues.
4. Phase 14A: deployment/scaling hardening.
1. Phase 12A: notification preference UI and event-channel controls.
2. Phase 13A: audit logs and moderation/operations queues.
3. Phase 14A: deployment/scaling hardening.
4. Phase 15A: UX polish and accessibility pass.
## Key Design Commitments
docs/ROADMAP.md
+16 -5
View File
@@ -26,7 +26,8 @@ Provider Exchange is a Laravel application for a provider-centered field-service
- Peer-review disputes with comments, evidence, structured recommendations, and public vote breakdowns.
- Universal community ratings for buyers, providers, job posts, work orders, and disputes.
- Database notification events and notification inbox.
- Starter Sanctum API surface for future app clients.
- Versioned Sanctum API surface for future app clients, including mobile-safe work-order actions, token ability checks, action audit records, and optional geolocation evidence.
- Baseline API/security hardening with rate limiting and HTTP security headers.
- MIT license and no-payment/no-rate-setting guardrails.
## Operating Principles
@@ -58,11 +59,11 @@ Provider Exchange is a Laravel application for a provider-centered field-service
## Phase Checkpoint
Phases 1-10B have been implemented locally through post-work provider tag verification. The next active planning block is:
Phases 1-11A have been implemented locally through mobile-safe API actions and baseline security hardening. The next active planning block is:
8. API/mobile prep: token-scoped endpoints, versioned API resources, geolocation check-in groundwork, contact/support failure logging, and mobile-safe work-order actions.
9. Notification preference UI and event-channel controls.
10. Admin operations, audit logs, and deployment hardening.
8. Notification preference UI and event-channel controls.
9. Admin operations, audit logs, and moderation queues.
10. Deployment/scaling hardening and UX/accessibility polish.
Work-order safeguards to carry into the next implementation passes:
@@ -134,6 +135,16 @@ Post-work provider tag verification completed:
- Provider profiles now show recent completed-work competency evidence separately from imported history and five-star reviews.
- Providers cannot self-verify their tags from a work order.
Phase 11A mobile API and security hardening completed:
- `/api/v1` now exposes mobile-safe endpoints for available jobs, assigned work orders, work-order detail, status transitions, checklist updates, messages, evidence uploads, contact/support events, running-late notices, schedule-update requests, and dispute opening.
- API tokens can be scoped by ability: `jobs:read`, `work-orders:read`, `work-orders:write`, `work-orders:upload`, and `disputes:write`.
- Work-order API actions enforce buyer/provider/admin participant boundaries.
- Mobile actions write to `work_order_mobile_events` with event type, user, payload, optional coordinates, optional accuracy, and occurred-at timestamp.
- Geolocation is optional and documented in the API response as work-order evidence only.
- API routes are throttled through an explicit `api` rate limiter.
- Application responses include baseline security headers: content-type sniffing protection, same-origin frame policy, strict origin referrer policy, limited permissions policy, and HSTS on secure requests.
Available-work safeguards to carry into directory and job-list phases:
- Available jobs should expose pay type, provider terms, schedule type, work type, rough location, buyer reliability, support/contact certification, scope clarity status, and request/quote count.