VIA CRM Lead (Service Development) — Gap Analysis Review

VIA CRM Lead (Service Development) — Gap Analysis Review

Comparing current Odoo 17 CRM form against VIA Service Development spec · Generated March 14, 2026 · Task fe7887bf

How to use this document: Each change item shows what the spec asks for versus what currently exists. Click Agree (proceed with change) or Disagree (skip or modify). Add an explanation for any Disagree. When done, click Export YAML at the bottom — paste the output into a Claude chat to resume implementation planning.

0 of 0 items reviewed

Section 1 — SD Dashboard (Kanban Pipeline) 6 items
D-A Replace stage model with new 4-stage pipeline (date-driven, no manual drag) HIGH
Spec Says
4 stages: Inquiry → Discussion → Enrollment → Archive. Each stage triggered by specific date fields being populated (Inquiry Date, Referral Date/Referral Meeting Date, Projected Auth Date). Archive is triggered by user action with a required reason (see D-E).
Current State
Stages defined in database records, not XML. Current stage_type field has 3 values: introduction, discussion, activation. No automatic stage movement based on date fields. Stages are manually dragged in kanban.
Planned Action
Confirmed behavior: Stages move automatically on save based on date field state. No manual dragging. Stages can be skipped — if Inquiry Date and Projected Auth Date are both set in one save, the record lands at Enrollment (highest applicable stage).
  • Create/rename stage records: Inquiry, Discussion, Enrollment, Archive
  • Remap stage_type: introduction → Inquiry, discussion → Discussion, activation → Enrollment
  • Override write() to evaluate date fields in reverse priority order on every save:
    1. If Opportunity Status = Archive → Archive (overrides all)
    2. If project_auth_date is set → Enrollment
    3. If date_referral OR referral_meeting_date is set → Discussion
    4. If inquiry_date is set → Inquiry
  • Disable kanban drag-and-drop for stage changes (set statusbar clickable="False", kanban group_create="false")
  • The "activation path" is the overall workflow from Inquiry through to sale.order — not a specific stage
  • Required-field enforcement currently on stage_type == 'activation' transfers to the Enrollment stage or the Activate Authorization button validation
D-B Remove won stage / dual statusbar system HIGH
Spec Says
No "won" stage concept. Instead, authorized opportunities disappear from the pipeline (via "Activate Authorization" button launching sale.order). The spec's 4 stages do not include a "won" state.
Current State
VIA has a dual statusbar: primary stage_id (hidden when won) and secondary won_stage_id (visible when won, non-clickable). is_won_stage Boolean drives field requirements and partner_relative_id readonly. "Mark Won" and "Mark Lost" buttons are hidden but the won-stage logic is active.
Planned Action
  • Remove won_stage_id statusbar from the form view
  • Remove all is_won_stage-dependent visibility and required rules
  • Stage-based required attributes stay — update from stage_type == 'activation' or is_won_stage == True to stage_type == 'enrollment'. This preserves the greyish-blue visual indicator on required fields and prevents saving without them once the lead reaches Enrollment. Same mechanism as today, remapped to the new stage.
  • The Activate Authorization button (D-C) adds a second validation gate for the spec's starred fields before launching sale.order.
  • Keep "Mark Won"/"Mark Lost" hidden (already done)
D-C Add "Activate Authorization" button (greyed out until requirements met) HIGH
Spec Says
An "Activate Authorization" button on the form's right column. Can be clicked at any time during the process. Launches a sale.order form. Fields marked with * (Service Type, County of Service, Region of Service, Last Name, First Name, MA Number, Internal ID) must be filled before clicking.
Current State
No "Activate Authorization" button exists. Won-stage logic and action_sale_quotations_new() handle the transition to sale.order. The _handle_partner_assignment() method syncs data lead→partner when a quotation is created.
Planned Action
Two layers of enforcement (confirmed):
  • Layer 1 — Stage-based required attributes: Billing-critical fields (payer, payer_program, plan dates, priority) keep their required attribute in the XML, updated to required="stage_type == 'enrollment'". This preserves the greyish-blue fill color on required fields and prevents saving without them once the lead reaches Enrollment. Same mechanism as today, remapped from activation to enrollment.
  • Layer 2 — Button-click validation: The Activate Authorization button validates the spec's starred fields (Service Type, County/Region of Service, Last Name, First Name, MA Number, Internal ID) before launching sale.order. Some of these overlap with stage-required fields; others (like Service Type, County/Region) may not be stage-required but are needed for authorization.
  • Button behavior (confirmed): Button is always visible but greyed out (disabled) until all required fields are filled. Uses invisible or readonly attribute with a condition checking the starred fields.
  • On click: launches sale.order form, triggers _handle_partner_assignment() to sync 50+ fields lead→partner
  • Replaces the current quotation-from-won-stage flow (action_sale_quotations_new())
Must ensure _handle_partner_assignment() still fires on button click (it syncs 50+ fields lead→partner). The button's Python method should call the existing sync logic before opening sale.order.
D-D Update kanban card display fields LOW
Spec Says
Kanban cards show: Opportunity Name, Person Supported, Assigned to, Tags.
Current State
VIA does NOT customize the kanban view — it uses Odoo's standard crm.crm_case_kanban_view_leads. Standard kanban shows opportunity name, expected revenue, tags, activity icons, partner name.
Planned Action
Create an inherited kanban view that shows the spec's 4 fields. Remove revenue display (not relevant for service development). Add "Assigned to" (hr.employee field — new, see D-F).
D-E Archive with required reason (wizard pattern) and activity cancellation MEDIUM
Spec Says
Opportunities can be archived and reactivated. Users can search archived opportunities. "Archive" is Stage 4 in the pipeline. Note: Nurture campaigns run until prospect opts out. Long-term nurture is a best practice vs. archiving. Long-term nurture could be one email per quarter with a follow-up call scheduled if the email is opened.
Current State
Odoo base CRM has an active Boolean for archiving. VIA hides "Mark Lost" (which normally archives). No "Archive" stage exists. Current status field has values: pre_auth, authorized, inactive — no "Archive" value.
Planned Action
Archive is for leads that declare themselves no longer interested. It is not date-driven like the other 3 stages — it is triggered by a user action with a required explanation.
  • Add "Archive" stage to the pipeline (Stage 4)
  • Build an Archive wizard (modeled on VIA's existing employee departure wizard):
    — archive_reason_id: Many2one to a configurable reason model (VIA can add/edit reasons without code)
    — archive_description: Free text, required ("Give more details about why this opportunity is being archived")
    — archive_date: Auto-set to today or user-selectable
  • On archive: cancel all open/scheduled activities for this lead
  • No follower notification on archive (not required at this time)
  • Allow reactivation: move back from Archive stage, clear archive fields, restore to the stage matching current date field state
  • Add search filter for archived opportunities
  • Separate project: Automated follow-up cadences (chained event follow-up for non-responsive leads, escalating intervals) are out of scope for this form restructure. Leads that don't convert should eventually enter a long-tail follow-up sequence, but that's a CRM workflow/marketing automation project.
D-F Add "Assigned to" (hr.employee) and notification MEDIUM
Spec Says
"Assigned to" field: Many2one → hr.employee, required. If different from "Entered by" (auto-set to creating user), send notification.
Current State
Odoo base CRM has user_id (Salesperson, Many2one → res.users). No hr.employee-based assignment field exists. No "Entered by" field exists on crm.lead currently.
Planned Action
  • Add assigned_employee_id field (Many2one → hr.employee, required)
  • Add entered_by_user_id field (Many2one → res.users, default=current user, readonly)
  • Build notification logic: if assigned employee's user differs from entered_by, send message
  • Decide relationship to existing user_id (Salesperson) — keep, hide, or replace?
Odoo base CRM uses user_id (res.users) for assignment. The spec wants hr.employee. Should we keep user_id as well (some Odoo features depend on it), or hide it and use only the new employee field? What notification method — Odoo chatter message, email, or both?
Section 2 — Pre-Authorization Path (Main Form) 10 items
PA-A Restructure main form: replace lead_partner/lead_info with new layout HIGH
Spec Says
Two-column layout:
Left: Opportunity Name, Person Supported (auto from tab), Service Team, Service Line, Inquiry Date, Referral Date, Referral Meeting Date, Projected Auth Date, Projected Units, Funding Source.
Right: Activate Authorization button, Service Type, Supports Coordinator (Many2one → res.partner), SC phone/email (related), County of Service, Region of Service.
Bottom: Opportunity Status, Assigned to, Tags.
Current State
lead_partner group: contact_name, title, partner_relationship, firstname, lastname, DOB, email, phone, mobile, primary_language, address block.
lead_info group: gender, distinguish_region, assessment_date, graduating, legal_guardian, service_ids, company_type, internal_unique_id, ma_number, mci_number, program_type, funding_source, status_of_plan, plan dates, status, plan_tier, payer, payer_program, function, source_platform, partner_relative_id.
Most demographic fields are on the main form, not in tabs.
Planned Action
This is a fundamental restructure. Most current main-form fields move into tabs (Person Supported Details tab gets demographics, address, contact info). The main form becomes a Pre-Authorization workflow with date-driven fields. This affects:
  • ~25 fields removed from main form → moved to Person Supported Details tab
  • ~5 new fields added to main form (Service Team, Service Line, Inquiry Date, Opportunity Status, Assigned to)
  • Several existing fields repositioned (funding_source, projected_units stay; plan dates stay)
  • Opportunity vs Lead type distinction may need revisiting — spec doesn't reference the type='lead' vs type='opportunity' split
The current lead_partner and lead_info groups have different visibility rules for leads vs opportunities. The spec appears to unify these into a single form layout. Must confirm: does VIA still want the lead/opportunity type distinction, or is everything an "opportunity" in the new design?
PA-B Add "Service Team" and "Service Line" fields MEDIUM
Spec Says
Service Team: Selection LOV with values PDS, HCBS.
Service Line: Selection LOV filtered by Service Team — Supports Broker (PDS only), HTTS (PDS), IHCS (HCBS), Residential (HCBS). "Cannot appear in multi-select" note for Supports Broker.
Current State
No service_team or service_line fields exist on crm.lead. Odoo base has team_id (Many2one → crm.team) which is used for the sales team — different concept.
Planned Action
  • Add service_team selection field (PDS, HCBS)
  • Add service_line selection field with 4 values
  • Implement filtering: Service Line options change based on Service Team selection
  • Determine relationship to existing team_id (crm.team) — keep both? Map service_team to team_id?
The spec mentions "Service Line" is filtered by "Service Team". Should this be a domain filter (dynamic LOV) or hardcoded visibility? Also: should Service Team map to Odoo's existing team_id (crm.team record), or be a completely separate field?
PA-C Replace "Service Type" LOV with expanded spec values MEDIUM
Spec Says
16 service types with procedure codes: Supports Brokering (W7096), HTTS (H0043), IHCS (W7060), IHCS 2 (W7068), IHCS Enhanced (W7061), IHCS Enhanced 2 (W7069), Companion (W1726), Community Participation Support (W5996/W5997), Community Integration (97537), Licensed Residential Habilitation variants (W9001/W9000/W9029/W9030/W6093), Transportation (W7272). Required before Activate Authorization.
Current State
Current service_ids is a Many2many → product.product with many2many_tags widget. This allows MULTIPLE services. The spec says "Only 1 Service Type per opportunity" — fundamentally different data model (Selection vs Many2many).
Planned Action
  • Add new service_type selection field with the 16 spec values (including procedure codes as technical keys or separate field)
  • Keep or hide existing service_ids Many2many — don't delete to preserve historical data
  • New field enforces single selection per opportunity (as spec requires: "one per service type")
  • Procedure codes may need to be stored for billing integration
Service types with procedure codes (W7060, H0043, etc.) likely feed into billing and claims processes. Must verify whether these codes are used by Sandata or PROMISe APIs before changing.
PA-D Replace Support Coordinator (Char → Many2one) MEDIUM
Spec Says
"Supports Coordinator": Many2one → res.partner, domain filtered to Contact Type = "Supports Coordinator". Related fields for SC phone and SC email auto-populated from the linked contact.
Current State
support_coordinator is a Char field (free text). sc_phone_no is also Char (manually entered). No relational link to res.partner. These fields appear on the Pre-Authorization tab, not the main form.
Planned Action
  • Add new supports_coordinator_id (Many2one → res.partner, domain: contact_type = supports_coordinator)
  • Add related fields: sc_phone_related, sc_email_related from the linked partner
  • Move from Pre-Authorization tab to main form right column
  • Keep old Char fields temporarily for data migration, then deprecate
  • Migrate existing free-text SC names to matching res.partner records where possible
The existing support_coordinator Char field is in the partner→lead sync list (sync/partner-lead-sync.md). Changing to a Many2one requires updating all 3 sync methods (create, write, _handle_partner_assignment) plus the partner create method. Confirm this migration is desired.
SUPPORT COORDINATORS ARE ALWAYS CREATED AS RES.PARTNER unless you are planning to treat them as leads. If prospecting to build relationships with Support Coordinators is part of your plans, we should discuss.
PA-E Add "Inquiry Date" field (stage trigger) LOW
Spec Says
"Inquiry Date" — Date field, left column. Populating this triggers the Inquiry stage.
Current State
No inquiry_date field exists on crm.lead. date_referral exists (currently on Pre-Authorization tab).
Planned Action
Add new inquiry_date Date field to the main form left column. Connect to stage auto-advance logic (D-A).
PA-F Relocate date fields from Pre-Auth tab to main form MEDIUM
Spec Says
Main form left column includes: Referral Date, Referral Meeting Date, Projected Auth Date, Projected Units. These are currently on the Pre-Authorization tab.
Current State
date_referral, referral_meeting_date, project_auth_date, projected_units, authorized_date are all on the Pre-Authorization tab (group_1_pre_auth).
Planned Action
Move these fields from the Pre-Authorization tab to the main form left column. The Pre-Authorization tab may become empty or be removed (see PS-H). Note: authorized_date is NOT in the spec's main form — clarify if it's still needed.
Current authorized_date field exists on Pre-Auth tab but is NOT listed in the spec's main form. Is it being removed, or should it remain somewhere? Also: project_auth_date currently controls ISP Data tab visibility — this logic must be preserved even if the field moves.
PA-G Add "County of Service" and "Region of Service" with auto-populate MEDIUM
Spec Says
Right column: County of Service (Selection LOV, all PA counties, required*), Region of Service (Selection LOV: Central, Northeast, Southeast, West — auto-populates from County per ODP Appendix H map). Required before Activate Authorization.
Current State
pre_auth_county_id (Many2one → via.res.county) and pre_auth_region (Selection: western, central, north_east, south_east) exist on the Pre-Authorization tab. The existing distinguish_region on lead_info has the same 4 values with slightly different keys. The USPS module already has the county→region mapping for all 67 PA counties.
Planned Action
  • Move pre_auth_county_id and pre_auth_region from Pre-Auth tab to main form right column
  • Rename labels to "County of Service" and "Region of Service"
  • Implement auto-populate: when County is selected, Region fills automatically using the USPS module's county→region mapping
  • Resolve distinguish_region key mismatch (western on lead vs west in spec/partner) — spec says "West"
  • Make both required for Activate Authorization button
PA-H Replace "Opportunity Status" LOV LOW
Spec Says
Opportunity Status: Active, Hold, Archive. Bottom section of main form.
Current State
status field has values: pre_auth (Pre-Auth), authorized (Authorized), inactive (Inactive). Completely different set of values.
Planned Action
  • Replace status LOV values with: active, hold, archive
  • Migrate existing data: map pre_auth→active, authorized→ ?, inactive→archive
  • Move field position to bottom section of main form
  • "Archive" value triggers stage movement (ties to D-E)
The status field is in the partner→lead sync list. Partner has completely different values (active, inactive, discharged, deceased). The sync already has a mismatch — this change creates a third set of values. The sync logic for this field needs explicit handling.
PA-I Remove lead/opportunity type distinction HIGH
Spec Says
The spec describes a single form layout with no reference to lead vs opportunity types. All records appear to be "opportunities" in the SD pipeline. No mention of type='lead' anywhere.
Current State
Odoo CRM has a fundamental type field ('lead' vs 'opportunity'). VIA's form has separate field groups for each: lead_partner, lead_info (type=lead) and opportunity_partner (type=opportunity). Many fields are conditionally visible based on type. The lead_priority group hides tag_ids and priority for opportunities.
Planned Action
  • Set all SD records to type='opportunity' (or configure CRM settings to skip lead stage)
  • Remove type-conditional visibility rules from the form view
  • Consolidate field groups into the single spec layout
  • Keep type field on the model but always default to 'opportunity' for SD
Removing the lead/opportunity split is a major architectural change. Does VIA want to disable the lead stage entirely in CRM settings? Or keep it for other CRM uses outside SD? If there are non-SD CRM pipelines that use leads, those would be affected.
PA-J Remove fields from main form (moved to tabs or eliminated) MEDIUM
Spec Says
Main form contains ONLY the Pre-Authorization workflow fields. Demographics, contact info, address, and other identifying fields belong on the "Person Supported Details" tab.
Current State
Main form currently shows: contact_name, title, partner_relationship, firstname, lastname, DOB, email, phone, mobile, primary_language, address block, gender, distinguish_region, assessment_date, is_person_graduating, is_legal_guardian, service_ids, internal_unique_id_code, ma_number, mci_number, program_type, status_of_plan, status, plan_tier, payer, payer_program, function, source_platform, partner_relative_id.
Planned Action
Fields moving from main form to Person Supported Details tab:
  • Contact info: firstname, lastname, email, phone, mobile, address block
  • Demographics: DOB, gender, ma_number, internal_unique_id_code, sex, sexual_orientation, race, ethnicity, primary_language, religion, disabilities, mobility, living_arrangement
  • Removed from form entirely (not in spec): contact_name, title, partner_relationship, assessment_date, is_person_graduating, is_legal_guardian, mci_number, status_of_plan, plan_tier, payer, payer_program, function, source_platform, partner_relative_id
Note: Several "removed" fields (payer, payer_program, plan_tier) may need to stay somewhere for billing. The spec suggests some move to sale.order Authorization tab.
Fields being removed from the main form include API-connected fields: payer, payer_program (Sandata/billing), ma_number (PROMISe), source_platform (HCSIS/iRecord). These must remain accessible — either on a tab or on sale.order. Cannot simply delete them.
Section 3 — Person Supported Details Tab 5 items
PS-A Replace Demographics tab with "Person Supported Details" tab HIGH
Spec Says
New tab named "Person Supported Details" (replaces "Demographics"). Two columns:
Left: Last Name*, First Name*, Email, Mobile, Phone, Address (Line 1, Line 2, City/State/Zip), County of Residence, Region of Residence.
Right: DOB, MA Number*, Internal ID*, Sex, Gender, Sexual Orientation, Race, Ethnicity, Primary Language, Religion, Dev Disability, Intellectual Disability, Communication Plan, Mobility, Living Arrangement.
Current State
Demographics tab (demo_graphics) has: 2-column layout with race/ethnicity (col 1), sexual_orientation/religion (col 2), then radio widgets for disabilities, ethnicity HTML checkbox table, and notes. Contact info and demographics fields are split between main form and this tab.
Planned Action
  • Rename tab from "Demographics" to "Person Supported Details"
  • Restructure to 2-column layout per spec
  • Move contact info (name, email, phone, mobile, address) from main form into left column
  • Move demographic fields (DOB, ma_number, etc.) from main form into right column
  • Add County/Region of Residence (distinct from County/Region of Service on main form)
  • Remove radio widgets — all fields become standard Selection dropdowns per spec
  • Remove ethnicity HTML checkbox table
  • Remove duplicate ethnicity display and notes field from this tab
PS-B Implement contact search-and-link on name entry HIGH
Spec Says
PS-1: Typing Last Name or First Name triggers a search of existing res.partner contacts. User can select a match, which auto-populates all fields.
PS-2: If no match, prompt to create a new res.partner record via quick-add button.
Current State
partner_id (Many2one → res.partner) exists on the form header, hidden in lead mode, visible in opportunity mode. When set, partner→lead sync copies ~50 fields. firstname/lastname are computed from partner_id but also stored/editable.
Planned Action
  • Implement onchange on firstname/lastname that searches res.partner for matches
  • Show matching contacts as a dropdown or dialog for selection
  • On selection: set partner_id, which triggers existing partner→lead sync (all ~50 fields auto-populate)
  • If no match: show "Create New Contact" button that creates res.partner and links it
  • This replaces the current hidden partner_id field approach — the user never directly interacts with partner_id
Currently firstname/lastname on the lead are computed from partner_id but stored and editable. The spec's search behavior implies these fields become the entry point (type name → search → link). This inverts the current flow (select partner → populate names). Does VIA want the search to happen in real-time as the user types, or only when they tab out of the field?
PS-C Remove ethnicity detail checkboxes and radio widgets LOW
Spec Says
Demographics fields are simple Selection (LOV) dropdowns. No radio widgets, no HTML checkbox table for ethnicity breakdown.
Current State
Demographics tab uses radio widgets (horizontal) for: developmental_disability, commu_issue, mobility, living_arrangement, intellectual_disability. Plus an HTML table with 8 Boolean checkbox fields for ethnicity details (is_hispanic, is_mexican, is_puerto_rican, etc.). Plus a duplicate ethnicity field displayed as checkbox widget.
Planned Action
  • Change all radio widgets to standard Selection dropdowns
  • Remove the ethnicity detail HTML checkbox table (8 Boolean fields)
  • Remove duplicate ethnicity field display
  • Keep the Boolean fields on the model (don't delete data) but hide from the form
PS-D Align LOV values between spec, lead, and partner MEDIUM
Spec Says
Spec LOVs for Race: American Indian/Alaskan Native, Asian, Black/African American, Native Hawaiian/Pacific Islander, White, Other, Self-Described, Prefer not to say.
Religion: Christian, Buddhist, Hindu, Muslim, Jewish, Sikh, None, Other, Prefer not to say.
Current State
Race mismatches: Lead has native_other, partner has native_hawaiian. Lead has prefer_to_self_describe, partner has self_described. Spec says "Self-Described" (matches partner). Lead missing two_or_more. Spec says "Other" (matches partner's other), not lead's other_race_ethnicity_or_origin.
Religion mismatches: Lead has no_religion, partner has none. Spec says "None" (matches partner). Lead has another, partner has other. Spec says "Other" (matches partner).
Planned Action
  • Update crm.lead LOV technical keys to match the spec (which aligns with res.partner):
  • Race: native_other→native_hawaiian, other_race_ethnicity_or_origin→other, prefer_to_self_describe→self_described
  • Religion: no_religion→none, another→other
  • Region: western→west (if distinguish_region kept)
  • Add missing two_or_more to race on lead (spec doesn't include it — confirm)
  • Data migration: update existing records with old keys to new keys
  • This fixes the long-standing LOV mismatch issue documented in Session 3
LOV key changes require data migration scripts. Every existing crm.lead record with the old key values must be updated to the new keys, or those field values will become blank/invalid.
PS-E Add "County of Residence" and "Region of Residence" LOW
Spec Says
Person Supported Details left column includes: County of Residence (Selection, all PA counties), Region of Residence (Selection, auto-populates from County).
Current State
county_id (Many2one → via.res.county) exists on the address block. distinguish_region exists on lead_info. These are separate from pre_auth_county_id / pre_auth_region (which are "County/Region of Service" on main form). The spec distinguishes residence from service counties.
Planned Action
  • Use existing county_id as County of Residence (already on address block)
  • Use distinguish_region as Region of Residence (already computed/stored)
  • Move both to Person Supported Details tab, left column, after address
  • Implement auto-populate Region from County (same as County of Service, using USPS module mapping)
Section 4 — Notes Tab 2 items
NT-A Restructure Notes tab with spec fields MEDIUM
Spec Says
Notes tab with 4 fields:
1. "What information are you looking for?" (Text, auto-populate from web inquiry form)
2. "What services are you looking for?" (Text, auto-populate from web inquiry form)
3. "Notes" (Text, free form)
4. "Entered by" (Many2one → res.users, auto-populates to logged-in user who creates the opportunity)
Current State
Odoo base has internal_notes tab (page name internal_notes) with description_sale field. No "What information are you looking for?" or "What services are you looking for?" fields exist. pre_auth_notes exists but is shared between Demographics and Pre-Auth tabs. No "Entered by" field on crm.lead.
Planned Action
  • Add 2 new Text fields: inquiry_info_looking_for, inquiry_services_looking_for
  • Add entered_by_user_id (Many2one → res.users, default=current user, readonly) — same field as D-F if combined
  • Keep or repurpose existing internal_notes / description_sale as the "Notes" free text
  • Web inquiry form auto-population requires website form integration (separate scope)
The "auto-populate from web inquiry form" requirement implies a website form integration. Is that in scope for this project, or is it a future phase? If future, we'd create the fields now but skip the auto-population logic.
NT-B Remove shared pre_auth_notes field from Demographics/Pre-Auth LOW
Spec Says
Notes live on the Notes tab only. No notes fields on other tabs.
Current State
pre_auth_notes appears on BOTH the Demographics tab AND the Pre-Authorization tab — same database field displayed twice. Editing in either location changes the same value.
Planned Action
Remove pre_auth_notes from the Demographics and Pre-Authorization tabs. If the Notes tab uses a different field, decide whether to migrate existing pre_auth_notes data into the new Notes field.
Section 5 — Related Contacts Tab 3 items
RC-A Replace "Representative Details" tab with "Related Contacts" CRITICAL
Spec Says
"Related Contacts" tab (RC-1 through RC-7): Search existing res.partner contacts and associate them with the opportunity. Display as view-only cards (Name, Contact Type, Relationship, Title, Mobile, Email). Click to open full contact record. Remove associations. Sort alphabetically. Quick-add new contacts if they don't exist. Associations persist to res.partner when authorized. Required when "Self Initiated Inquiry" is NOT checked.
Current State
"Representative Details" tab captures one representative as flat text fields on the crm.lead: 12 representative_* fields (firstname, lastname, address, email, phone, mobile, notes). Visible only when partner_relationship != 'self'. On conversion, res_partner.py create() (lines 660–690) creates a child contact (partner_type='family_member') from these flat fields and sets crm_id.partner_relative_id to the new child's ID. The same child-creation code is commented out in _handle_partner_assignment().
Planned Action
These two systems cannot be merged — they are architecturally incompatible. The current system stores one person's data as flat Char fields on the lead and only creates a res.partner at conversion. The spec wants a Many2many link to existing res.partner records where multiple contacts can be searched, linked, and displayed.
  • Remove from form: Representative Details tab, all 12 representative_* field displays (keep fields on model for data integrity)
  • Remove from Python: Child contact creation in res_partner.py create() (lines 660–690), partner_relative_id assignment (line 698), commented-out representative block in _handle_partner_assignment()
  • Build new: Many2many field (e.g. related_contact_ids) on crm.lead → res.partner, with junction table storing relationship type per link
  • New tab: Kanban-style view-only cards with search/link widget and quick-add button
  • Persistence: On authorization, copy contact associations to the partner record (design for this depends on VIA's answer — see questions below)
  • Data migration: Existing leads with representative data need a migration script to create res.partner records from the flat fields and link them via the new Many2many
Workflow asymmetry: The spec requires related contacts (the inquiring parent, SC, family member) to exist as real res.partner records before the person supported converts. Currently, nobody becomes a res.partner until conversion — all data lives as flat fields on the lead. This means that during intake, the inquiring party would be created as a real contact immediately (via search-and-link or quick-add), while the person they're inquiring about remains as flat fields on the crm.lead until authorization. VIA must confirm this is the intended workflow.
Conversion logic in res_partner.py create() and _handle_partner_assignment() must be rewritten. The current child_ids creation (lines 660–690) and the partner_relative_id assignment are both replaced by the Many2many persistence mechanism.
Question 1: Do you want related contacts (the inquiring party, the SC, family members) to be created as real res.partner records during intake — before the person supported is authorized? This is what the spec implies (search existing contacts or quick-add new ones), but it's a change from the current workflow where nobody becomes a contact until conversion.
Question 2: Where does "Relationship to Person Supported" live? If the same person (e.g., a mother) is linked to two different opportunities for two different children, the relationship type needs to be stored on the junction table between the lead and the contact — not on the lead or the partner. Confirm this design.
Question 3: What does "persist to res.partner when authorized" mean concretely? Options: (a) create a matching Many2many on res.partner, (b) use the existing partner_relationship_ids field on res.partner, (c) create child_ids records as today, or (d) some other mechanism.
Question 4: Should existing leads with representative data (e.g., flat fields for a mother's name/phone/address) be migrated into real res.partner records and linked via the new Many2many?
RC-B Add "Self Initiated Inquiry" checkbox and related logic MEDIUM
Spec Says
RC-1: Related Contacts tab is required when "Self Initiated Inquiry" is NOT checked. This implies a checkbox exists somewhere (location not specified in spec — Q-6 asks "What is the Self Initiated Inquiry checkbox and where does it live?").
Current State
No "Self Initiated Inquiry" field exists on crm.lead. The current partner_relationship field (Self, Mother, Father, etc.) partially serves this role — when relationship is "Self", the person supported IS the inquiring party.
Planned Action
  • Add self_initiated_inquiry Boolean field
  • When checked: Related Contacts tab is optional
  • When unchecked: Related Contacts tab is required (must have at least one contact)
  • Determine placement: main form? Person Supported Details tab?
  • Consider relationship to partner_relationship field — if Self Initiated, relationship is implicitly "Self"
This is spec open question Q-6. Where should this checkbox live? Does it replace or complement the existing partner_relationship field? If the person supported is making their own inquiry (Self Initiated = Yes), does that mean partner_relationship should auto-set to "Self"?
RC-C Remove partner_relationship from main form MEDIUM
Spec Says
No partner_relationship field appears in any spec section. The concept is replaced by the Related Contacts tab's contact associations and potentially the Self Initiated Inquiry checkbox.
Current State
partner_relationship is on the main form (both lead_partner and opportunity_partner groups). It drives: Representative Details tab visibility, representative field required rules, child contact creation on conversion, is_legal_guardian visibility. It's in the partner→lead sync list. Default: 'self'.
Planned Action
  • Hide partner_relationship from the main form (don't delete — keep on model for data integrity)
  • Remove its role as Representative tab visibility driver (tab being replaced anyway — RC-A)
  • If Self Initiated Inquiry checkbox is added (RC-B), consider auto-setting partner_relationship based on it
  • Update partner→lead sync to handle the field being hidden but still synced
partner_relationship is in all 3 sync methods (create, write, _handle_partner_assignment). It also controls child contact creation during _create_customer(). Hiding it from the form is safe, but the model-level logic must be updated to use the new Related Contacts architecture.
Section 6 — Authorization Tab & Removed Elements 5 items
AU-A Add view-only Authorization tab (or defer to sale.order) HIGH
Spec Says
Authorization tab: view-only, shows all active authorizations in kanban format. Fields: Service Team, Service Type, Authorization Dates, Units, Region, County, Funding, Eligibility. Visible only when Contact Type = "Person Supported". ⚠️ Spec open question Q-4: "Consider removing this tab from crm.lead and moving it to sale.order."
Current State
No Authorization tab exists on crm.lead. The Pre-Authorization tab has editable fields for dates, SC info, and region/county. The payer/payer_program/plan_tier fields are on the main form (lead_info group). Authorization data currently lives scattered across CRM lead fields, not in a separate model.
Planned Action
Two options depending on Q-4 decision:
  • Option A: Build view-only Authorization tab on crm.lead that displays kanban cards from sale.order (requires sale.order integration)
  • Option B: Skip the tab on crm.lead, build authorization management entirely in sale.order (simpler, cleaner separation)
  • Additional fields mentioned: Payer ID, Payer Program, ICD10 Code, Modifier, EVV — all "consider for sale.order"
This is spec open question Q-4. The spec itself suggests moving Authorization to sale.order. If that's the decision, this tab would not be built on crm.lead at all — the "Activate Authorization" button (D-C) would simply launch sale.order where all authorization data lives. This significantly reduces CRM form complexity. Which option does VIA prefer?
AU-B Remove Pre-Authorization tab MEDIUM
Spec Says
The spec does not include a "Pre-Authorization" tab. Its fields are distributed: date fields and SC info move to the main form (PA-F, PA-D). County/Region move to main form (PA-G). Notes move to Notes tab (NT-B).
Current State
Pre-Authorization tab (pre_auth_details) has: date_referral, referral_meeting_date, project_auth_date, authorized_date, projected_units (left column); support_coordinator, sc_phone_no, pre_auth_region, pre_auth_county_id (right column); pre_auth_notes (bottom).
Planned Action
After moving all fields to their new locations (main form and Notes tab), remove the Pre-Authorization tab from the form view. Keep the page element in the XML but set invisible="1" to preserve inheritance stability, or remove it entirely if no other views inherit from it.
AU-C Remove ISP Data tab MEDIUM
Spec Says
The spec does not include an "ISP Data" tab. The spec's 5 tabs are: Person Supported Details, Notes, Related Contacts, Authorization, and (implicitly) Internal Notes from Odoo base.
Current State
ISP Data tab (isp_data) shows isp_ids (One2many → via.isp) with product_id and outcome_phrase columns. Conditionally visible when project_auth_date is set. On conversion, ISP records are moved (not copied) from lead to partner.
Planned Action
  • Hide the ISP Data tab from the CRM form
  • Keep isp_ids field on the model — ISP data may still be created and moved during conversion
  • If ISP data entry is needed, it would happen on the partner form (Referrals tab) after conversion
ISP records are currently moved from lead to partner on conversion. If the ISP Data tab is hidden from the lead form, where/when does ISP data get entered? Does it now get entered directly on the partner's Referrals tab instead?
AU-D Remove PA/NJ company-type conditional logic MEDIUM
Spec Says
The spec makes no reference to NJ-specific fields or PA/NJ conditional behavior. All LOVs and field visibility appear to be PA-only.
Current State
via_company_type (PA vs NJ) drives extensive conditional logic: distinguish_region visibility, assessment_date visibility, is_person_graduating visibility, is_legal_guardian conditions, mci_number label/visibility, source_platform default (HCSIS vs iRecord), program_type values (10 PA vs 2 NJ), ma_number required relaxation for NJ.
Planned Action
  • Remove company-type conditional visibility rules from the CRM form
  • Keep via_company_type field on the model (don't delete)
  • Simplify to PA-only behavior (all PA county/region LOVs, HCSIS default, etc.)
  • NJ-only fields (assessment_date, is_person_graduating) become hidden or removed
Is VIA fully PA-only now, or does NJ work still exist? If NJ is still active, removing company-type logic would break NJ users' experience. Confirm whether NJ operations have been discontinued.
AU-E Add Home Page card for Service Development LOW
Spec Says
"A Home Page card must be created for Service Development" (high-level business rule #1). This provides a navigation entry point to the SD Dashboard.
Current State
Service Development is accessible via the standard CRM menu. No custom home page card exists.
Planned Action
Create a home page card (Odoo 17 dashboard tile or menu item) that links directly to the SD Dashboard kanban view. This is a simple UI addition with no model changes.

Export Responses

Click to generate YAML for Claude ingestion. Paste into a new Claude chat to resume implementation planning.