DRV · Drivers
There is one drivers row per person, from lead to leaving, labelled by stage. Documents, addresses, emergency contacts, platform accounts, notes and trainings are child rows. legacy_id keeps v1's lead number. Code DRV.
Not yet a rule
Section titled “Not yet a rule”These questions are open in #79. Each gets a rule with a new ID once it is answered.
- DRV open 1 · Stage history
- DRV open 2 · Source notes
- Queue form fields: OQ8 (#34)
- Who sees NIK, phone, company_amount and margin: OQ9 (#35)
R-DRV-01 · A NIK is exactly 16 digits
Section titled “R-DRV-01 · A NIK is exactly 16 digits”- Status: planned
- Example: given a new driver, when the NIK is saved as 32750112345 (11 digits), then it is refused.
- Refusal: none: check_violation (23514).
- Who: every writer.
- Source: [Ref] Database rules and conventions, Normalized input; [Ref] Data model V13: drivers.
R-DRV-02 · A NIK is unique within the organization
Section titled “R-DRV-02 · A NIK is unique within the organization”- Status: planned
- Example: given a driver with NIK 3275011234567890, when a second driver with that NIK is saved in the same organization, then it is refused.
- Refusal: none: unique_violation (23505).
- Who: every writer.
- Source: [Ref] Data model V13: drivers; D9 (P3).
R-DRV-03 · A v1 lead number (legacy_id) is unique within the organization
Section titled “R-DRV-03 · A v1 lead number (legacy_id) is unique within the organization”- Status: planned
- Example: given a migrated driver with legacy_id 1042, when a second driver with 1042 is saved, then it is refused.
- Refusal: none: unique_violation (23505).
- Who: every writer, the migration included.
- Source: [Ref] Data model V13: drivers.
R-DRV-04 · Every driver has a lead source
Section titled “R-DRV-04 · Every driver has a lead source”- Status: planned
- Example: given a new driver, when it is saved with no lead source, then it is refused.
- Refusal: none: not_null_violation (23502).
- Who: every writer.
- Source: [Ref] Data model V13: drivers, lead_sources.
R-DRV-05 · A new driver starts at the lead stage
Section titled “R-DRV-05 · A new driver starts at the lead stage”- Status: planned
- Example: given a driver registered with no stage, when it is read back, then its stage is lead.
- Refusal: none.
- Who: every writer.
- Source: [Ref] Data model V13: drivers.
R-DRV-06 · App users can't change a driver's stage directly; only database functions can
Section titled “R-DRV-06 · App users can't change a driver's stage directly; only database functions can”- Status: planned
- Example: given an admin_driver, when she updates drivers.stage from lead to approved, then it is refused and the stage stays lead.
- Refusal: driver.stage_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.
R-DRV-07 · Changing a driver's stage needs driver:write, onboarding:write, screening:approve, booking:write or inspection:handover at the driver's pool
Section titled “R-DRV-07 · Changing a driver's stage needs driver:write, onboarding:write, screening:approve, booking:write or inspection:handover at the driver's pool”- Status: planned
- Example: given a finance user at PML, when she calls app.set_driver_stage on a PML driver, then it is refused; a background_check user at PML may.
- Refusal: driver.stage_forbidden
- Who: super_admin, admin, admin_driver, admin_fleet, background_check and checker hold one of these.
- Source: [Ref] Database rules and conventions, Status and stage only through functions.
R-DRV-08 · A stage change records when it happened
Section titled “R-DRV-08 · A stage change records when it happened”- Status: planned
- Example: given a driver at screening, when app.set_driver_stage moves her to approved at 10:15, then stage_changed_at reads 10:15.
- Refusal: none.
- Who: app.set_driver_stage and every function that calls it.
- Source: [Ref] Database rules and conventions, Status and stage only through functions.
R-DRV-09 · A driver has at most one address of each kind (KTP, domicile)
Section titled “R-DRV-09 · A driver has at most one address of each kind (KTP, domicile)”- Status: planned
- Example: given a driver with a KTP address, when a second KTP address is saved, then it is refused; a domicile address is accepted.
- Refusal: none: unique_violation (23505).
- Who: every writer.
- Source: [Ref] Data model V13: driver_addresses.
R-DRV-10 · A postal code is exactly 5 digits
Section titled “R-DRV-10 · A postal code is exactly 5 digits”- Status: planned
- Example: given a new address, when its postal code is saved as 1541, then it is refused; 15417 is accepted.
- Refusal: none: check_violation (23514).
- Who: every writer.
- Source: [Ref] Data model V13: driver_addresses.
R-DRV-11 · A driver has at most one primary emergency contact
Section titled “R-DRV-11 · A driver has at most one primary emergency contact”- Status: planned
- Example: given a driver whose wife is the primary contact, when his brother is also saved as primary, then it is refused.
- Refusal: none: unique_violation (23505).
- Who: every writer.
- Source: [Ref] Data model V13: driver_emergency_contacts.
R-DRV-12 · A driver has at most one account per ride platform
Section titled “R-DRV-12 · A driver has at most one account per ride platform”- Status: planned
- Example: given a driver with a Grab account row, when a second Grab row is saved, then it is refused.
- Refusal: none: unique_violation (23505).
- Who: every writer.
- Source: D9 (P4).
R-DRV-13 · A driver is linked to at most one login
Section titled “R-DRV-13 · A driver is linked to at most one login”- Status: planned
- Example: given a login linked to driver A, when driver B is linked to the same login, then it is refused.
- Refusal: none: unique_violation (23505).
- Who: every writer.
- Source: [Ref] Data model V13: drivers.profile_id.
R-DRV-14 · A SIM number equal to the driver's NIK is migrated empty, until the SIM is re-checked
Section titled “R-DRV-14 · A SIM number equal to the driver's NIK is migrated empty, until the SIM is re-checked”- Status: planned
- Example: given a v1 driver whose SIM number equals his NIK, when he is migrated, then his SIM document has no number.
- Refusal: none.
- Who: the migration.
- Source: D9 (Q9).
R-DRV-15 · A driver is readable with driver:read, screening:read, onboarding:read, booking:read, payment:read, inspection:read, gate:read or debt_letter:read at the driver's pool
Section titled “R-DRV-15 · A driver is readable with driver:read, screening:read, onboarding:read, booking:read, payment:read, inspection:read, gate:read or debt_letter:read at the driver's pool”- Status: planned
- Example: given a satpam at PML, who holds gate:read, when he reads drivers, then PML's drivers come back.
- Refusal: none: hidden.
- Who: every system role holds at least one of these.
- Source: [Ref] Roles, policy matrix.
R-DRV-16 · Adding or changing a driver or its child rows needs driver:write at the driver's pool
Section titled “R-DRV-16 · Adding or changing a driver or its child rows needs driver:write at the driver's pool”- Status: planned
- Example: given a checker at PML, when he edits a PML driver's address, then nothing changes; an admin_driver at PML may.
- Refusal: none: insufficient_privilege (42501) on insert; no effect on update.
- Who: super_admin, admin and admin_driver hold driver:write.
- Source: [Ref] Roles, policy matrix.
R-DRV-17 · Deleting a driver needs driver:delete at the driver's pool
Section titled “R-DRV-17 · Deleting a driver needs driver:delete at the driver's pool”- Status: planned
- Example: given an admin, when he deletes a driver registered twice by mistake, then nothing is deleted; a super_admin's delete goes through when nothing references the row (R-CONV-11).
- Refusal: none: no effect without the permission.
- Who: super_admin holds driver:delete.
- Source: [Ref] Roles, policy matrix; D9 (P13).