Skip to main content

The whistleblower pivot

The single most useful key to the schema: the codebase was forked from a generic whistleblower / compliance-reporting platform and pivoted into a Portuguese disciplinary- process engine. Migration 20260228135542 is literally "the big pivot". Understanding this explains dozens of otherwise-baffling names and leftovers.

What the pivot did​

  • Renamed whistleblower_email → employee_email, is_from_whistleblower → is_from_employee (on case_messages, case_attachments).
  • Dropped categories, category_id, severity (whistleblowing taxonomy).
  • Migrated legacy roles: company_admin → hr_admin, case_handler → case_manager, viewer → case_manager; changed the default role.
  • Rewrote most RLS policies TO authenticated (closing anon holes from the WB era).

Leftovers that still leak (rebuild must decide keep/drop for each)​

  • cases.access_password TEXT NOT NULL — the WB case-access password, still required (plaintext access_password).
  • SITE_NAME = "open-whisper-hub" in auth-email-hook — leaks into email From: names.
  • English PRESET_CATEGORIES seeded by setup-company (Fraud, Harassment, Corruption, Retaliation…) — a whistleblowing taxonomy in a Portuguese disciplinary product.
  • Legacy app_role values (company_admin, case_handler, viewer) and legacy case_status values that can't be dropped from the PG enums (status generations).
  • .test sample domains and open-whisper-hub.lovable.app placeholders in email templates.

Rebuild implication​

Use the pivot as a checklist: for every whistleblower-era artifact, decide explicitly keep, rename, or drop. Don't carry vestigial names into a clean domain model. Normalise the enums.