+.. _module-dev-views:
+
Views and Events
================
.. note:: Since OpenERP 4.1, form views can also contain graphs.
-
Form views
----------
* Fields are placed on the screen from left to right, and from top to bottom, according to the order in which they are declared in the view.
* Every screen is divided into 4 columns, each column being able to contain either a label, or an "edition" field. As every edition field is preceded (by default) by a label with its name, there will be two fields (and their respective labels) on each line of the screen. The green and red zones on the screen-shot below, illustrate those 4 columns. They designate respectively the labels and their corresponding fields.
-.. figure:: images/sale_order.png
- :scale: 50
- :align: center
+.. .. figure:: images/sale_order.png
+.. :scale: 50
+.. :align: center
Views also support more advanced placement options:
* A view field can use several columns. For example, on the screen-shot below, the zone in the blue frame is, in fact, the only field of a "one to many". We will come back later on this note, but let's note that it uses the whole width of the screen and not only one column.
- .. figure:: images/sale_order_sale_order_lines.png
- :scale: 50
- :align: center
+ .. .. figure:: images/sale_order_sale_order_lines.png
+ .. :scale: 50
+ .. :align: center
* We can also make the opposite operation: take a columns group and divide it in as many columns as desired. The surrounded green zones of the screen above are good examples. Precisely, the green framework up and on the right side takes the place of two columns, but contains 4 columns.
As we can see below in the purple zone of the screen, there is also a way to distribute the fields of an object on different tabs.
-.. figure:: images/sale_order_notebook.png
- :scale: 50
- :align: center
+.. .. figure:: images/sale_order_notebook.png
+.. :scale: 50
+.. :align: center
On Change
+++++++++
These views are used when we work in list mode (in order to visualize several resources at once) and in the search screen. These views are simpler than the form views and thus have less options.
-.. figure:: images/tree_view.png
- :scale: 50
- :align: center
+.. .. figure:: images/tree_view.png
+.. :scale: 50
+.. :align: center
Search views
--------------
It creates a customized search panel, and is declared quite similarly to a form view,
except that the view type and root element change to ``search`` instead of ``form``.
-.. image:: images/search.png
- :scale: 50
- :align: center
+.. .. image:: images/search.png
+.. :scale: 50
+.. :align: center
Following is the list of new elements and features supported in search views.
of all currently applied domain and context values) as a personal filter, which can be recalled
at any time. Filters can also be turned into Shortcuts directly available in the User's homepage.
-.. image:: images/filter.png
- :scale: 50
- :align: center
+.. .. image:: images/filter.png
+.. :scale: 50
+.. :align: center
In above screenshot we filter Partner where Salesman = Demo user and Country = Belgium,
You can get en example in all modules of the form: report\_.... Example: report_crm.
+Controlling view actions
+------------------------
+
+When defining a view, the following attributes can be added on the
+opening element of the view (i.e. ``<form>``, ``<tree>``...)
+
+``create``
+ set to ``false`` to hide the link / button which allows to create a new
+ record.
+
+``delete``
+ set to ``false`` to hide the link / button which allows to remove a
+ record.
+
+``edit``
+ set to ``false`` to hide the link / button which allows to
+ edit a record.
+
+
+These attributes are available on form, tree, kanban and gantt
+views. They are normally automatically set from the access rights of
+the users, but can be forced globally in the view definition. A
+possible use case for these attributes is to define an inner tree view
+for a one2many relation inside a form view, in which the user cannot
+add or remove related records, but only edit the existing ones (which
+are presumably created through another way, such as a wizard).
+
Calendar Views
--------------
Month Calendar:
-.. figure:: images/calendar_month.png
- :scale: 50%
- :align: center
+.. .. figure:: images/calendar_month.png
+.. :scale: 50%
+.. :align: center
Week Calendar:
-.. figure:: images/calendar_week.png
- :scale: 50%
- :align: center
+.. .. figure:: images/calendar_week.png
+.. :scale: 50%
+.. :align: center
Gantt Views
Screenshots
+++++++++++
-.. figure:: images/gantt.png
- :scale: 50%
- :align: center
+.. .. figure:: images/gantt.png
+.. :scale: 50%
+.. :align: center
Design Elements
its descendants will be displayed in the main tree. The value is ignored
for flat lists.
+
Grouping Elements
+++++++++++++++++
field, for example? When you have a one2many field, two views are used, a tree view (**in blue**), and a form view when
you click on the add button (**in red**).
-.. figure:: images/one2many_views.png
- :scale: 70%
- :align: center
+.. .. figure:: images/one2many_views.png
+.. :scale: 70%
+.. :align: center
When you add a one2many field in a form view, you do something like this :
If you want to specify the views to use, you can add a *context* attribute, and
specify a view id for each type of view supported, exactly like the action's
-*view_id* attribute:
+*view_id* attribute, except that the provided view id must always be
+fully-qualified with the module name, even if it belongs to the same module:
.. code-block:: xml
<field name="order_line" colspan="4" nolabel="1"
- context="{'form_view_ref' : 'module.view_id', 'tree_view_ref' : 'model.view_id'}"/>
+ context="{'form_view_ref': 'module.view_id',
+ 'tree_view_ref': 'module.view_id'}"/>
+
+.. note::
+
+ You *have to* put the module name in the view_id, because this
+ is evaluated when the view is displayed, and not when the XML file
+ is parsed, so the module name information is not available. Failing
+ to do so will result in the default view being selected (see
+ below).
If you don't specify the views, OpenERP will choose one in this order :
projects / odoo / odoo.git / blobdiff