training

Scope
1. Network Expansion Visits
Implement paginated visit listing.
Add filters for:
Status
Network Expansion Executive
Start date range
Search by title/purpose
Implement visit creation.
Implement visit detail view.
Implement visit update while the visit is in PLANNED status.
Implement visit cancellation with an optional reason.
Implement executive dropdown using the sales-executives filter API.
Implement visit activity timeline.
2. Visit Locations
Display locations associated with each visit.
Show location status and onboarding status.
Display location details, notes, media counts and captured setup information.
Support onboarding progression from GOOD to AVAILABLE_FOR_SALE.
Refresh visit/location details after onboarding status updates.
3. Proposed Locations

Implement the CMS-only Proposed Location flow:

Create Proposed Location.
List/search Proposed Locations.
View Proposed Location details.
Update Proposed Location.
Soft-delete Proposed Location.
Upload/list/delete media.
Add and display notes.
Display activity log.
Mark location as GOOD.
Advance location from GOOD to AVAILABLE_FOR_SALE.
4. Validation & Status Handling

Mirror the API validations on the frontend:

At least one network expansion executive is required.
At least one location is required for a visit.
Exactly one visit location must be marked as destination.
locationName is required.
Executive IDs must belong to active network_expansion_executive users.
Visit editing/cancellation is allowed only when status is PLANNED.
Onboarding transition must be sequential: GOOD → AVAILABLE_FOR_SALE.
Proposed Location property type and offer validations must be handled.
Display API validation/error messages appropriately.
5. Permissions

Use the existing permission-based approach:

stations.network_expansion_visits.view
Required for all GET operations.
stations.network_expansion_visits.manage
Required for create/update/cancel/onboarding and other management operations.

Hide management actions when the logged-in user does not have the required permission.

6. API Integration

Use the standard CMS authentication:

Authorization: Bearer <jwt>
Tenant/company context must be resolved from the JWT.
Handle standard API response envelope:
success
data
message
errors
statusCode
timestamp

Handle HTTP 400, 403, 404, and 500 responses appropriately.

7. Statuses

Visit status:
PLANNED | IN_PROGRESS | COMPLETED | CANCELLED

Location status:
PENDING | IN_PROGRESS | VISITED | SKIPPED

Onboarding status:
GOOD | AVAILABLE_FOR_SALE

The CMS should treat visit execution statuses as read-only because IN_PROGRESS and COMPLETED are generated from the mobile execution flow.

Expected Outcome

The CMS should provide a complete Network Expansion Visit management flow allowing authorized users to create, manage, review, cancel and monitor network expansion visits and proposed locations, including location onboarding, notes, media and activity history.

All API integrations should follow the provided contracts and permission/validation rules.