Viagens — iOS

TripCadViewController · viewControllersCad/CadTripViewController Paridade com Android: TripCadFragment

Cadastro e edição de viagens, migrado para v1 (base https://api.monisystem.com/v1, Bearer JWT). No iOS o fluxo é organizado em cadTrips/ com ViewControllers especializados por etapa (rota, datas, veículo, motorista, pontos, temperatura). A análise/criação usa o padrão duplo POST /v1/trip/ com accept_nonconformity — em paridade com o Android.

Arquivos

cadTrips/
├── TripCadViewController.swift            · entrada principal (dropdowns v1)
├── BaseSelectionModalViewController.swift · base de modais de seleção
├── RouteDatePickerModal.swift             · escolha de datas da rota
├── SelectedTypeViewController.swift       · tipo de viagem + gating (loadAllData)
├── viewControllersCad/
│   └── CadTripViewController.swift        · análise/criação v1 (submitTripV1)
├── modals/                                · modais auxiliares
├── parser/                                · conversão Model ↔ JSON
├── views/                                 · subviews customizadas
└── config/                                · configuração do form

Etapas do cadastro

Etapa	Descrição
Rota	Origem, destino, rotograma — busca `GET /v1/rotograms`
Datas	`RouteDatePickerModal` — janelas previstas de saída/chegada
Veículo	Modal lista `GET /v1/vehicles`
Motorista	Modal lista `GET /v1/user` filtrado por papel
Pontos / Entregas	`GET /v1/point` + reordenação local
Temperatura	Setpoint mínimo/máximo p/ sensores (ver Relatórios)

Fluxo de análise e criação (duplo POST /v1/trip/)

Não existe endpoint /analyze separado — a análise e a criação usam o mesmo POST /v1/trip/, alternando o booleano accept_nonconformity. Toda a lógica vive em viewControllersCad/CadTripViewController.swift:

analyzeTrip() — accept_nonconformity=false

buildTripPayloadV1(status:acceptNonconformity:) monta o corpo snake_case e submitTripV1(payload:) faz o POST /v1/trip/. O backend Go devolve conflitos/avisos; se estiver limpo já cria a viagem e retorna 201 (a flag interna marca que a viagem já foi criada na análise).

processAnalysisResponseV1() → AnalysisResult

A resposta é interpretada por processAnalysisResponseV1(jsonResponse:statusCode:), que produz um AnalysisResult exibido em popup para o usuário confirmar/ajustar. Espelha a classe AnalysisResult do Android.

submitTripV1() — accept_nonconformity=true

Confirmado o popup, reenvia o mesmo payload com accept_nonconformity=true (a menos que a viagem já tenha sido criada com 201 na etapa 1), efetivando a criação. Não há segundo POST ao legado — o fluxo de criação é 100% v1.

Gating de tipo/perfil — GET /v1/trip/registration_permissions

Antes de liberar os tipos de viagem, SelectedTypeViewController.loadAllData() chama GET /v1/trip/registration_permissions, que consolida no backend as permissões (allowed + checks) — substituindo as leituras antigas por Elasticsearch. Em paridade com o Android (TripCadViewModelNew).

Endpoints

POST/v1/trip/

Analisa e cria a viagem (submitTripV1). Body construído por buildTripPayloadV1 a partir do estado das abas. Enviado com accept_nonconformity=false (análise) e depois true (confirmação). Não há PUT de edição confirmado.

GET/v1/trip/registration_permissions

Gating de tipos/perfis do cadastro (SelectedTypeViewController.loadAllData). Retorna allowed + checks.

GET/v1/trip/situation

Situações disponíveis para a viagem.

GET/v1/user?_driver=true&_limit=10000

Motoristas (filtro _driver=true sobre usuários). Não existe /v1/drivers.

GET/v1/profile?_client_id=...

Perfis de viagem (singular).

GET/v1/policy?_client_id=...&_active=true

Apólices ativas do cliente (singular).

GET/v1/point

Pontos de parada/entrega (não existe /v1/delivery-points).

GET/v1/rotograms

Rotogramas cadastrados.