Drop the UNIQUE constraint on sales_agents.email (migration 084) so a single agent (person/company) can hold several referral codes, each with its own client discount and commission split. All commission lookups already key on the unique agent_code, so no lookup logic changes. Agent-creation endpoint now: - accepts repeat emails (creates an additional code instead of 409) - accepts client_discount_value, commission_type, commission_pct per code - reports existing codes for the email in the response Both Jay Kordic codes (REF-JKORDIC 7%/12%, REF-JAYK05 5%/15%) now share his real email jay_kordic@thehorizongroup.biz.
23 lines
1 KiB
PL/PgSQL
23 lines
1 KiB
PL/PgSQL
-- 084_multi_code_per_agent.sql
|
|
-- Allow a single sales agent (person/company) to have MULTIPLE referral codes,
|
|
-- each with its own client discount and agent commission split.
|
|
--
|
|
-- Background: each sales_agents row already represents one referral code
|
|
-- (it owns a unique agent_code and links to one discount_code). The only thing
|
|
-- that blocked the same person from having several codes was the UNIQUE
|
|
-- constraint on sales_agents.email. We drop that constraint (keeping a plain
|
|
-- index for lookups) so the same email can back several codes/splits.
|
|
--
|
|
-- All commission/referral lookups key on the unique agent_code, so no other
|
|
-- logic changes are required at the DB level.
|
|
|
|
BEGIN;
|
|
|
|
-- Drop the UNIQUE constraint on email (name is auto-generated by Postgres).
|
|
ALTER TABLE sales_agents DROP CONSTRAINT IF EXISTS sales_agents_email_key;
|
|
|
|
-- Keep a non-unique index so email lookups stay fast.
|
|
-- (idx_agents_email already exists from migration 011; create defensively.)
|
|
CREATE INDEX IF NOT EXISTS idx_agents_email ON sales_agents (email);
|
|
|
|
COMMIT;
|