VIA Contact Form (res.partner) — Gap Analysis Review
Comparing current Odoo 17 Contact form against VIA res.partner spec · Generated March 17, 2026 · Updated April 7, 2026 (AUTH section cross-referenced with Authorization module) · 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 30 items reviewed
48–72
Estimated Total Hours
30
Change Items
5
Sections
Section 1 — Main Contact (Header)
9 items · ~12–16 hrs
▶ 14 items already implemented — no changes needed (click to expand)
✓ Contact Type in right column, required
✓ Relationship to Person Supported — Many2many tags, conditional visibility
✓ Pronouns — free text in right column
✓ Email, Mobile, Phone repositioned to left column above address
✓ County of Residence inside address block
✓ Region of Residence after address block
✓ Service Team(s) — Many2many tags, conditional visibility
✓ Service Line(s) — Many2many tags, conditional visibility
✓ Status field in right column
✓ Tags (category_id) in right column
✓ Title field hidden
✓ VAT and Website fields hidden
✓ Job Position (function) field hidden
✓ GeoLocation and Contacts Label groups hidden
H-A
Remove "Employee" from Contact Type dropdown
MEDIUM
IN PROGRESS
~3 hrs
Spec Says
MC-LOV-1 lists Employee as "REMOVED per testing". Final Contact Type list has 8 values (no Employee).
Current State
employee exists in partner_type selection (9 values). Used in visibility rules for Service Team(s) and Service Line(s): partner_type in ('person_support', 'employee').
Planned Action
Remove employee from the selection list. Update visibility conditions that reference it. Audit existing records for data migration. Check via_roles for security rules referencing this value.
Existing partner records with Contact Type = Employee would have an orphaned value. What should those records become?
H-G
Remove Individual/Company radio buttons
LOW
IN PROGRESS
~0.5 hrs
Spec Says
MC-11: Remove the Individual/Company radio buttons. Marked as TBD in spec's open questions.
Current State
Base Odoo company_type radio buttons (Individual/Company) likely still visible at top of form.
Planned Action
Hide the radio buttons. Default is_company to False. Will not proceed until confirmed since spec marks this TBD.
Are companies established as contacts in res.partner, or elsewhere? This determines whether the radio buttons are still needed.
H-H
Region auto-populates from County (ODP Appendix H)
MEDIUM
BLOCKED
~2 hrs
Spec Says
MC-3: Region of Residence auto-populates based on County using ODP Appendix H mapping.
Current State
County-to-region mapping data exists in the USPS address validation module. Both fields are on the form but Region does not auto-fill when County changes.
Planned Action
Add @api.onchange('county_id') method to auto-set distinguish_region from existing ODP mapping data. User can still override manually.
RC-B
"Add Related Contact" — search/link existing vs. create new
HIGH
~6–10 hrs
Spec Says
RC-1/RC-2: "Add Related Contact" opens a search for existing contacts. If not found, user clicks "NEW" to create, then links it.
Current State
Uses child_ids (One2many via parent_id). "Add" creates a new child contact inline. No search for existing contacts.
Planned Action
Two options:
Option A (Less disruptive): Keep parent-child structure but customize the "Add" button to open a search dialog. Selecting an existing contact sets its
parent_id. Preserves all existing relationships.
Option B (Larger change): New Many2many field for related contacts, replacing
child_ids. A contact can relate to multiple people without changing its parent_id. Requires data migration.
Which approach do you prefer? Or is there a different relationship model you have in mind?
RC-C
Allow related contacts to be unlinked (not deleted)
LOW
IN PROGRESS
~1 hr
Spec Says
RC-4: Allow related contacts to be removed (unlinked from relationship).
Current State
Standard child_ids kanban has remove action. Should clear parent_id (unlink) not delete, but needs verification.
Planned Action
Verify current remove action does NOT delete the contact record. If it deletes, change to unlink only.
RC-E
Relationship field on cards — legacy vs. new field
MEDIUM
~2 hrs
Spec Says
Cards show "Relationship to Person Supported." Doesn't specify which underlying field.
Current State
Cards show legacy partner_relationship (Selection, 11 values). Newer partner_relationship_ids (Many2many) exists in header but is NOT on kanban cards.
Planned Action
Decision needed: show old Selection (backward compatible — existing data displays) or new Many2many (forward-looking — old records show blank until migrated)?
Existing child contacts have data in the legacy field. Switching to the new field without migration would cause relationship info to disappear from cards.
Section 3 — Personal Details Tab
8 items · ~8–10 hrs
▶ 18 items already implemented (click to expand)
✓ Tab visible only for Person Supported
✓ Three-column layout (Identifiers, Identity, Functional)
✓ DOB, MA Number, Internal ID in Column 1
✓ Sex — 3 values match spec
✓ Gender, Sexual Orientation, Race, Ethnicity, Primary Language, Religion in Column 2
✓ Developmental Disability, Intellectual Disability, Communication Plan, Mobility, Living Arrangement in Column 3
✓ All LOV values match spec (except items below)
✓ All fields populate from CRM.lead on creation (sync confirmed)
PD-A
Remove "Not listed" from Gender dropdown
MEDIUM
~1.5 hrs
Spec Says
PD-5: Remove "Not listed" from Gender LOV. Final list: 9 values (Woman, Man, Non-Binary, Self-Describe, Prefer not to say, Transgender, Cisgender, Agender, Genderqueer).
Current State
Gender has 10 values including not_listed. Same field exists on crm.lead in the sync list.
Planned Action
Remove not_listed from selection on both res.partner and crm.lead. Check existing records for migration. Determine replacement value for existing data.
What should existing records with gender = "Not listed" be migrated to? (Likely "Prefer not to say" or "Self-Describe")
PD-B
Remove "Other" from Race dropdown
MEDIUM
~1.5 hrs
Spec Says
PD-6: Remove "Other" from Race LOV. Final list: 8 values. Race has LOV key mismatches between crm.lead and res.partner.
Current State
Race has 9 values including other. Known LOV key mismatches with crm.lead (3 key differences + 1 missing value).
Planned Action
Remove other from selection on both models. Coordinate with LOV key mismatch fix. Determine replacement value for existing data (likely "Self-Described").
Race LOV has key mismatches between crm.lead and res.partner — this removal should be coordinated with the mismatch fix to avoid compounding sync issues.
PD-C
Free text box when Gender = "Self-Describe"
LOW
~1 hr
Spec Says
PD-4: If Gender is "Self-Describe," show free form text box for custom entry.
Current State
No conditional text box. "Self-Describe" just sets the selection value.
Planned Action
Add new Char field (e.g., gender_self_describe) visible only when gender = 'self_describe'. Add to both res.partner and crm.lead models + sync list + both form views.
PD-D
Free text box when Sexual Orientation = "Self-Describe"
LOW
~1 hr
Spec Says
If Sexual Orientation is "Self-Describe," show free form text box.
Current State
No conditional text box exists.
Planned Action
Same pattern as PD-C: new Char field sexual_orientation_self_describe, visible conditionally. Both models + sync.
PD-E
Free text box when Race = "Self-Described"
LOW
~1 hr
Spec Says
If Race is "Self-Described," show free form text box.
Current State
No conditional text box exists.
Planned Action
Same pattern: new Char field race_self_describe, visible conditionally. Both models + sync.
PD-F
Free text box when Primary Language = "Other"
LOW
~1 hr
Spec Says
PD-7: If Primary Language is "Other," show text box for custom language entry.
Current State
No conditional text box exists.
Planned Action
Same pattern: new Char field primary_language_other, visible conditionally. Both models + sync.
PD-G
Rename "Internal Unique ID" label to "Internal ID"
LOW
~0.25 hrs
Spec Says
PD-3: Label changed from "Internal Unique ID" to "Internal ID".
Current State
Field label is "Internal Unique ID Code" (from model string).
Planned Action
Change field string or add view-level label override to display "Internal ID".
PD-H
Reduce spacing between Internal ID and Developmental Disability
LOW
~0.5 hrs
Spec Says
PD-8: Remove some space between Internal ID and Developmental Disability sections (UI adjustment).
Current State
Column 1 has 3 fields, Column 3 has 5 — height difference creates whitespace.
Planned Action
CSS/layout adjustment. Deferred to final layout pass after all functional changes are complete.
Section 4 — Authorization Tab
5 items · ~14–22 hrs
⚠ Major Architectural Change — Context Updated April 2026: The
via_authorization module is now live on staging (DB-1 through DB-7 complete). sale.order has been renamed "Authorization" system-wide. The current editable Authorization tab on res.partner is being replaced with a new view-only kanban tab that reads from sale.order (Authorization) records. API-connected fields (payer, payer_program, source_platform, team_ids) remain in the res.partner data model — they are now edited on the Authorization (sale.order) form and synced back to the partner.
AUTH-A
Remove editable pre-authorization fields from this tab
CRITICAL
~2 hrs
Spec Says
Remove the Pre-Authorization tab from res.partner entirely. Pre-auth data moves to CRM.lead only. Client confirmed (CRM AU-A): "Do not build this tab in CRM.lead, move to Sale.order and a view only tab will be in Res.partner when Contact type = Person supported."
Current State
13 editable fields on the existing tab (owned by via_tab_authorization, priority 25): payer, payer_program, source_platform, authorized_date, pre_auth_region, pre_auth_county_id, projected_units, sc_phone_no, team_ids, primary_team_id, user_id, partner_activation_status, pre_auth_notes. Four are API-connected.
Planned Action
Remove ALL current fields from the tab view XML (via_tab_authorization). Fields remain in the res.partner model — API integrations (Sandata, PROMISe) continue reading from the model. Users will edit billing-critical fields on the Authorization (sale.order) form instead. The via_authorization module (DB-1 through DB-7, now live on staging) provides the new editing surface.
API-connected fields: payer (Sandata + PROMISe), payer_program (Sandata), source_platform (PROMISe), team_ids (Sandata). These fields are now editable on the Authorization (sale.order) form. A sync mechanism must write values back to res.partner so API integrations continue to read them from the partner record.
Cross-reference: CRM AU-A (move auth tab to sale.order), Auth AH-1 (header fields from crm.lead), Auth SL-9 (payer/payer_program on sale.order.line). DB-7 rename is COMPLETE — sale.order is now labeled "Authorization" in menus, breadcrumbs, and actions.
AUTH-B
Build new view-only Authorization tab with kanban cards
HIGH
~8–12 hrs
Spec Says
AUTH-2/AUTH-4: View-only tab. Active authorizations as kanban cards. Tab header: Region of Service, County of Service, Eligibility (Yes/No/Error), Last Eligibility Check.
Current State
No kanban authorization view exists on res.partner. The via_authorization module is now live on staging — it owns the sale.order list/form/search views (DB-1 through DB-7). sale.order records ARE the authorization records. The data source question is answered: sale.order records linked via partner_id.
Planned Action
Build a new view-only tab on res.partner (visible when partner_type = 'person_support') that displays the person's sale.order records as kanban cards. Each card shows: Service Type (from sale.order.line product), Authorization Dates, Units Remaining, Funding Source. Tab header shows: Region of Service, County of Service, Eligibility status, Last Eligibility Check date. This tab replaces the current editable tab removed in AUTH-A.
Cross-reference: Auth DB-1 (list view is read-only, verified), Auth DB-2 (search filters exist), Auth DB-4 (native checkboxes for bulk select), Auth DB-5 (duplicate with date override wizard). The sale.order infrastructure this tab reads from is built and working.
Deferred kanban card decisions (from Auth gap analysis): How to display multi-service authorizations (one card per SO vs one card per SO line)? How to calculate "units remaining" formula?
AUTH-C
Combine Authorization, Eligibility, and Service Line tabs
MEDIUM
~2 hrs
Spec Says
AUTH-3: Combine Authorization, Eligibility, and Service Line tabs into one unified tab.
Current State
Three separate tab modules exist on res.partner: via_tab_authorization (priority 25), via_tab_eligibility (if present), and via_tab_service_lines (shows service line header with Region/County). The new AUTH-B kanban tab will consolidate all three into a single "Authorization" tab with eligibility in the header and service lines visible within kanban cards.
Planned Action
When AUTH-B is built, hide or remove the separate Eligibility and Service Line tabs. All relevant data appears within the unified Authorization tab: eligibility status in the tab header (AUTH-D), service lines within each kanban card. Follows the One Module One Tab principle — the new tab module owns the combined view.
Cross-reference: Per the via-notebook-tab-architecture skill, each tab has an owning module and a priority. The replacement tab should claim priority 25 (same slot as the current
via_tab_authorization) and the other two tabs should be deactivated or hidden.
AUTH-D
Add Eligibility fields to tab header
MEDIUM
~3 hrs
Spec Says
AUTH-7/AUTH-8: Eligibility (Yes/No/Error) and Last Eligibility Check (date), plus Region and County of Service — displayed in the tab header above the kanban cards.
Current State
No eligibility_status or last_eligibility_check fields exist on res.partner. PROMISe EDI (270/271 transactions) performs eligibility checks but results are not currently stored as partner-level fields. Region exists as pre_auth_region (Selection) and County as pre_auth_county_id (Many2one → via.res.county) — both synced from crm.lead. These are pre-authorization concepts; the tab header needs to show the active service region/county which may differ.
Planned Action
New fields on res.partner: eligibility_status (Selection: yes/no/error/pending), last_eligibility_check (Datetime). Populated by PROMISe 271 response processing. Region/County of Service in the tab header: if a person has only one active authorization, display its region/county; if multiple authorizations exist with different regions, display "Multiple" or aggregate. The per-line region/county lives on sale.order.line (Auth SL-7/SL-8, not yet built).
Cross-reference: Auth SL-7 (region_of_service on sale.order.line), Auth SL-8 (county_of_service_id on sale.order.line), Contact H-H (county auto-populate from ODP Appendix H — BLOCKED). Note: County of Residence (H-H) ≠ County of Service (this item). PROMISe EDI skill covers 270/271 eligibility transaction format.
Should the tab header show a computed aggregate of region/county across active authorizations, or the partner-level pre_auth values? Does the PROMISe 271 response handler need to be built before this item can be completed?
AUTH-E
Funding Source at service line level, not partner level
HIGH
~4 hrs
Spec Says
AUTH-5/AUTH-6: Funding Source and authorization dates must be at the service line level — can differ per service line within the same authorization.
Current State
funding_source is a single Selection field on res.partner — one value per person. No per-service-line structure exists yet. The Authorization gap analysis specifies funding_source on sale.order.line (Auth SL-11) and auth_start_date / auth_end_date on sale.order.line (Auth SL-3). These SL items are not yet built — they are the next implementation phase after DB-1 through DB-7.
Planned Action
The architecture is confirmed: sale.order.line will carry per-service funding_source, auth_start_date, and auth_end_date. The partner-level funding_source field becomes legacy — it may be kept as a computed "primary" value or removed entirely. On the res.partner Authorization tab (AUTH-B), each kanban card will display the per-line funding source and date range from the linked sale.order.line records. This item is architecturally dependent on Auth SL-3 and SL-11 being built first.
Cross-reference: Auth SL-3 (auth_start_date/auth_end_date on sale.order.line — NOT YET BUILT), Auth SL-11 (funding_source on sale.order.line — NOT YET BUILT), Auth SL-9 (payer/payer_program on sale.order.line), Auth OQ-2 (funding source purpose unclear — needs client clarification).
Auth OQ-2 flagged that the purpose of funding_source is unclear ("PA PROMISe ???"). Client clarification needed: is funding_source the same as payer_program, or a separate concept? This affects whether it's redundant with SL-9.
Section 5 — Removed Tabs & General Rules
3 items · ~4–8 hrs
▶ 3 items already implemented (click to expand)
✓ Sales & Purchases tab hidden unconditionally (via_roles, priority 400)
✓ Accounting tab hidden unconditionally (via_roles, priority 400)
✓ Internal Notes tab hidden unconditionally (via_roles, priority 400)
RT-A
Internal Notes: spec says remove for Physician only, currently hidden for ALL
LOW
~0.5 hrs
Spec Says
MC-7: Remove Internal Notes tab when Contact Type = Physician. (Implies visible for other types.)
Current State
Hidden for ALL contact types unconditionally (invisible="1", priority 400).
Planned Action
Spec and current state disagree. Two options: (a) Keep hidden for everyone (simpler), or (b) Make visible for all except Physician (matches spec). Will not change until confirmed.
Keep Internal Notes hidden for everyone (current), or show for non-Physician contacts (spec)?
RT-B
Remove all CRM/Service Development links from contact form
LOW
~1.5 hrs
Spec Says
Remove all links to CRM and Service Development from the contact form.
Current State
action_view_opportunity smart button exists with effect=False (visible but non-functional, Studio 9475). Other CRM links may exist.
Planned Action
Set action_view_opportunity to invisible="1". Audit for other CRM links and hide them.
RT-C
Person Supported contacts created via CRM.lead only
MEDIUM
~2–4 hrs
Spec Says
Users will NOT create Person Supported contacts directly — only through CRM.lead workflow.
Current State
Users can create a contact and set partner_type = 'person_support' directly. CRM conversion also works (from_crm=True).
Planned Action
Options: (a) Remove "Person Supported" from Contact Type dropdown on new records only, or (b) Add validation blocking save with partner_type = 'person_support' unless from_crm context is set. CRM conversion flow continues normally.
Should "Person Supported" still appear in the dropdown on existing records? Or hidden entirely and only set programmatically?
Export Responses
Click to generate YAML for Claude ingestion. Paste into a new Claude chat to resume implementation planning.
✅ Completed Items (Implemented)
8 items — click to expand/collapse
H-B
Narrow visibility of "Relationship to Person Supported" field
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-1: Field appears only when Contact Type is Supports Coordinator, Family Member, Common Law Employer, Managing Employer, or Physician.
Current State
Visible for ALL non–Person Supported contacts (partner_type != 'person_support') — including Employee, 1099 Contractor, and Other.
Planned Action
Change the visibility rule to: partner_type not in ('support_coordinator', 'family_member', 'common_law_employer', 'managing_employer', 'physician'). Field hidden for 1099 Contractor and Other.
H-C
Service Line(s) visibility depends on Service Team selection
MEDIUM
COMPLETED
~2 hrs
Spec Says
MC-5: Service Line(s) visible only when Contact Type = Person Supported AND Service Team includes PDS or HCBS.
Current State
Visible whenever partner_type in ('person_support', 'employee') — no team filtering.
Planned Action
Add logic so Service Line(s) only appears when at least one selected Service Team is PDS or HCBS. Requires computed field or onchange since team_ids is Many2many.
H-D
Status dropdown values vary by Contact Type
LOW
COMPLETED
~1 hr
Spec Says
MC-6: Person Supported gets 4 values (Active, Inactive, Discharged, Deceased). All others get 3 (no Discharged).
Current State
All 4 values available to all contact types.
Planned Action
Add domain filter to hide "Discharged" when partner_type != 'person_support'. Check existing non-PS records for orphaned Discharged values.
H-E
Remove Physicians field from the form
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-9: Remove Physicians field — physicians will be Related Contacts instead.
Current State
physician_ids Many2many is hidden by default, then made visible for Person Supported by the post-Studio override (priority 365).
Planned Action
Remove the post-Studio override that makes physician_ids visible. Field stays in the model (no data loss). Existing physician links remain in data but are not visible on the form.
Users would need to re-establish physician links as Related Contacts if they want to see them on the form.
H-F
Change "Contact" label to "Address" (no dropdown)
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-10: Change the "Contact" label/field to "Address" with no dropdown box.
Current State
Base Odoo type field shows a "Contact" dropdown on child/related contacts (Contact, Invoice Address, Shipping Address, etc.).
Planned Action
Rename label from "Contact" to "Address". Either hide the dropdown or make it readonly with a default value.
H-I
Internal ID auto-generation
MEDIUM
COMPLETED
~2 hrs
Spec Says
PD-3: Auto-generated from 1st letter of First Name + first 3 letters of Last Name + last 6 digits of MA Number. Label changed to "Internal ID".
Current State
Field internal_unique_id_code exists with SQL unique constraint and copy disabled. Hidden in header, shown on Personal Details tab. Auto-generation not verified.
Planned Action
Verify if auto-generation exists. If not, add computed field or onchange using the formula. Rename label to "Internal ID". Field readonly to users.
Section 2 — Related Contacts Tab
5 items · ~10–16 hrs
▶ 5 items already implemented (click to expand)
✓ Tab renamed to "Related Contacts"
✓ Kanban card display for child contacts
✓ Relationship to PS displayed on kanban cards
✓ GeoLocation removed from this area (RC-6)
✓ Clicking a card opens the contact's full form (RC-3)
⚠ Architectural Decision Required (RC-B): The spec describes a "search and link existing contacts" flow that is fundamentally different from the current parent-child (
child_ids) model. Your answer on RC-B determines the scope of work for this entire tab.
RC-A
Add Contact Type, Mobile, Email to kanban cards
LOW
COMPLETED
~1 hr
Spec Says
Kanban cards show: Contact Name, Contact Type, Relationship to PS, Mobile, Email.
Current State
Cards show name, display_name, and relationship only. No Contact Type, Mobile, or Email on cards.
Planned Action
Add partner_type, mobile, email to the kanban card template.
RC-D
Sort related contacts alphabetically by last name
LOW
COMPLETED
~0.5 hrs
Spec Says
RC-5: Sort contacts alphabetically by last name.
Current State
No explicit sort order. Default Odoo sort likely by record ID (creation order).
Planned Action
Add alphabetical sorting by lastname field to the kanban display.
VIA Contact Form (res.partner) — Gap Analysis Review
Comparing current Odoo 17 Contact form against VIA res.partner spec · Generated March 17, 2026 · Updated April 7, 2026 (AUTH section cross-referenced with Authorization module) · 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 30 items reviewed
48–72
Estimated Total Hours
30
Change Items
5
Sections
Section 1 — Main Contact (Header)
9 items · ~12–16 hrs
▶ 14 items already implemented — no changes needed (click to expand)
✓ Contact Type in right column, required
✓ Relationship to Person Supported — Many2many tags, conditional visibility
✓ Pronouns — free text in right column
✓ Email, Mobile, Phone repositioned to left column above address
✓ County of Residence inside address block
✓ Region of Residence after address block
✓ Service Team(s) — Many2many tags, conditional visibility
✓ Service Line(s) — Many2many tags, conditional visibility
✓ Status field in right column
✓ Tags (category_id) in right column
✓ Title field hidden
✓ VAT and Website fields hidden
✓ Job Position (function) field hidden
✓ GeoLocation and Contacts Label groups hidden
H-A
Remove "Employee" from Contact Type dropdown
MEDIUM
IN PROGRESS
~3 hrs
Spec Says
MC-LOV-1 lists Employee as "REMOVED per testing". Final Contact Type list has 8 values (no Employee).
Current State
employee exists in partner_type selection (9 values). Used in visibility rules for Service Team(s) and Service Line(s): partner_type in ('person_support', 'employee').
Planned Action
Remove employee from the selection list. Update visibility conditions that reference it. Audit existing records for data migration. Check via_roles for security rules referencing this value.
Existing partner records with Contact Type = Employee would have an orphaned value. What should those records become?
H-G
Remove Individual/Company radio buttons
LOW
IN PROGRESS
~0.5 hrs
Spec Says
MC-11: Remove the Individual/Company radio buttons. Marked as TBD in spec's open questions.
Current State
Base Odoo company_type radio buttons (Individual/Company) likely still visible at top of form.
Planned Action
Hide the radio buttons. Default is_company to False. Will not proceed until confirmed since spec marks this TBD.
Are companies established as contacts in res.partner, or elsewhere? This determines whether the radio buttons are still needed.
H-H
Region auto-populates from County (ODP Appendix H)
MEDIUM
BLOCKED
~2 hrs
Spec Says
MC-3: Region of Residence auto-populates based on County using ODP Appendix H mapping.
Current State
County-to-region mapping data exists in the USPS address validation module. Both fields are on the form but Region does not auto-fill when County changes.
Planned Action
Add @api.onchange('county_id') method to auto-set distinguish_region from existing ODP mapping data. User can still override manually.
RC-B
"Add Related Contact" — search/link existing vs. create new
HIGH
~6–10 hrs
Spec Says
RC-1/RC-2: "Add Related Contact" opens a search for existing contacts. If not found, user clicks "NEW" to create, then links it.
Current State
Uses child_ids (One2many via parent_id). "Add" creates a new child contact inline. No search for existing contacts.
Planned Action
Two options:
Option A (Less disruptive): Keep parent-child structure but customize the "Add" button to open a search dialog. Selecting an existing contact sets its
parent_id. Preserves all existing relationships.
Option B (Larger change): New Many2many field for related contacts, replacing
child_ids. A contact can relate to multiple people without changing its parent_id. Requires data migration.
Which approach do you prefer? Or is there a different relationship model you have in mind?
RC-C
Allow related contacts to be unlinked (not deleted)
LOW
IN PROGRESS
~1 hr
Spec Says
RC-4: Allow related contacts to be removed (unlinked from relationship).
Current State
Standard child_ids kanban has remove action. Should clear parent_id (unlink) not delete, but needs verification.
Planned Action
Verify current remove action does NOT delete the contact record. If it deletes, change to unlink only.
RC-E
Relationship field on cards — legacy vs. new field
MEDIUM
~2 hrs
Spec Says
Cards show "Relationship to Person Supported." Doesn't specify which underlying field.
Current State
Cards show legacy partner_relationship (Selection, 11 values). Newer partner_relationship_ids (Many2many) exists in header but is NOT on kanban cards.
Planned Action
Decision needed: show old Selection (backward compatible — existing data displays) or new Many2many (forward-looking — old records show blank until migrated)?
Existing child contacts have data in the legacy field. Switching to the new field without migration would cause relationship info to disappear from cards.
Section 3 — Personal Details Tab
8 items · ~8–10 hrs
▶ 18 items already implemented (click to expand)
✓ Tab visible only for Person Supported
✓ Three-column layout (Identifiers, Identity, Functional)
✓ DOB, MA Number, Internal ID in Column 1
✓ Sex — 3 values match spec
✓ Gender, Sexual Orientation, Race, Ethnicity, Primary Language, Religion in Column 2
✓ Developmental Disability, Intellectual Disability, Communication Plan, Mobility, Living Arrangement in Column 3
✓ All LOV values match spec (except items below)
✓ All fields populate from CRM.lead on creation (sync confirmed)
PD-A
Remove "Not listed" from Gender dropdown
MEDIUM
~1.5 hrs
Spec Says
PD-5: Remove "Not listed" from Gender LOV. Final list: 9 values (Woman, Man, Non-Binary, Self-Describe, Prefer not to say, Transgender, Cisgender, Agender, Genderqueer).
Current State
Gender has 10 values including not_listed. Same field exists on crm.lead in the sync list.
Planned Action
Remove not_listed from selection on both res.partner and crm.lead. Check existing records for migration. Determine replacement value for existing data.
What should existing records with gender = "Not listed" be migrated to? (Likely "Prefer not to say" or "Self-Describe")
PD-B
Remove "Other" from Race dropdown
MEDIUM
~1.5 hrs
Spec Says
PD-6: Remove "Other" from Race LOV. Final list: 8 values. Race has LOV key mismatches between crm.lead and res.partner.
Current State
Race has 9 values including other. Known LOV key mismatches with crm.lead (3 key differences + 1 missing value).
Planned Action
Remove other from selection on both models. Coordinate with LOV key mismatch fix. Determine replacement value for existing data (likely "Self-Described").
Race LOV has key mismatches between crm.lead and res.partner — this removal should be coordinated with the mismatch fix to avoid compounding sync issues.
PD-C
Free text box when Gender = "Self-Describe"
LOW
~1 hr
Spec Says
PD-4: If Gender is "Self-Describe," show free form text box for custom entry.
Current State
No conditional text box. "Self-Describe" just sets the selection value.
Planned Action
Add new Char field (e.g., gender_self_describe) visible only when gender = 'self_describe'. Add to both res.partner and crm.lead models + sync list + both form views.
PD-D
Free text box when Sexual Orientation = "Self-Describe"
LOW
~1 hr
Spec Says
If Sexual Orientation is "Self-Describe," show free form text box.
Current State
No conditional text box exists.
Planned Action
Same pattern as PD-C: new Char field sexual_orientation_self_describe, visible conditionally. Both models + sync.
PD-E
Free text box when Race = "Self-Described"
LOW
~1 hr
Spec Says
If Race is "Self-Described," show free form text box.
Current State
No conditional text box exists.
Planned Action
Same pattern: new Char field race_self_describe, visible conditionally. Both models + sync.
PD-F
Free text box when Primary Language = "Other"
LOW
~1 hr
Spec Says
PD-7: If Primary Language is "Other," show text box for custom language entry.
Current State
No conditional text box exists.
Planned Action
Same pattern: new Char field primary_language_other, visible conditionally. Both models + sync.
PD-G
Rename "Internal Unique ID" label to "Internal ID"
LOW
~0.25 hrs
Spec Says
PD-3: Label changed from "Internal Unique ID" to "Internal ID".
Current State
Field label is "Internal Unique ID Code" (from model string).
Planned Action
Change field string or add view-level label override to display "Internal ID".
PD-H
Reduce spacing between Internal ID and Developmental Disability
LOW
~0.5 hrs
Spec Says
PD-8: Remove some space between Internal ID and Developmental Disability sections (UI adjustment).
Current State
Column 1 has 3 fields, Column 3 has 5 — height difference creates whitespace.
Planned Action
CSS/layout adjustment. Deferred to final layout pass after all functional changes are complete.
Section 4 — Authorization Tab
5 items · ~14–22 hrs
⚠ Major Architectural Change — Context Updated April 2026: The
via_authorization module is now live on staging (DB-1 through DB-7 complete). sale.order has been renamed "Authorization" system-wide. The current editable Authorization tab on res.partner is being replaced with a new view-only kanban tab that reads from sale.order (Authorization) records. API-connected fields (payer, payer_program, source_platform, team_ids) remain in the res.partner data model — they are now edited on the Authorization (sale.order) form and synced back to the partner.
AUTH-A
Remove editable pre-authorization fields from this tab
CRITICAL
~2 hrs
Spec Says
Remove the Pre-Authorization tab from res.partner entirely. Pre-auth data moves to CRM.lead only. Client confirmed (CRM AU-A): "Do not build this tab in CRM.lead, move to Sale.order and a view only tab will be in Res.partner when Contact type = Person supported."
Current State
13 editable fields on the existing tab (owned by via_tab_authorization, priority 25): payer, payer_program, source_platform, authorized_date, pre_auth_region, pre_auth_county_id, projected_units, sc_phone_no, team_ids, primary_team_id, user_id, partner_activation_status, pre_auth_notes. Four are API-connected.
Planned Action
Remove ALL current fields from the tab view XML (via_tab_authorization). Fields remain in the res.partner model — API integrations (Sandata, PROMISe) continue reading from the model. Users will edit billing-critical fields on the Authorization (sale.order) form instead. The via_authorization module (DB-1 through DB-7, now live on staging) provides the new editing surface.
API-connected fields: payer (Sandata + PROMISe), payer_program (Sandata), source_platform (PROMISe), team_ids (Sandata). These fields are now editable on the Authorization (sale.order) form. A sync mechanism must write values back to res.partner so API integrations continue to read them from the partner record.
Cross-reference: CRM AU-A (move auth tab to sale.order), Auth AH-1 (header fields from crm.lead), Auth SL-9 (payer/payer_program on sale.order.line). DB-7 rename is COMPLETE — sale.order is now labeled "Authorization" in menus, breadcrumbs, and actions.
AUTH-B
Build new view-only Authorization tab with kanban cards
HIGH
~8–12 hrs
Spec Says
AUTH-2/AUTH-4: View-only tab. Active authorizations as kanban cards. Tab header: Region of Service, County of Service, Eligibility (Yes/No/Error), Last Eligibility Check.
Current State
No kanban authorization view exists on res.partner. The via_authorization module is now live on staging — it owns the sale.order list/form/search views (DB-1 through DB-7). sale.order records ARE the authorization records. The data source question is answered: sale.order records linked via partner_id.
Planned Action
Build a new view-only tab on res.partner (visible when partner_type = 'person_support') that displays the person's sale.order records as kanban cards. Each card shows: Service Type (from sale.order.line product), Authorization Dates, Units Remaining, Funding Source. Tab header shows: Region of Service, County of Service, Eligibility status, Last Eligibility Check date. This tab replaces the current editable tab removed in AUTH-A.
Cross-reference: Auth DB-1 (list view is read-only, verified), Auth DB-2 (search filters exist), Auth DB-4 (native checkboxes for bulk select), Auth DB-5 (duplicate with date override wizard). The sale.order infrastructure this tab reads from is built and working.
Deferred kanban card decisions (from Auth gap analysis): How to display multi-service authorizations (one card per SO vs one card per SO line)? How to calculate "units remaining" formula?
AUTH-C
Combine Authorization, Eligibility, and Service Line tabs
MEDIUM
~2 hrs
Spec Says
AUTH-3: Combine Authorization, Eligibility, and Service Line tabs into one unified tab.
Current State
Three separate tab modules exist on res.partner: via_tab_authorization (priority 25), via_tab_eligibility (if present), and via_tab_service_lines (shows service line header with Region/County). The new AUTH-B kanban tab will consolidate all three into a single "Authorization" tab with eligibility in the header and service lines visible within kanban cards.
Planned Action
When AUTH-B is built, hide or remove the separate Eligibility and Service Line tabs. All relevant data appears within the unified Authorization tab: eligibility status in the tab header (AUTH-D), service lines within each kanban card. Follows the One Module One Tab principle — the new tab module owns the combined view.
Cross-reference: Per the via-notebook-tab-architecture skill, each tab has an owning module and a priority. The replacement tab should claim priority 25 (same slot as the current
via_tab_authorization) and the other two tabs should be deactivated or hidden.
AUTH-D
Add Eligibility fields to tab header
MEDIUM
~3 hrs
Spec Says
AUTH-7/AUTH-8: Eligibility (Yes/No/Error) and Last Eligibility Check (date), plus Region and County of Service — displayed in the tab header above the kanban cards.
Current State
No eligibility_status or last_eligibility_check fields exist on res.partner. PROMISe EDI (270/271 transactions) performs eligibility checks but results are not currently stored as partner-level fields. Region exists as pre_auth_region (Selection) and County as pre_auth_county_id (Many2one → via.res.county) — both synced from crm.lead. These are pre-authorization concepts; the tab header needs to show the active service region/county which may differ.
Planned Action
New fields on res.partner: eligibility_status (Selection: yes/no/error/pending), last_eligibility_check (Datetime). Populated by PROMISe 271 response processing. Region/County of Service in the tab header: if a person has only one active authorization, display its region/county; if multiple authorizations exist with different regions, display "Multiple" or aggregate. The per-line region/county lives on sale.order.line (Auth SL-7/SL-8, not yet built).
Cross-reference: Auth SL-7 (region_of_service on sale.order.line), Auth SL-8 (county_of_service_id on sale.order.line), Contact H-H (county auto-populate from ODP Appendix H — BLOCKED). Note: County of Residence (H-H) ≠ County of Service (this item). PROMISe EDI skill covers 270/271 eligibility transaction format.
Should the tab header show a computed aggregate of region/county across active authorizations, or the partner-level pre_auth values? Does the PROMISe 271 response handler need to be built before this item can be completed?
AUTH-E
Funding Source at service line level, not partner level
HIGH
~4 hrs
Spec Says
AUTH-5/AUTH-6: Funding Source and authorization dates must be at the service line level — can differ per service line within the same authorization.
Current State
funding_source is a single Selection field on res.partner — one value per person. No per-service-line structure exists yet. The Authorization gap analysis specifies funding_source on sale.order.line (Auth SL-11) and auth_start_date / auth_end_date on sale.order.line (Auth SL-3). These SL items are not yet built — they are the next implementation phase after DB-1 through DB-7.
Planned Action
The architecture is confirmed: sale.order.line will carry per-service funding_source, auth_start_date, and auth_end_date. The partner-level funding_source field becomes legacy — it may be kept as a computed "primary" value or removed entirely. On the res.partner Authorization tab (AUTH-B), each kanban card will display the per-line funding source and date range from the linked sale.order.line records. This item is architecturally dependent on Auth SL-3 and SL-11 being built first.
Cross-reference: Auth SL-3 (auth_start_date/auth_end_date on sale.order.line — NOT YET BUILT), Auth SL-11 (funding_source on sale.order.line — NOT YET BUILT), Auth SL-9 (payer/payer_program on sale.order.line), Auth OQ-2 (funding source purpose unclear — needs client clarification).
Auth OQ-2 flagged that the purpose of funding_source is unclear ("PA PROMISe ???"). Client clarification needed: is funding_source the same as payer_program, or a separate concept? This affects whether it's redundant with SL-9.
Section 5 — Removed Tabs & General Rules
3 items · ~4–8 hrs
▶ 3 items already implemented (click to expand)
✓ Sales & Purchases tab hidden unconditionally (via_roles, priority 400)
✓ Accounting tab hidden unconditionally (via_roles, priority 400)
✓ Internal Notes tab hidden unconditionally (via_roles, priority 400)
RT-A
Internal Notes: spec says remove for Physician only, currently hidden for ALL
LOW
~0.5 hrs
Spec Says
MC-7: Remove Internal Notes tab when Contact Type = Physician. (Implies visible for other types.)
Current State
Hidden for ALL contact types unconditionally (invisible="1", priority 400).
Planned Action
Spec and current state disagree. Two options: (a) Keep hidden for everyone (simpler), or (b) Make visible for all except Physician (matches spec). Will not change until confirmed.
Keep Internal Notes hidden for everyone (current), or show for non-Physician contacts (spec)?
RT-B
Remove all CRM/Service Development links from contact form
LOW
~1.5 hrs
Spec Says
Remove all links to CRM and Service Development from the contact form.
Current State
action_view_opportunity smart button exists with effect=False (visible but non-functional, Studio 9475). Other CRM links may exist.
Planned Action
Set action_view_opportunity to invisible="1". Audit for other CRM links and hide them.
RT-C
Person Supported contacts created via CRM.lead only
MEDIUM
~2–4 hrs
Spec Says
Users will NOT create Person Supported contacts directly — only through CRM.lead workflow.
Current State
Users can create a contact and set partner_type = 'person_support' directly. CRM conversion also works (from_crm=True).
Planned Action
Options: (a) Remove "Person Supported" from Contact Type dropdown on new records only, or (b) Add validation blocking save with partner_type = 'person_support' unless from_crm context is set. CRM conversion flow continues normally.
Should "Person Supported" still appear in the dropdown on existing records? Or hidden entirely and only set programmatically?
Export Responses
Click to generate YAML for Claude ingestion. Paste into a new Claude chat to resume implementation planning.
✅ Completed Items (Implemented)
8 items — click to expand/collapse
H-B
Narrow visibility of "Relationship to Person Supported" field
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-1: Field appears only when Contact Type is Supports Coordinator, Family Member, Common Law Employer, Managing Employer, or Physician.
Current State
Visible for ALL non–Person Supported contacts (partner_type != 'person_support') — including Employee, 1099 Contractor, and Other.
Planned Action
Change the visibility rule to: partner_type not in ('support_coordinator', 'family_member', 'common_law_employer', 'managing_employer', 'physician'). Field hidden for 1099 Contractor and Other.
H-C
Service Line(s) visibility depends on Service Team selection
MEDIUM
COMPLETED
~2 hrs
Spec Says
MC-5: Service Line(s) visible only when Contact Type = Person Supported AND Service Team includes PDS or HCBS.
Current State
Visible whenever partner_type in ('person_support', 'employee') — no team filtering.
Planned Action
Add logic so Service Line(s) only appears when at least one selected Service Team is PDS or HCBS. Requires computed field or onchange since team_ids is Many2many.
H-D
Status dropdown values vary by Contact Type
LOW
COMPLETED
~1 hr
Spec Says
MC-6: Person Supported gets 4 values (Active, Inactive, Discharged, Deceased). All others get 3 (no Discharged).
Current State
All 4 values available to all contact types.
Planned Action
Add domain filter to hide "Discharged" when partner_type != 'person_support'. Check existing non-PS records for orphaned Discharged values.
H-E
Remove Physicians field from the form
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-9: Remove Physicians field — physicians will be Related Contacts instead.
Current State
physician_ids Many2many is hidden by default, then made visible for Person Supported by the post-Studio override (priority 365).
Planned Action
Remove the post-Studio override that makes physician_ids visible. Field stays in the model (no data loss). Existing physician links remain in data but are not visible on the form.
Users would need to re-establish physician links as Related Contacts if they want to see them on the form.
H-F
Change "Contact" label to "Address" (no dropdown)
LOW
COMPLETED
~0.5 hrs
Spec Says
MC-10: Change the "Contact" label/field to "Address" with no dropdown box.
Current State
Base Odoo type field shows a "Contact" dropdown on child/related contacts (Contact, Invoice Address, Shipping Address, etc.).
Planned Action
Rename label from "Contact" to "Address". Either hide the dropdown or make it readonly with a default value.
H-I
Internal ID auto-generation
MEDIUM
COMPLETED
~2 hrs
Spec Says
PD-3: Auto-generated from 1st letter of First Name + first 3 letters of Last Name + last 6 digits of MA Number. Label changed to "Internal ID".
Current State
Field internal_unique_id_code exists with SQL unique constraint and copy disabled. Hidden in header, shown on Personal Details tab. Auto-generation not verified.
Planned Action
Verify if auto-generation exists. If not, add computed field or onchange using the formula. Rename label to "Internal ID". Field readonly to users.
Section 2 — Related Contacts Tab
5 items · ~10–16 hrs
▶ 5 items already implemented (click to expand)
✓ Tab renamed to "Related Contacts"
✓ Kanban card display for child contacts
✓ Relationship to PS displayed on kanban cards
✓ GeoLocation removed from this area (RC-6)
✓ Clicking a card opens the contact's full form (RC-3)
⚠ Architectural Decision Required (RC-B): The spec describes a "search and link existing contacts" flow that is fundamentally different from the current parent-child (
child_ids) model. Your answer on RC-B determines the scope of work for this entire tab.
RC-A
Add Contact Type, Mobile, Email to kanban cards
LOW
COMPLETED
~1 hr
Spec Says
Kanban cards show: Contact Name, Contact Type, Relationship to PS, Mobile, Email.
Current State
Cards show name, display_name, and relationship only. No Contact Type, Mobile, or Email on cards.
Planned Action
Add partner_type, mobile, email to the kanban card template.
RC-D
Sort related contacts alphabetically by last name
LOW
COMPLETED
~0.5 hrs
Spec Says
RC-5: Sort contacts alphabetically by last name.
Current State
No explicit sort order. Default Odoo sort likely by record ID (creation order).
Planned Action
Add alphabetical sorting by lastname field to the kanban display.