Skip to main content

[Employer Sync 1.2] (Optional) JodGig data cleanup and real-mobile collection plan

TL;DR: Two optional tracks in JodGig itself — mark the 57 obsolete-company orphan users is_deleted = 1, and add a JodGig-portal form so HQ / AREA / LOCATION users can enter their real personal mobile before migration.

Context​

The data audit found that JodGig data is mostly clean for the migration. Two items remain that the JodApp-side sync cannot fix on its own — they live in JodGig.

Problem​

  • The 57 employer users on the 11 obsolete companies stay in JodGig as enabled rows, even though the company sync will never migrate their companies. They are migration orphans by design — they show up in audit queries forever and add noise.
  • 1,047 employers (32%) share a contact_number with at least one other employer (one office number is used by 107 sub-accounts). The migration carries a placeholder mobile so the row inserts cleanly, but the real personal mobile is missing for those users — and we want it for WhatsApp / SMS transactional notifications.

This issue is a plan, not a hard blocker. The sync works without it.

Direction​

Two parallel tracks, each can be deferred independently:

Track A — clean up the orphan employers in JodGig.

  • Run a one-off script that sets users.is_deleted = 1 for the 57 employer users whose company_id is in OBSOLETE_REMOTE_COMPANIES_IDS.
  • Coordinate with whoever owns JodGig production — this writes to a live system, so approval and a backup come first.
  • Effect: cleaner audit queries from now on; no functional change to the sync (which already skips them).

Track B — collect real personal mobiles before migration.

  • Add a small "Confirm your mobile number" form in the JodGig employer portal (jodgig-frontend) for HQ, AREA, LOCATION users.
  • They enter their personal mobile; jodgig stores it; the next sync run picks it up via the normal mapping.
  • This is gentler than asking every migrated employer in JodApp (issue 6.4 does that, but having a real mobile from day one is better).

Acceptance​

  • Decision recorded for Track A — run the obsolete-user cleanup, or leave the rows as audit noise.
  • Decision recorded for Track B — build the JodGig-side mobile form, or rely only on JodApp's first-login prompt (issue 6.4).
  • If either track is chosen, a follow-up issue is created in the relevant repo.