Skip to content

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.

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)
  • 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).