[FIX] comment all missing image includes in doc, so that it can build at all
bzr revid: xmo@openerp.com-20121116112659-fy9amck0k5g5xvjz
This commit is contained in:
Xavier Morel
parent
e5bae342ae
commit
59ffc0af69
|
|
@ -124,11 +124,11 @@ But it is dangerous to write or read directly in the PostgreSQL database, as
|
|||
you will shortcut important steps like constraints checking or workflow
|
||||
modification.
|
||||
|
||||
.. figure:: images/pom_3_0_3.png
|
||||
:scale: 50
|
||||
:align: center
|
||||
.. .. figure:: images/pom_3_0_3.png
|
||||
.. :scale: 50
|
||||
.. :align: center
|
||||
|
||||
*The Physical Objects Model of [OpenERP version 3.0.3]*
|
||||
.. *The Physical Objects Model of [OpenERP version 3.0.3]*
|
||||
|
||||
|
||||
XML Files
|
||||
|
|
@ -311,9 +311,9 @@ When you open an invoice, here is the chain of operations followed by the client
|
|||
* The client asks (with XML-RPC) to the server what views are defined for the invoice object and what are the data it must show.
|
||||
* The client displays the form according to the view
|
||||
|
||||
.. figure:: images/arch_view_use.png
|
||||
:scale: 50
|
||||
:align: center
|
||||
.. .. figure:: images/arch_view_use.png
|
||||
.. :scale: 50
|
||||
.. :align: center
|
||||
|
||||
To develop new objects
|
||||
//////////////////////
|
||||
|
|
@ -342,9 +342,9 @@ The workflows describe these interactions with graphs. One or several workflows
|
|||
|
||||
Below is an example workflow used for sale orders. It must generate invoices and shipments according to certain conditions.
|
||||
|
||||
.. figure:: images/arch_workflow_sale.png
|
||||
:scale: 85
|
||||
:align: center
|
||||
.. .. figure:: images/arch_workflow_sale.png
|
||||
.. :scale: 85
|
||||
.. :align: center
|
||||
|
||||
|
||||
In this graph, the nodes represent the actions to be done:
|
||||
|
|
|
|||
|
|
@ -45,26 +45,26 @@ The field disposition in a form view always follows the same principle. Fields a
|
|||
* 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
|
||||
+++++++++
|
||||
|
|
@ -129,9 +129,9 @@ Tree views
|
|||
|
||||
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
|
||||
--------------
|
||||
|
|
@ -140,9 +140,9 @@ Search views are a new feature of OpenERP supported as of version 6.0
|
|||
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.
|
||||
|
||||
|
|
@ -300,9 +300,9 @@ combining them with AND/OR operators. It is also possible to save any search con
|
|||
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,
|
||||
|
|
@ -440,15 +440,15 @@ Screenshots
|
|||
|
||||
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
|
||||
|
|
@ -556,9 +556,9 @@ end time can be changed by dragging right end of a bar.
|
|||
Screenshots
|
||||
+++++++++++
|
||||
|
||||
.. figure:: images/gantt.png
|
||||
:scale: 50%
|
||||
:align: center
|
||||
.. .. figure:: images/gantt.png
|
||||
.. :scale: 50%
|
||||
.. :align: center
|
||||
|
||||
|
||||
Design Elements
|
||||
|
|
@ -1337,9 +1337,9 @@ The *view_id* method works very well for menus/actions, but how can you specify
|
|||
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 :
|
||||
|
||||
|
|
|
|||
|
|
@ -207,9 +207,9 @@ They indicate at the user that he has to open a new window in a new 'tab'.
|
|||
|
||||
Administration > Custom > Low Level > Base > Action > Window Actions
|
||||
|
||||
.. figure:: images/module_base_action_window.png
|
||||
:scale: 85
|
||||
:align: center
|
||||
.. .. figure:: images/module_base_action_window.png
|
||||
.. :scale: 85
|
||||
.. :align: center
|
||||
|
||||
Examples of actions
|
||||
+++++++++++++++++++
|
||||
|
|
|
|||
Loading…
Reference in New Issue