VEH · Vehicles

A car belongs to a home pool and, when it isn't the operator's own, to a rental company. Its status changes only through database functions, which write its history. unit_code keeps v1's unit id, so the printed unit QR codes keep working. Code VEH.

Not yet a rule

These questions are open in #77. Each gets a rule with a new ID once it is answered.

VEH open 1 · Who else reads vehicles
VEH open 2 · Status history
VEH open 3 · Pool on child rows
Rename contract_status to supply_status: OQ10 (#36)

Answered in part

VEH open 1: gate:read and fleet_monitor:read read cars too (R-VEH-15, R-VEH-16), which settles acceptance check 7. Whether any other permission reads cars stays open.

Rules

R-VEH-01 · A plate is stored in upper case without spaces

Status: planned
Example: given a new car, when its plate is saved as "b 1234 xyz", then it is refused; B1234XYZ is accepted.
Refusal: none: check_violation (23514).
Who: every writer.
Source: [Ref] Database rules and conventions, Normalized input; [Ref] Data model V13: vehicles.

R-VEH-02 · A plate is unique within the organization

Status: planned
Example: given a car with plate B1234XYZ, when a second car with B1234XYZ is saved in the same organization, then it is refused.
Refusal: none: unique_violation (23505).
Who: every writer.
Source: [Ref] Data model V13: vehicles; D9 (P3).

R-VEH-03 · A unit code is unique within the organization

Status: planned
Example: given a car with unit code 0042, when a second 0042 is saved in the same organization, then it is refused.
Refusal: none: unique_violation (23505).
Who: every writer.
Source: [Ref] Data model V13: vehicles.

R-VEH-04 · A vehicle's year is between 1990 and 2100

Status: planned
Example: given a new car, when its year is saved as 202, then it is refused.
Refusal: none: check_violation (23514).
Who: every writer.
Source: [Ref] Data model V13: vehicles.

R-VEH-05 · A new vehicle starts as not_ready

Status: planned
Example: given a car is added with no status, when it is read back, then its status is not_ready.
Refusal: none.
Who: every writer.
Source: [Ref] Data model V13: vehicles.

R-VEH-06 · App users can't change a vehicle's status directly; only database functions can

Status: planned
Example: given an admin_fleet, when he updates vehicles.status from ready to rented, then it is refused and the status stays ready.
Refusal: vehicle.status_locked
Who: every app user (authenticated). Database functions, jobs and the migration may.
Source: D9 (P9); [Ref] Database rules and conventions, Status and stage only through functions; the M0 acceptance checks.

R-VEH-07 · Every vehicle status change writes a status history row with the old and new status

Status: planned
Example: given a ready car, when app.set_vehicle_status moves it to booked, then vehicle_status_history has a row from ready to booked, with who and when.
Refusal: none.
Who: app.set_vehicle_status and every function that calls it.
Source: D9 (P9); the M0 acceptance checks.

R-VEH-08 · Changing a vehicle's status needs vehicle:write, booking:write, inspection:handover, preparation:write, maintenance:write or insurance:write at its home pool

Status: planned
Example: given a satpam at PML, when he calls app.set_vehicle_status on a PML car, then it is refused; a checker at PML may.
Refusal: vehicle.status_forbidden
Who: super_admin, admin, admin_fleet, checker, maintenance and asuransi hold one of these.
Source: [Ref] Database rules and conventions, Status and stage only through functions; the M0 acceptance checks.

R-VEH-09 · When a car's plate changes, the old plate is kept in its plate history

Status: planned
Example: given a car with plate B1234XYZ, when its plate changes to B5678ABC, then vehicle_plate_history holds B1234XYZ, so an old ETLE ticket still finds the car.
Refusal: none.
Who: every writer.
Source: [Ref] Data model V13: vehicle_plate_history.

R-VEH-10 · An inspection, work order or gate pass given no pool takes its car's home pool

Status: planned
Example: given a car whose home pool is PML, when an inspection is saved for it with no pool, then its pool is PML.
Refusal: none.
Who: every writer.
Source: D9 (P5); [Ref] Database rules and conventions, Bookings (pool on child rows).

R-VEH-11 · A car has at most one GPS device

Status: planned
Example: given a car with an Easygo tracker, when a second device is linked to it, then it is refused.
Refusal: none: unique_violation (23505).
Who: every writer.
Source: [Ref] Data model V13: gps_devices.

R-VEH-12 · Adding or changing a vehicle, its documents or its GPS device needs vehicle:write at its home pool

Status: planned
Example: given a maintenance user at PML, when she edits a PML car's color, then nothing changes; an admin_fleet at PML may.
Refusal: none: insufficient_privilege (42501) on insert; no effect on update.
Who: super_admin, admin and admin_fleet hold vehicle:write.
Source: [Ref] Roles, policy matrix.

R-VEH-13 · Deleting a vehicle needs vehicle:delete at its home pool

Status: planned
Example: given an admin, when he deletes a car added by mistake, then nothing is deleted; a super_admin's delete goes through when nothing references the car (R-CONV-11).
Refusal: none: no effect without the permission.
Who: super_admin holds vehicle:delete.
Source: [Ref] Roles, policy matrix; D9 (P13).

R-VEH-14 · vehicle:read at a car's home pool lets a user read the car

Status: planned
Example: given a viewer scoped to PML, when she reads vehicles, then PML's cars come back.
Refusal: none: hidden without it.
Who: super_admin, admin, admin_driver, admin_fleet, maintenance, asuransi, checker and viewer hold vehicle:read.
Source: [Ref] Roles, policy matrix.

R-VEH-15 · gate:read at a car's home pool lets a user read the car

Status: planned
Example: given a satpam at PML, who holds gate:read, when he scans a PML car's unit code at the gate, then the car comes back; a PML car stays hidden from a satpam scoped to SBY.
Refusal: none: hidden without it.
Who: super_admin, admin, maintenance, asuransi, checker, satpam and viewer hold gate:read.
Source: [Ref] Roles, policy matrix (vehicles: vehicle:read and other vehicle-facing reads); D25, which makes the delivered M0's checks the acceptance list (check 7: satpam reads its pool's car).

R-VEH-16 · fleet_monitor:read at a car's home pool lets a user read the car

Status: planned
Example: given a user whose only vehicle-facing permission is a grant of fleet_monitor:read at PML, when she reads vehicles, then PML's cars come back.
Refusal: none: hidden without it.
Who: super_admin, admin, admin_fleet, maintenance, asuransi, checker and viewer hold fleet_monitor:read.
Source: [Ref] Roles, The RLS pattern (vehicles_read lists vehicle:read and fleet_monitor:read).