Creating Views And Tracking In Odoo || Odoo 17 Developement Tutorials

Main ideas / lessons

• Build Odoo 17 app functionality step-by-step:

  • Create records (e.g., Patients) and observe automatic fields and record IDs in URLs.
  • Use View architecture to control how model data is displayed (Tree, Form, and default/dynamic behavior).
  • Control view behavior (create/edit/delete visibility, read-only vs editable) by linking specific views to specific menu actions.
  • Add chatter and field change tracking to log changes to records.

• Understand Odoo’s “magic” automatic fields and metadata:

  • id, create_date, create_uid, write_date, write_uid
  • Updated automatically on save; can be inspected via debugger → View metadata.

---

Concepts and workflow (organized)

1) Verify record creation and “magic fields”

• Create a new hospital.patient record (example: name “Sam”).
• After saving:
  • The record gets a unique ID (visible in the URL).
  • Use debug mode → View metadata to inspect:
    • creator (user)
    • create/write timestamps
    • last modification user
• When updating a field (e.g., changing DOB), the “last modification” metadata updates.

---

2) Views in Odoo: Tree & Form

• Goal: Create explicit Tree and Form views instead of relying on Odoo’s dynamic generation.
• Where views are defined:
  • XML files under your custom module views (e.g., something like patient_views.xml).
• The menu action determines which views are used:
  • In the action, specify view modes like:
    • view_mode="tree,form" (conceptually: show tree list, then open a form)
• Key behaviors:
  • If you don’t define a view for a model, Odoo may generate a dynamic view based on model fields.
  • After defining views, Odoo displays the defined columns and UI.

2a) Tree view definition (detailed instructions)

• Add an XML record for an ir.ui.view:
  • Give it a unique id
  • Set model="hospital.patient" (the target model)
  • Choose type="tree"
• Inside <tree>, list the fields to display:
  • Example fields: name, date_of_birth, gender
• After updating/upgrading:
  • The list view shows the specified columns (instead of only default columns).

2b) Form view definition (detailed instructions)

• Create a second ir.ui.view record:
  • Unique id
  • model="hospital.patient"
  • type="form"
• Use the correct XML structure:
  • Put fields inside a <group>; otherwise labels/strings may not render as expected.
• Layout customization:
  • Nest multiple <group> tags inside the form to split fields into left/right sections.
• Add a <sheet> tag:
  • This makes the form render inside the typical boxed sheet layout (instead of using the whole form space).

2c) Handling “Invalid field” issues

• If a required field is not set, the form shows validation like:
  • “invalid field” with the reason that a Python field is required=True.

2d) Optional field visibility in views (detailed instructions)

• Use optional="hide" / optional="show" on fields (especially in tree/list).
• Concept:
  • By default, optional="hide" hides the field.
  • Users can later enable it (e.g., via UI column options).
• The video mentions using a “developer XML” parameter approach to preview XML changes without repeated module upgrades.

---

3) Add tracking (chatter + field change logs)

• Motivation:
  • Odoo’s standard apps track changes in the Chatter section (logs, followers, message history).
  • Your custom hospital.patient model initially lacks this.

3a) Inherit mail thread (detailed instructions)

• In the Python model:
  • Inherit mail.thread (referred as mail.thread in the video).
• Ensure the module depends on mail:
  • Add to __manifest__.py → depends: ["mail"].
• After upgrading:
  • New chatter-related fields appear on the model automatically, such as:
    • followers (message_follower_ids)
    • message records (message_ids)
    • attachments/accounts-related message fields (as described broadly)

3b) Add chatter UI to the Form view (detailed instructions)

• In the form view XML:
  • Add chatter block elements (copied from Odoo source patterns) including:
    • message follower IDs
    • message IDs
• After upgrading/reloading:
  • The form shows sections like:
    • “Send message”
    • “Log note”
• User actions:
  • Add a log note; it appears in chatter.

3c) Enable per-field tracking (detailed instructions)

• In the Python field definition for the specific fields you want tracked:
  • Set tracking=True
• Then:
  • Upgrade the module (required for the tracking metadata to take effect reliably).
• Result:
  • When the field value changes, chatter displays the change history.

---

4) Multiple menus + multiple views: read-only vs editable

• Problem posed:

  • What if you want two different menu entries for the same model:
    • one menu with create/edit
    • another menu read-only (no create, no edit/delete)

• Solution approach:

  • Create extra actions and extra view definitions (tree/form variants).
  • Link each menu to the appropriate action.
  • Use action keys view_ids, and control create/edit/delete at view level.

4a) Create a second menu action + views (detailed instructions)

• Define a new menu item (example: “View Patients”) pointing to a new action.
• Create a new action for the same model (but with different external ID):
  • Includes view_mode and links to custom view IDs.
• Create additional ir.ui.view records:
  • e.g., “read-only tree” view and “read-only form” view.

4b) Control buttons/permissions via view attributes (detailed instructions)

• On the tree view XML tag:
  • create="0" to hide “Create”
  • delete="0" to hide delete action (if desired)
  • edit="0" to prevent inline editing (read-only feel)
• On the form view:
  • Use corresponding attributes like create="0" / edit="0" / delete="0" (as shown conceptually in the video)
• After upgrading:
  • The “read-only” menu shows no “New/Create” button and prevents modifications.

4c) Why sequences don’t solve everything (key concept)

• If you have multiple views of the same type for a model and you don’t specify which ones to use in the action:
  • Odoo may pick based on view ordering/sequence (lowest sequence can win).
• Therefore:
  • Specify exact view IDs in the action using view_ids.

4d) Action view_ids (detailed instructions)

• In the action definition, include view_ids listing:
  • the specific tree view ID
  • the specific form view ID
• This ensures:
  • the menu always uses the correct view variant (editable vs read-only), regardless of other existing views.

---

Speakers / sources featured

• Speaker/voice: Not explicitly named in the subtitles.
• Source referenced:
  • Odoo core modules, specifically:
    • mail.thread (from the Odoo mail module)
    • Odoo model/view system (ir.ui.view, view XML architecture)
  • References to “Sales” app as an example UI pattern (no specific person)
• User names observed in examples/metadata:
  • “Mitchell admin” (logged-in user example)
  • “admin” (mentioned as the user creator in metadata example)