Contact Form (res.partner) — Gap Analysis Review
VIA · Odoo 17 · Prepared by SignalPoint Media Group · March 2026
For each proposed change below, please indicate whether our understanding matches your intent.
Agree — We understood correctly, proceed as described.
Disagree — Our understanding is wrong or incomplete. A text box will appear for you to explain.
Items already implemented are collapsed at the top of each section for reference.
Agree — We understood correctly, proceed as described.
Disagree — Our understanding is wrong or incomplete. A text box will appear for you to explain.
Items already implemented are collapsed at the top of each section for reference.
Section 1: Main Contact (Header)
The top section of the contact form — fields above the notebook tabs, split into left column (contact info) and right column (classification).
▶
14 items already implemented — no changes needed (click to expand)
✓ Contact Type field in right column, required
✓ Relationship to Person Supported — Many2many tags, conditional visibility
✓ Pronouns — free text field 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 Caution
Spec says
MC-LOV-1 lists Employee as "REMOVED per testing"
Current
Employee exists as a Contact Type value (
employee). It is used in visibility rules for Service Team(s) and Service Line(s).
Our plan
Remove
employee from the dropdown. Before removing, we will check how many existing records use this type and update visibility rules that reference it. Records with this type would need to be migrated to another type.
Risk note
Existing partner records with Contact Type = Employee would have an orphaned value. We need to know: what should those records become?
Does this match your intent?
H-B
Narrow visibility of "Relationship to Person Supported" field Low risk
Spec says
MC-1: Field appears only when Contact Type is Supports Coordinator, Family Member, Common Law Employer, Managing Employer, or Physician.
Current
Field is visible for ALL non–Person Supported contacts — including Employee, 1099 Contractor, and Other.
Our plan
Change the visibility rule so the field only appears for the five types listed in the spec. It will be hidden for 1099 Contractor and Other (and Employee, if that type is removed per H-A).
Does this match your intent?
H-C
Service Line(s) visibility should depend on Service Team selection Low risk
Spec says
MC-5: Service Line(s) only visible when Contact Type = Person Supported AND Service Team includes PDS or HCBS.
Current
Service Line(s) is visible whenever Contact Type is Person Supported or Employee — regardless of which Service Team is selected.
Our plan
Add logic so Service Line(s) only appears when at least one of the selected Service Teams is PDS or HCBS. If only Admin or QAI teams are selected, the field stays hidden.
Does this match your intent?
H-D
Status dropdown values should vary by Contact Type Low risk
Spec says
MC-6: Person Supported gets 4 values (Active, Inactive, Discharged, Deceased). All other contact types get 3 values (Active, Inactive, Deceased — no Discharged).
Current
All 4 values are available to all contact types.
Our plan
Hide the "Discharged" option when Contact Type is not Person Supported. Existing records with Discharged status on non-PS contacts would be reviewed for migration.
Does this match your intent?
H-E
Remove Physicians field from the form Caution
Spec says
MC-9: Remove Physicians field — physicians will be Related Contacts instead of a separate Many2many link.
Current
The
physician_ids Many2many field is hidden by default, then made visible for Person Supported contacts by a post-Studio override view.
Our plan
Remove the override that makes
physician_ids visible. The field stays in the database (no data loss) but will no longer appear on the form. Physicians would be linked as Related Contacts instead.
Risk note
Existing physician links will remain in the data but won't be visible on the form. Users would need to re-establish these links as Related Contacts if they want to see them.
Does this match your intent?
H-F
Change "Contact" label to "Address" (no dropdown) Low risk
Spec says
MC-10: The "Contact" label/field should be changed to "Address" with no dropdown box.
Current
The base Odoo
type field shows a "Contact" dropdown on child/related contacts (values: Contact, Invoice Address, Shipping Address, etc.). This appears in the Related Contacts inline form.
Our plan
Rename the label from "Contact" to "Address" and either hide the dropdown or make it readonly with a default value, so users see a simple label instead of a selectable dropdown.
Does this match your intent?
H-G
Remove Individual/Company radio buttons Low risk
Spec says
MC-11: Remove the Individual/Company radio buttons. Marked as TBD in the spec's open questions.
Current
The base Odoo
company_type radio buttons (Individual / Company) likely still appear at the top of the form.
Our plan
Hide the radio buttons from the form. The underlying
is_company field would default to False (Individual). We will NOT proceed on this until you confirm, since the spec marks it TBD.
Question
Are companies established as contacts in res.partner, or elsewhere? (This affects whether the radio buttons are still needed.)
Does this match your intent?
H-H
Region auto-populates from County (ODP Appendix H) Low risk
Spec says
MC-3: Region of Residence auto-populates based on County of Residence using the ODP Appendix H mapping.
Current
The county-to-region mapping data exists in the USPS address validation module. Region (
distinguish_region) and County (county_id) are both on the form, but there is no auto-population when county changes.
Our plan
Add an
onchange method so that when County is selected, Region auto-fills based on the existing ODP mapping data. The user could still override it manually.
Does this match your intent?
H-I
Internal ID auto-generation Low risk
Spec says
PD-3: Internal ID auto-generated from first letter of First Name + first 3 letters of Last Name + last 6 digits of MA Number. Label changed to "Internal ID".
Current
The
internal_unique_id_code field exists with a SQL unique constraint and copy disabled. It is currently hidden in the header and displayed on the Personal Details tab. Auto-generation logic has not been verified.
Our plan
Verify whether auto-generation already exists. If not, add a computed field or onchange that builds the ID from the formula. Rename the label to "Internal ID". The field would be readonly to users.
Does this match your intent?
Open Questions — Header
OQ-2
Address validation with USPS — which identity document should the address match (Driver's License, etc.)?
OQ-5
Do the Individual/Company radio buttons need to stay on the form? (Related to H-G above)
OQ-6
Service Team and Service Line LOV values will need updated — what are the final values?
Section 2: Related Contacts Tab
The tab showing associated contacts in kanban card format. Currently named "Related Contacts" (renamed from "Contacts & Addresses").
▶
5 items already implemented — no changes needed (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-1 / RC-2
The spec describes an "Add Related Contact" flow that searches for existing contacts and links them, rather than creating new child contacts inline. This is a fundamentally different pattern from the current implementation.
Currently, related contacts are child records (parent-child relationship via parent_id). The spec describes a link-existing-contacts pattern (Many2many). These are different database relationships with different implications for data structure.
Please review item RC-B below carefully — your answer determines the scope of work for this tab.
RC-A
Add Contact Type, Mobile, and Email to kanban cards Low risk
Spec says
Kanban cards should show: Contact Name, Contact Type, Relationship to PS, Mobile, Email.
Current
Cards show name, display name, and relationship. Contact Type, Mobile, and Email are not on the cards.
Our plan
Add
partner_type, mobile, and email to the kanban card template so all five fields display on each card.
Does this match your intent?
RC-B
"Add Related Contact" — search and link existing contacts vs. create new Caution
Spec says
RC-1: "Add Related Contact" opens a search window for existing contacts. RC-2: If not found, user clicks "NEW," creates the contact, then it appears as a related contact.
Current
Uses Odoo's standard
child_ids (One2many via parent_id). Clicking "Add" creates a new child contact inline. There is no search for existing contacts.
Our plan
We see two possible approaches and need your guidance:
Option A (Less disruptive): Keep the current parent-child structure but customize the "Add" button to open a search dialog. If the user selects an existing contact, set its
Option B (Larger change): Create a new Many2many field for related contacts, replacing the One2many
Option A (Less disruptive): Keep the current parent-child structure but customize the "Add" button to open a search dialog. If the user selects an existing contact, set its
parent_id to this person. If not found, allow creating a new one. This preserves all existing child relationships.Option B (Larger change): Create a new Many2many field for related contacts, replacing the One2many
child_ids approach. This allows a single contact to be related to multiple people without changing its parent_id. This is a bigger structural change and would require migrating existing child contact relationships.
Question
Which approach do you prefer? Or is there a different relationship model you have in mind?
Does this match your intent?
RC-C
Allow related contacts to be unlinked (not deleted) Low risk
Spec says
RC-4: Allow related contacts to be removed (unlinked from the relationship).
Current
Standard Odoo child_ids kanban has a delete/remove action. This should clear
parent_id (unlink) rather than delete the record, but needs to be verified.
Our plan
Verify the current remove action does NOT delete the contact record — only clears the parent-child relationship. If it deletes, we'll change it to unlink only.
Does this match your intent?
RC-D
Sort related contacts alphabetically by last name Low risk
Spec says
RC-5: Sort contacts alphabetically by last name.
Current
No explicit sort order. Default Odoo sorting (likely by record ID — order of creation).
Our plan
Add alphabetical sorting by the
lastname field to the kanban display.
Does this match your intent?
RC-E
Relationship field on kanban cards — legacy vs. new field Caution
Spec says
Cards should show "Relationship to Person Supported." Does not specify which underlying field.
Current
Cards display the legacy
partner_relationship (Selection field with 11 values). A newer Many2many field (partner_relationship_ids) exists in the header for non-PS contacts but is NOT shown on kanban cards.
Our plan
We need to know: should the kanban cards show the old Selection field (backward compatible — existing data displays) or the new Many2many field (forward-looking — old records would show blank until updated)?
Risk note
Existing child contact records have data in the legacy field. Switching to the new field without migrating data would cause relationship info to disappear from cards.
Does this match your intent?
Open Questions — Related Contacts
OQ-3
When Contact Type is Supports Coordinator, a "Referrals" tab appears — what content should be in that tab? (Currently shows ISP records in an editable tree.)
OQ-4
Quick buttons review — what changes are needed to the smart buttons at the top of the form?
RC-7
When "Relationship to Person Supported" is answered, the spec says to allow associating the contact with a Person Supported. How should this work — a lookup field? An automatic link?
Section 3: Personal Details Tab
Demographics tab visible only for Person Supported contacts. Three-column layout: Identifiers (left), Identity (center), Functional (right). Owned by via_tab_demographics module.
▶
18 items already implemented — no changes needed (click to expand)
✓ Tab visible only for Person Supported (partner_type)
✓ Three-column layout (Identifiers, Identity, Functional)
✓ DOB (date_of_birth) — Date field in Column 1
✓ MA Number (ma_number) — Char, unique constraint, tracked. ⚠️ API: Sandata + PROMISe
✓ Internal ID (internal_unique_id_code) — Char, SQL unique, copy disabled
✓ Sex — 3 values: Female, Male, Intersex
✓ Sexual Orientation — 8 values match spec
✓ Ethnicity — 2 values: Not Hispanic, Hispanic
✓ Primary Language — 4 values: English, Spanish, ASL, Other
✓ Religion — 9 values match spec
✓ Developmental Disability — 3 values: Autism, Cerebral Palsy, Other
✓ Intellectual Disability — 5 values: Mild, Moderate, Profound, Severe, Unspecified
✓ Communication Plan (commu_issue) — 2 values: Yes, No
✓ Mobility — 4 values: Walks on own, Walker/Crutches/Cane, Wheelchair, Other
✓ Living Arrangement — 3 values match spec
✓ All fields populate from CRM.lead on creation (sync confirmed)
✓ Gender — Selection field present in Column 2
✓ Race — Selection field present in Column 2
PD-A
Remove "Not listed" from Gender dropdown Caution
Spec says
PD-5: Remove "Not listed" from the Gender LOV. Final list: Woman, Man, Non-Binary, Self-Describe, Prefer not to say, Transgender, Cisgender, Agender, Genderqueer (9 values).
Current
Gender has 10 values including "Not listed" (technical key: not_listed).
Our plan
Remove "not_listed" from the selection list. Before removing, check for existing records that use this value and determine what they should be migrated to (likely "Prefer not to say" or "Self-Describe").
Risk note
Any existing records with gender = "not_listed" would show a blank or invalid value after removal. The same field exists on crm.lead and is in the sync list — the value must be removed from both models.
Does this match your intent?
PD-B
Remove "Other" from Race dropdown Caution
Spec says
PD-6: Remove "Other" from the Race LOV. Final list: American Indian/Alaskan Native, Asian, Black/African American, Native Hawaiian/Pacific Islander, White, Self-Described, Two or more, Prefer not to say (8 values).
Current
Race has 9 values including "Other" (technical key: other).
Our plan
Remove "other" from the selection list. Before removing, check for existing records that use this value and determine what they should be migrated to (likely "Self-Described"). The same field exists on crm.lead — must be removed from both models.
Risk note
Race is one of the fields with a LOV mismatch between crm.lead and res.partner (different technical keys). This removal needs to be coordinated across both models to prevent sync issues.
Does this match your intent?
PD-C
Show free text box when Gender = "Self-Describe" Low risk
Spec says
PD-4: If Gender answer is "Self-Describe," display a free form text box for custom entry.
Current
No conditional text box. Selecting "Self-Describe" just sets the selection value — no place for the user to type what they identify as.
Our plan
Add a new Char field (e.g., gender_self_describe) that is visible only when gender = "self_describe". This requires a new field on both res.partner and crm.lead (to maintain sync), plus view changes on both forms.
Does this match your intent?
PD-D
Show free text box when Sexual Orientation = "Self-Describe" Low risk
Spec says
Sexual Orientation: if "Self-Describe" is selected, show a free form text box.
Current
No conditional text box exists for Sexual Orientation.
Our plan
Same pattern as PD-C: add a new Char field (e.g., sexual_orientation_self_describe) visible only when sexual_orientation = "self_describe". Add to both models and sync list.
Does this match your intent?
PD-E
Show free text box when Race = "Self-Described" Low risk
Spec says
Race: if "Self-Described" is selected, show a free form text box.
Current
No conditional text box exists for Race.
Our plan
Same pattern as PD-C and PD-D: add a new Char field (e.g., race_self_describe) visible only when race = "self_described". Add to both models and sync list.
Does this match your intent?
PD-F
Show free text box when Primary Language = "Other" Low risk
Spec says
PD-7: If Primary Language is "Other," display a free form text box to enter the language.
Current
No conditional text box exists for Primary Language.
Our plan
Same pattern: add a new Char field (e.g., primary_language_other) visible only when primary_language = "other". Add to both models and sync list.
Does this match your intent?
PD-G
Rename "Internal Unique ID" label to "Internal ID" Low risk
Spec says
PD-3: Label changed from "Internal Unique ID" to "Internal ID".
Current
Field label is "Internal Unique ID Code" (from the field string in the model: internal_unique_id_code).
Our plan
Change the field's string attribute or add a label override in the view XML to display "Internal ID" instead of "Internal Unique ID Code".
Does this match your intent?
PD-H
Reduce spacing between Internal ID and Developmental Disability sections Low risk
Spec says
PD-8: Remove some of the space between Internal ID and Developmental Disability sections (UI adjustment).
Current
Column 1 has 3 fields (DOB, MA Number, Internal ID). Column 3 has 5 fields starting with Developmental Disability. The height difference between columns may create visible whitespace.
Our plan
This is a CSS/layout adjustment. We will address it during the final layout pass after all functional changes are complete. Deferring to the positioning phase.
Does this match your intent?
Open Questions — Personal Details
PD-Q1
For the four new "Self-Describe" / "Other" text fields (Gender, Sexual Orientation, Race, Primary Language): should these fields also appear on the CRM.lead form, or only on the contact form after conversion?
PD-Q2
For LOV removals (Gender "Not listed", Race "Other"): what should happen to existing records that have these values? Options: (a) migrate to a specific replacement value, (b) leave as-is and just prevent new selections, (c) blank them out.
OQ-7
Typos in LOVs from the original spec: "Pefer not to say" (Sexual Orientation, Race) and "Native Hawiian" (Race) — confirm these should be corrected to "Prefer not to say" and "Native Hawaiian".
Section 4: Authorization Tab
Currently an editable two-column tab with pre-authorization fields, authorization details, and notes. The spec replaces this entirely with a view-only tab showing active authorizations as kanban cards.
⚠ Major Architectural Change — This Tab Is Being Replaced, Not Modified
The current Authorization tab contains editable pre-authorization fields (payer, payer program, region, county, projected units, SC phone, notes, etc.). The spec removes ALL of this from the contact form and moves it to the CRM.lead form.
In its place, a new view-only Authorization tab would show active authorizations as kanban cards populated from sale.order or a similar authorization record. This is fundamentally new functionality, not a modification of the existing tab.
Critical: Several fields on the current tab are API-connected (payer, payer_program, source_platform, team_ids). These fields must remain in the data model even though they will no longer be editable on this tab. The APIs read them from the model, not from the view.
AUTH-A
Remove current editable pre-authorization fields from this tab API Review
Spec says
Remove the Pre-Authorization tab from res.partner entirely. Pre-authorization data moves to CRM.lead only and is available through an archive view there.
Current
Authorization tab has 13 editable fields including 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, and pre_auth_notes. Four of these are API-connected (payer, payer_program, source_platform, team_ids).
Our plan
Remove ALL current fields from this tab's view. The fields remain in the data model — only the view changes. API integrations (Sandata, PROMISe) read from the model, not the form, so they continue working. However, users will no longer be able to edit payer, payer_program, etc. from the contact form. We need to confirm: where will users edit these fields going forward?
Risk note
🛑 API-connected fields: payer (Sandata + PROMISe), payer_program (Sandata), source_platform (PROMISe), team_ids (Sandata). These must continue to have values for billing to work. If they are no longer editable on the contact form, there must be another way to set/update them (e.g., from CRM lead conversion, or from the new authorization workflow).
Does this match your intent?
AUTH-B
Build new view-only Authorization tab with kanban cards Caution
Spec says
AUTH-2/AUTH-4: New tab is entirely view-only. All active authorizations appear as kanban cards. Tab header shows Region of Service, County of Service, Eligibility (Yes/No/Error), and Last Eligibility Check (date).
Current
No kanban authorization view exists on the contact form. Authorization data currently lives in the editable fields being removed (AUTH-A). Active authorizations would need to come from sale.order records or a new authorization model.
Our plan
Build a new view-only tab that reads authorization records (likely from sale.order or a related model). Each kanban card shows: Service Team, Service Type, Authorization Dates, Units, and Funding Source. Tab header shows aggregate fields. This is new development — not a modification of existing views.
Question
Where do authorization records come from? Currently there is no "authorization" model — the closest is sale.order. Should we read from confirmed sale.orders, or is there a separate authorization record/model planned?
Does this match your intent?
AUTH-C
Combine Authorization, Eligibility, and Service Line tabs into one Caution
Spec says
AUTH-3: Combine the former Authorization tab, Eligibility tab, and Service Line tab into this single unified tab.
Current
We only see one Authorization tab currently (via_tab_authorization). We do not see separate Eligibility or Service Line tabs in the repo code. These may exist via Studio or another source we haven't identified.
Our plan
If Eligibility and Service Line tabs exist (perhaps via Studio or another module), they would be hidden and their relevant content merged into the new Authorization tab. We need to verify whether these tabs currently exist in the live system.
Question
Do separate Eligibility and Service Line tabs currently exist on the contact form? If so, where do they come from (Studio, another module)?
Does this match your intent?
AUTH-D
Add Eligibility fields to the new Authorization tab header Caution
Spec says
AUTH-7/AUTH-8: Tab header shows Eligibility (values: Yes, No, Error) and Last Eligibility Check (date), plus Region of Service and County of Service.
Current
No Eligibility field exists on the current res.partner model that we can identify. The PROMISe EDI integration performs eligibility checks (X12 270/271), but the results may not be stored as a simple field on the partner record.
Our plan
This likely requires new fields on res.partner: eligibility_status (Selection: Yes/No/Error) and last_eligibility_check (Date). These would be populated by the PROMISe eligibility check workflow. Region of Service and County of Service may map to existing pre_auth_region and pre_auth_county_id, or may need new fields if "service" location differs from "pre-auth" location.
Question
Are Eligibility and Last Eligibility Check currently stored anywhere (PROMISe integration results)? And should Region/County of Service reuse the existing pre_auth_region/pre_auth_county_id fields, or are these different concepts?
Does this match your intent?
AUTH-E
Funding Source at the service line level, not partner level Caution
Spec says
AUTH-5/AUTH-6: Funding Source must be at the service line level — it can be different for each service line. Authorization dates must also be at the service line level.
Current
Funding Source (funding_source) is a single Selection field on res.partner — one value per person, not per service line. There is no per-service-line authorization date structure.
Our plan
This requires a new data model where each authorization record (kanban card) has its own funding_source and date range. The existing partner-level funding_source field would become legacy. This is part of the broader authorization model design (see AUTH-B).
Does this match your intent?
Open Questions — Authorization
AUTH-Q1
Once the editable pre-auth fields are removed from the contact form, where will users go to update payer, payer_program, and other billing-critical fields? These are required by Sandata and PROMISe APIs.
AUTH-Q2
What is the data source for the authorization kanban cards? Confirmed sale.orders? A new authorization model? Something else?
AUTH-Q3
The CRM.lead spec mentions an "Activate Authorization" button that launches sale.order. Is the authorization record created at that point, and is that what should appear on the contact form's Authorization tab?
Section 5: Removed Tabs
Tabs that the spec says should be removed entirely from the res.partner form.
▶
3 items already implemented — no changes needed (click to expand)
✓ Sales & Purchases tab — already hidden unconditionally by via_roles (priority 400)
✓ Accounting tab — already hidden unconditionally by via_roles (priority 400)
✓ Internal Notes tab — already hidden unconditionally by via_roles (priority 400)
RT-A
Internal Notes tab: spec says remove only for Physician, currently hidden for ALL Low risk
Spec says
MC-7: When Contact Type = Physician, remove Internal Notes tab. (Implies it should remain visible for other contact types.)
Current
Internal Notes tab is hidden for ALL contact types unconditionally by via_roles/views/res_partner_fa_visibility.xml (priority 400, invisible="1").
Our plan
The spec and current implementation disagree. Two options: (a) Keep it hidden for everyone (current behavior — simpler), or (b) Make it visible for all except Physician (matches spec literally). We will not change this until you confirm which behavior you want.
Question
Should the Internal Notes tab remain hidden for everyone (current state), or should it be made visible for non-Physician contacts as the spec implies?
Does this match your intent?
RT-B
Remove all CRM links from contact form Low risk
Spec says
Remove all links to CRM from the contact form. Remove all links to Service Development from the contact form.
Current
The action_view_opportunity smart button exists with effect=False (visible but non-functional, controlled by Studio 9475). There may be other CRM-related links or smart buttons.
Our plan
Hide all CRM/Service Development smart buttons and links. The action_view_opportunity button would be set to invisible="1" (currently effect=False). We will audit for any other CRM links in the form.
Does this match your intent?
RT-C
Person Supported contacts created via CRM.lead only, not directly Caution
Spec says
Users will NOT create a Contact for a Person Supported directly — Person Supported contacts are created through the CRM.lead workflow.
Current
Users can currently create a contact and set partner_type = "person_support" directly. The CRM lead → partner conversion also creates PS contacts via the sync flow (from_crm=True context).
Our plan
Prevent direct creation of Person Supported contacts. Options include: (a) removing "Person Supported" from the Contact Type dropdown when creating a new contact (but keeping it visible on existing records), or (b) adding a validation that blocks saving a new record with partner_type = "person_support" unless the from_crm context is set. The CRM conversion flow would continue to work normally.
Question
Should "Person Supported" still appear in the Contact Type dropdown on existing records (readonly), or should it be completely hidden from the dropdown and only set programmatically?
Does this match your intent?
Open Questions — Removed Tabs & General
OQ-1
Are companies established as a contact in res.partner, or somewhere else? (Affects whether Individual/Company radio buttons and is_company logic need to be preserved.)
OQ-8
"Physcian" is misspelled in the Relationship to Person Supported field description in the original spec — confirm this should be "Physician".
Generates a text summary of all your responses that you can copy, save, or send back to SignalPoint.
0 Agreed
0 Disagreed
30 Pending
Sections 1–5 of 5 · res.partner complete
Contact Form (res.partner) — Gap Analysis Review
VIA · Odoo 17 · Prepared by SignalPoint Media Group · March 2026
For each proposed change below, please indicate whether our understanding matches your intent.
Agree — We understood correctly, proceed as described.
Disagree — Our understanding is wrong or incomplete. A text box will appear for you to explain.
Items already implemented are collapsed at the top of each section for reference.
Agree — We understood correctly, proceed as described.
Disagree — Our understanding is wrong or incomplete. A text box will appear for you to explain.
Items already implemented are collapsed at the top of each section for reference.
Section 1: Main Contact (Header)
The top section of the contact form — fields above the notebook tabs, split into left column (contact info) and right column (classification).
▶
14 items already implemented — no changes needed (click to expand)
✓ Contact Type field in right column, required
✓ Relationship to Person Supported — Many2many tags, conditional visibility
✓ Pronouns — free text field 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 Caution
Spec says
MC-LOV-1 lists Employee as "REMOVED per testing"
Current
Employee exists as a Contact Type value (
employee). It is used in visibility rules for Service Team(s) and Service Line(s).
Our plan
Remove
employee from the dropdown. Before removing, we will check how many existing records use this type and update visibility rules that reference it. Records with this type would need to be migrated to another type.
Risk note
Existing partner records with Contact Type = Employee would have an orphaned value. We need to know: what should those records become?
Does this match your intent?
H-B
Narrow visibility of "Relationship to Person Supported" field Low risk
Spec says
MC-1: Field appears only when Contact Type is Supports Coordinator, Family Member, Common Law Employer, Managing Employer, or Physician.
Current
Field is visible for ALL non–Person Supported contacts — including Employee, 1099 Contractor, and Other.
Our plan
Change the visibility rule so the field only appears for the five types listed in the spec. It will be hidden for 1099 Contractor and Other (and Employee, if that type is removed per H-A).
Does this match your intent?
H-C
Service Line(s) visibility should depend on Service Team selection Low risk
Spec says
MC-5: Service Line(s) only visible when Contact Type = Person Supported AND Service Team includes PDS or HCBS.
Current
Service Line(s) is visible whenever Contact Type is Person Supported or Employee — regardless of which Service Team is selected.
Our plan
Add logic so Service Line(s) only appears when at least one of the selected Service Teams is PDS or HCBS. If only Admin or QAI teams are selected, the field stays hidden.
Does this match your intent?
H-D
Status dropdown values should vary by Contact Type Low risk
Spec says
MC-6: Person Supported gets 4 values (Active, Inactive, Discharged, Deceased). All other contact types get 3 values (Active, Inactive, Deceased — no Discharged).
Current
All 4 values are available to all contact types.
Our plan
Hide the "Discharged" option when Contact Type is not Person Supported. Existing records with Discharged status on non-PS contacts would be reviewed for migration.
Does this match your intent?
H-E
Remove Physicians field from the form Caution
Spec says
MC-9: Remove Physicians field — physicians will be Related Contacts instead of a separate Many2many link.
Current
The
physician_ids Many2many field is hidden by default, then made visible for Person Supported contacts by a post-Studio override view.
Our plan
Remove the override that makes
physician_ids visible. The field stays in the database (no data loss) but will no longer appear on the form. Physicians would be linked as Related Contacts instead.
Risk note
Existing physician links will remain in the data but won't be visible on the form. Users would need to re-establish these links as Related Contacts if they want to see them.
Does this match your intent?
H-F
Change "Contact" label to "Address" (no dropdown) Low risk
Spec says
MC-10: The "Contact" label/field should be changed to "Address" with no dropdown box.
Current
The base Odoo
type field shows a "Contact" dropdown on child/related contacts (values: Contact, Invoice Address, Shipping Address, etc.). This appears in the Related Contacts inline form.
Our plan
Rename the label from "Contact" to "Address" and either hide the dropdown or make it readonly with a default value, so users see a simple label instead of a selectable dropdown.
Does this match your intent?
H-G
Remove Individual/Company radio buttons Low risk
Spec says
MC-11: Remove the Individual/Company radio buttons. Marked as TBD in the spec's open questions.
Current
The base Odoo
company_type radio buttons (Individual / Company) likely still appear at the top of the form.
Our plan
Hide the radio buttons from the form. The underlying
is_company field would default to False (Individual). We will NOT proceed on this until you confirm, since the spec marks it TBD.
Question
Are companies established as contacts in res.partner, or elsewhere? (This affects whether the radio buttons are still needed.)
Does this match your intent?
H-H
Region auto-populates from County (ODP Appendix H) Low risk
Spec says
MC-3: Region of Residence auto-populates based on County of Residence using the ODP Appendix H mapping.
Current
The county-to-region mapping data exists in the USPS address validation module. Region (
distinguish_region) and County (county_id) are both on the form, but there is no auto-population when county changes.
Our plan
Add an
onchange method so that when County is selected, Region auto-fills based on the existing ODP mapping data. The user could still override it manually.
Does this match your intent?
H-I
Internal ID auto-generation Low risk
Spec says
PD-3: Internal ID auto-generated from first letter of First Name + first 3 letters of Last Name + last 6 digits of MA Number. Label changed to "Internal ID".
Current
The
internal_unique_id_code field exists with a SQL unique constraint and copy disabled. It is currently hidden in the header and displayed on the Personal Details tab. Auto-generation logic has not been verified.
Our plan
Verify whether auto-generation already exists. If not, add a computed field or onchange that builds the ID from the formula. Rename the label to "Internal ID". The field would be readonly to users.
Does this match your intent?
Open Questions — Header
OQ-2
Address validation with USPS — which identity document should the address match (Driver's License, etc.)?
OQ-5
Do the Individual/Company radio buttons need to stay on the form? (Related to H-G above)
OQ-6
Service Team and Service Line LOV values will need updated — what are the final values?
Section 2: Related Contacts Tab
The tab showing associated contacts in kanban card format. Currently named "Related Contacts" (renamed from "Contacts & Addresses").
▶
5 items already implemented — no changes needed (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-1 / RC-2
The spec describes an "Add Related Contact" flow that searches for existing contacts and links them, rather than creating new child contacts inline. This is a fundamentally different pattern from the current implementation.
Currently, related contacts are child records (parent-child relationship via parent_id). The spec describes a link-existing-contacts pattern (Many2many). These are different database relationships with different implications for data structure.
Please review item RC-B below carefully — your answer determines the scope of work for this tab.
RC-A
Add Contact Type, Mobile, and Email to kanban cards Low risk
Spec says
Kanban cards should show: Contact Name, Contact Type, Relationship to PS, Mobile, Email.
Current
Cards show name, display name, and relationship. Contact Type, Mobile, and Email are not on the cards.
Our plan
Add
partner_type, mobile, and email to the kanban card template so all five fields display on each card.
Does this match your intent?
RC-B
"Add Related Contact" — search and link existing contacts vs. create new Caution
Spec says
RC-1: "Add Related Contact" opens a search window for existing contacts. RC-2: If not found, user clicks "NEW," creates the contact, then it appears as a related contact.
Current
Uses Odoo's standard
child_ids (One2many via parent_id). Clicking "Add" creates a new child contact inline. There is no search for existing contacts.
Our plan
We see two possible approaches and need your guidance:
Option A (Less disruptive): Keep the current parent-child structure but customize the "Add" button to open a search dialog. If the user selects an existing contact, set its
Option B (Larger change): Create a new Many2many field for related contacts, replacing the One2many
Option A (Less disruptive): Keep the current parent-child structure but customize the "Add" button to open a search dialog. If the user selects an existing contact, set its
parent_id to this person. If not found, allow creating a new one. This preserves all existing child relationships.Option B (Larger change): Create a new Many2many field for related contacts, replacing the One2many
child_ids approach. This allows a single contact to be related to multiple people without changing its parent_id. This is a bigger structural change and would require migrating existing child contact relationships.
Question
Which approach do you prefer? Or is there a different relationship model you have in mind?
Does this match your intent?
RC-C
Allow related contacts to be unlinked (not deleted) Low risk
Spec says
RC-4: Allow related contacts to be removed (unlinked from the relationship).
Current
Standard Odoo child_ids kanban has a delete/remove action. This should clear
parent_id (unlink) rather than delete the record, but needs to be verified.
Our plan
Verify the current remove action does NOT delete the contact record — only clears the parent-child relationship. If it deletes, we'll change it to unlink only.
Does this match your intent?
RC-D
Sort related contacts alphabetically by last name Low risk
Spec says
RC-5: Sort contacts alphabetically by last name.
Current
No explicit sort order. Default Odoo sorting (likely by record ID — order of creation).
Our plan
Add alphabetical sorting by the
lastname field to the kanban display.
Does this match your intent?
RC-E
Relationship field on kanban cards — legacy vs. new field Caution
Spec says
Cards should show "Relationship to Person Supported." Does not specify which underlying field.
Current
Cards display the legacy
partner_relationship (Selection field with 11 values). A newer Many2many field (partner_relationship_ids) exists in the header for non-PS contacts but is NOT shown on kanban cards.
Our plan
We need to know: should the kanban cards show the old Selection field (backward compatible — existing data displays) or the new Many2many field (forward-looking — old records would show blank until updated)?
Risk note
Existing child contact records have data in the legacy field. Switching to the new field without migrating data would cause relationship info to disappear from cards.
Does this match your intent?
Open Questions — Related Contacts
OQ-3
When Contact Type is Supports Coordinator, a "Referrals" tab appears — what content should be in that tab? (Currently shows ISP records in an editable tree.)
OQ-4
Quick buttons review — what changes are needed to the smart buttons at the top of the form?
RC-7
When "Relationship to Person Supported" is answered, the spec says to allow associating the contact with a Person Supported. How should this work — a lookup field? An automatic link?
Section 3: Personal Details Tab
Demographics tab visible only for Person Supported contacts. Three-column layout: Identifiers (left), Identity (center), Functional (right). Owned by via_tab_demographics module.
▶
18 items already implemented — no changes needed (click to expand)
✓ Tab visible only for Person Supported (partner_type)
✓ Three-column layout (Identifiers, Identity, Functional)
✓ DOB (date_of_birth) — Date field in Column 1
✓ MA Number (ma_number) — Char, unique constraint, tracked. ⚠️ API: Sandata + PROMISe
✓ Internal ID (internal_unique_id_code) — Char, SQL unique, copy disabled
✓ Sex — 3 values: Female, Male, Intersex
✓ Sexual Orientation — 8 values match spec
✓ Ethnicity — 2 values: Not Hispanic, Hispanic
✓ Primary Language — 4 values: English, Spanish, ASL, Other
✓ Religion — 9 values match spec
✓ Developmental Disability — 3 values: Autism, Cerebral Palsy, Other
✓ Intellectual Disability — 5 values: Mild, Moderate, Profound, Severe, Unspecified
✓ Communication Plan (commu_issue) — 2 values: Yes, No
✓ Mobility — 4 values: Walks on own, Walker/Crutches/Cane, Wheelchair, Other
✓ Living Arrangement — 3 values match spec
✓ All fields populate from CRM.lead on creation (sync confirmed)
✓ Gender — Selection field present in Column 2
✓ Race — Selection field present in Column 2
PD-A
Remove "Not listed" from Gender dropdown Caution
Spec says
PD-5: Remove "Not listed" from the Gender LOV. Final list: Woman, Man, Non-Binary, Self-Describe, Prefer not to say, Transgender, Cisgender, Agender, Genderqueer (9 values).
Current
Gender has 10 values including "Not listed" (technical key: not_listed).
Our plan
Remove "not_listed" from the selection list. Before removing, check for existing records that use this value and determine what they should be migrated to (likely "Prefer not to say" or "Self-Describe").
Risk note
Any existing records with gender = "not_listed" would show a blank or invalid value after removal. The same field exists on crm.lead and is in the sync list — the value must be removed from both models.
Does this match your intent?
PD-B
Remove "Other" from Race dropdown Caution
Spec says
PD-6: Remove "Other" from the Race LOV. Final list: American Indian/Alaskan Native, Asian, Black/African American, Native Hawaiian/Pacific Islander, White, Self-Described, Two or more, Prefer not to say (8 values).
Current
Race has 9 values including "Other" (technical key: other).
Our plan
Remove "other" from the selection list. Before removing, check for existing records that use this value and determine what they should be migrated to (likely "Self-Described"). The same field exists on crm.lead — must be removed from both models.
Risk note
Race is one of the fields with a LOV mismatch between crm.lead and res.partner (different technical keys). This removal needs to be coordinated across both models to prevent sync issues.
Does this match your intent?
PD-C
Show free text box when Gender = "Self-Describe" Low risk
Spec says
PD-4: If Gender answer is "Self-Describe," display a free form text box for custom entry.
Current
No conditional text box. Selecting "Self-Describe" just sets the selection value — no place for the user to type what they identify as.
Our plan
Add a new Char field (e.g., gender_self_describe) that is visible only when gender = "self_describe". This requires a new field on both res.partner and crm.lead (to maintain sync), plus view changes on both forms.
Does this match your intent?
PD-D
Show free text box when Sexual Orientation = "Self-Describe" Low risk
Spec says
Sexual Orientation: if "Self-Describe" is selected, show a free form text box.
Current
No conditional text box exists for Sexual Orientation.
Our plan
Same pattern as PD-C: add a new Char field (e.g., sexual_orientation_self_describe) visible only when sexual_orientation = "self_describe". Add to both models and sync list.
Does this match your intent?
PD-E
Show free text box when Race = "Self-Described" Low risk
Spec says
Race: if "Self-Described" is selected, show a free form text box.
Current
No conditional text box exists for Race.
Our plan
Same pattern as PD-C and PD-D: add a new Char field (e.g., race_self_describe) visible only when race = "self_described". Add to both models and sync list.
Does this match your intent?
PD-F
Show free text box when Primary Language = "Other" Low risk
Spec says
PD-7: If Primary Language is "Other," display a free form text box to enter the language.
Current
No conditional text box exists for Primary Language.
Our plan
Same pattern: add a new Char field (e.g., primary_language_other) visible only when primary_language = "other". Add to both models and sync list.
Does this match your intent?
PD-G
Rename "Internal Unique ID" label to "Internal ID" Low risk
Spec says
PD-3: Label changed from "Internal Unique ID" to "Internal ID".
Current
Field label is "Internal Unique ID Code" (from the field string in the model: internal_unique_id_code).
Our plan
Change the field's string attribute or add a label override in the view XML to display "Internal ID" instead of "Internal Unique ID Code".
Does this match your intent?
PD-H
Reduce spacing between Internal ID and Developmental Disability sections Low risk
Spec says
PD-8: Remove some of the space between Internal ID and Developmental Disability sections (UI adjustment).
Current
Column 1 has 3 fields (DOB, MA Number, Internal ID). Column 3 has 5 fields starting with Developmental Disability. The height difference between columns may create visible whitespace.
Our plan
This is a CSS/layout adjustment. We will address it during the final layout pass after all functional changes are complete. Deferring to the positioning phase.
Does this match your intent?
Open Questions — Personal Details
PD-Q1
For the four new "Self-Describe" / "Other" text fields (Gender, Sexual Orientation, Race, Primary Language): should these fields also appear on the CRM.lead form, or only on the contact form after conversion?
PD-Q2
For LOV removals (Gender "Not listed", Race "Other"): what should happen to existing records that have these values? Options: (a) migrate to a specific replacement value, (b) leave as-is and just prevent new selections, (c) blank them out.
OQ-7
Typos in LOVs from the original spec: "Pefer not to say" (Sexual Orientation, Race) and "Native Hawiian" (Race) — confirm these should be corrected to "Prefer not to say" and "Native Hawaiian".
Section 4: Authorization Tab
Currently an editable two-column tab with pre-authorization fields, authorization details, and notes. The spec replaces this entirely with a view-only tab showing active authorizations as kanban cards.
⚠ Major Architectural Change — This Tab Is Being Replaced, Not Modified
The current Authorization tab contains editable pre-authorization fields (payer, payer program, region, county, projected units, SC phone, notes, etc.). The spec removes ALL of this from the contact form and moves it to the CRM.lead form.
In its place, a new view-only Authorization tab would show active authorizations as kanban cards populated from sale.order or a similar authorization record. This is fundamentally new functionality, not a modification of the existing tab.
Critical: Several fields on the current tab are API-connected (payer, payer_program, source_platform, team_ids). These fields must remain in the data model even though they will no longer be editable on this tab. The APIs read them from the model, not from the view.
AUTH-A
Remove current editable pre-authorization fields from this tab API Review
Spec says
Remove the Pre-Authorization tab from res.partner entirely. Pre-authorization data moves to CRM.lead only and is available through an archive view there.
Current
Authorization tab has 13 editable fields including 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, and pre_auth_notes. Four of these are API-connected (payer, payer_program, source_platform, team_ids).
Our plan
Remove ALL current fields from this tab's view. The fields remain in the data model — only the view changes. API integrations (Sandata, PROMISe) read from the model, not the form, so they continue working. However, users will no longer be able to edit payer, payer_program, etc. from the contact form. We need to confirm: where will users edit these fields going forward?
Risk note
🛑 API-connected fields: payer (Sandata + PROMISe), payer_program (Sandata), source_platform (PROMISe), team_ids (Sandata). These must continue to have values for billing to work. If they are no longer editable on the contact form, there must be another way to set/update them (e.g., from CRM lead conversion, or from the new authorization workflow).
Does this match your intent?
AUTH-B
Build new view-only Authorization tab with kanban cards Caution
Spec says
AUTH-2/AUTH-4: New tab is entirely view-only. All active authorizations appear as kanban cards. Tab header shows Region of Service, County of Service, Eligibility (Yes/No/Error), and Last Eligibility Check (date).
Current
No kanban authorization view exists on the contact form. Authorization data currently lives in the editable fields being removed (AUTH-A). Active authorizations would need to come from sale.order records or a new authorization model.
Our plan
Build a new view-only tab that reads authorization records (likely from sale.order or a related model). Each kanban card shows: Service Team, Service Type, Authorization Dates, Units, and Funding Source. Tab header shows aggregate fields. This is new development — not a modification of existing views.
Question
Where do authorization records come from? Currently there is no "authorization" model — the closest is sale.order. Should we read from confirmed sale.orders, or is there a separate authorization record/model planned?
Does this match your intent?
AUTH-C
Combine Authorization, Eligibility, and Service Line tabs into one Caution
Spec says
AUTH-3: Combine the former Authorization tab, Eligibility tab, and Service Line tab into this single unified tab.
Current
We only see one Authorization tab currently (via_tab_authorization). We do not see separate Eligibility or Service Line tabs in the repo code. These may exist via Studio or another source we haven't identified.
Our plan
If Eligibility and Service Line tabs exist (perhaps via Studio or another module), they would be hidden and their relevant content merged into the new Authorization tab. We need to verify whether these tabs currently exist in the live system.
Question
Do separate Eligibility and Service Line tabs currently exist on the contact form? If so, where do they come from (Studio, another module)?
Does this match your intent?
AUTH-D
Add Eligibility fields to the new Authorization tab header Caution
Spec says
AUTH-7/AUTH-8: Tab header shows Eligibility (values: Yes, No, Error) and Last Eligibility Check (date), plus Region of Service and County of Service.
Current
No Eligibility field exists on the current res.partner model that we can identify. The PROMISe EDI integration performs eligibility checks (X12 270/271), but the results may not be stored as a simple field on the partner record.
Our plan
This likely requires new fields on res.partner: eligibility_status (Selection: Yes/No/Error) and last_eligibility_check (Date). These would be populated by the PROMISe eligibility check workflow. Region of Service and County of Service may map to existing pre_auth_region and pre_auth_county_id, or may need new fields if "service" location differs from "pre-auth" location.
Question
Are Eligibility and Last Eligibility Check currently stored anywhere (PROMISe integration results)? And should Region/County of Service reuse the existing pre_auth_region/pre_auth_county_id fields, or are these different concepts?
Does this match your intent?
AUTH-E
Funding Source at the service line level, not partner level Caution
Spec says
AUTH-5/AUTH-6: Funding Source must be at the service line level — it can be different for each service line. Authorization dates must also be at the service line level.
Current
Funding Source (funding_source) is a single Selection field on res.partner — one value per person, not per service line. There is no per-service-line authorization date structure.
Our plan
This requires a new data model where each authorization record (kanban card) has its own funding_source and date range. The existing partner-level funding_source field would become legacy. This is part of the broader authorization model design (see AUTH-B).
Does this match your intent?
Open Questions — Authorization
AUTH-Q1
Once the editable pre-auth fields are removed from the contact form, where will users go to update payer, payer_program, and other billing-critical fields? These are required by Sandata and PROMISe APIs.
AUTH-Q2
What is the data source for the authorization kanban cards? Confirmed sale.orders? A new authorization model? Something else?
AUTH-Q3
The CRM.lead spec mentions an "Activate Authorization" button that launches sale.order. Is the authorization record created at that point, and is that what should appear on the contact form's Authorization tab?
Section 5: Removed Tabs
Tabs that the spec says should be removed entirely from the res.partner form.
▶
3 items already implemented — no changes needed (click to expand)
✓ Sales & Purchases tab — already hidden unconditionally by via_roles (priority 400)
✓ Accounting tab — already hidden unconditionally by via_roles (priority 400)
✓ Internal Notes tab — already hidden unconditionally by via_roles (priority 400)
RT-A
Internal Notes tab: spec says remove only for Physician, currently hidden for ALL Low risk
Spec says
MC-7: When Contact Type = Physician, remove Internal Notes tab. (Implies it should remain visible for other contact types.)
Current
Internal Notes tab is hidden for ALL contact types unconditionally by via_roles/views/res_partner_fa_visibility.xml (priority 400, invisible="1").
Our plan
The spec and current implementation disagree. Two options: (a) Keep it hidden for everyone (current behavior — simpler), or (b) Make it visible for all except Physician (matches spec literally). We will not change this until you confirm which behavior you want.
Question
Should the Internal Notes tab remain hidden for everyone (current state), or should it be made visible for non-Physician contacts as the spec implies?
Does this match your intent?
RT-B
Remove all CRM links from contact form Low risk
Spec says
Remove all links to CRM from the contact form. Remove all links to Service Development from the contact form.
Current
The action_view_opportunity smart button exists with effect=False (visible but non-functional, controlled by Studio 9475). There may be other CRM-related links or smart buttons.
Our plan
Hide all CRM/Service Development smart buttons and links. The action_view_opportunity button would be set to invisible="1" (currently effect=False). We will audit for any other CRM links in the form.
Does this match your intent?
RT-C
Person Supported contacts created via CRM.lead only, not directly Caution
Spec says
Users will NOT create a Contact for a Person Supported directly — Person Supported contacts are created through the CRM.lead workflow.
Current
Users can currently create a contact and set partner_type = "person_support" directly. The CRM lead → partner conversion also creates PS contacts via the sync flow (from_crm=True context).
Our plan
Prevent direct creation of Person Supported contacts. Options include: (a) removing "Person Supported" from the Contact Type dropdown when creating a new contact (but keeping it visible on existing records), or (b) adding a validation that blocks saving a new record with partner_type = "person_support" unless the from_crm context is set. The CRM conversion flow would continue to work normally.
Question
Should "Person Supported" still appear in the Contact Type dropdown on existing records (readonly), or should it be completely hidden from the dropdown and only set programmatically?
Does this match your intent?
Open Questions — Removed Tabs & General
OQ-1
Are companies established as a contact in res.partner, or somewhere else? (Affects whether Individual/Company radio buttons and is_company logic need to be preserved.)
OQ-8
"Physcian" is misspelled in the Relationship to Person Supported field description in the original spec — confirm this should be "Physician".
Generates a text summary of all your responses that you can copy, save, or send back to SignalPoint.
0 Agreed
0 Disagreed
30 Pending
Sections 1–5 of 5 · res.partner complete