4. Views, actions, and menus
Objectives
- connect models to usable entry points
- design focused list and form views
- understand that visibility is not authorization
Mental model
A view presents a model; an action chooses how it opens; a menu exposes the action. These are three separate records and none replaces access control.
Guided practice
- Declare form and list ir.ui.view records.
- Create an ir.action.act_window and its view order.
- Attach the action to a menu.
- Grant explicit model access through CSV.
- Test with a normal user after signing in again.
Minimal example
<record model="ir.ui.view" id="book_view_form">
<field name="model">library.book</field>
<field name="type">form</field>
<field name="name">book_form</field>
</record>
<record model="ir.action.act_window" id="act_book">
<field name="name">Books</field>
<field name="res_model">library.book</field>
</record>
<menuitem name="Library" id="menu_library" sequence="50"/>
<menuitem parent="menu_library" action="act_book"
id="menu_book" sequence="10"/>
How to read the example
Keep forms aligned with the work sequence and lists limited to fields used for recognition or decisions. Translate user-facing labels rather than embedding language-specific logic.
Exercise
Create form and list XML files, add search ordering, and verify the same action in both desktop and web clients.
Run the exercise first with a minimal valid case, then add an invalid case and turn both into repeatable tests.
Verifiable result
A permitted user can open, create, and find books; an unpermitted user cannot access the model through RPC even if they know its name.
Common mistakes
- treating a hidden menu as security
- overloading list views with every field
- hard-coding database IDs
- forgetting access CSV or translations
Ready-to-advance criteria
- I can explain the concepts without looking at the code.
- Valid and invalid cases have tests.
- I tested with a non-administrative user.
- I know how to upgrade and restore the training database.
Version and references
Series 7.0 requires at least Python 3.8 according to official metadata. This official branch still carries historical metadata in setup.py; preserve series compatibility while preparing custom packages for standard python -m build builds. Do not confuse this historical minimum with the Python version certified by your organization.
This edition pins examples and dependencies to series 7.0. Check the official 7.0 tutorial, server API, and source branch before moving a pattern to production.