2
.. i18n: Module Structure
3
.. i18n: ================
16
.. i18n: #. Introduction
17
.. i18n: #. Files & Directories
18
.. i18n: #. __terp__.py
19
.. i18n: #. __init__.py
22
.. i18n: #. Menu Entries
29
#. Files & Directories
39
.. i18n: Modules - Files and Directories
40
.. i18n: -------------------------------
43
Modules - Files and Directories
44
-------------------------------
46
.. i18n: All the modules are located in the server/addons directory.
49
All the modules are located in the server/addons directory.
51
.. i18n: The following steps are necessary to create a new module:
54
The following steps are necessary to create a new module:
56
.. i18n: * create a subdirectory in the server/addons directory
57
.. i18n: * create a module description file: **__terp__.py**
58
.. i18n: * create the **Python** file containing the **objects**
59
.. i18n: * create **.xml files** that download the data (views, menu entries, demo data, ...)
60
.. i18n: * optionally create **reports**, **wizards** or **workflows**.
63
* create a subdirectory in the server/addons directory
64
* create a module description file: **__terp__.py**
65
* create the **Python** file containing the **objects**
66
* create **.xml files** that download the data (views, menu entries, demo data, ...)
67
* optionally create **reports**, **wizards** or **workflows**.
69
.. i18n: The Modules - Files And Directories - XML Files
70
.. i18n: +++++++++++++++++++++++++++++++++++++++++++++++
73
The Modules - Files And Directories - XML Files
74
+++++++++++++++++++++++++++++++++++++++++++++++
76
.. i18n: XML files located in the module directory are used to modify the structure of
77
.. i18n: the database. They are used for many purposes, among which we can cite :
80
XML files located in the module directory are used to modify the structure of
81
the database. They are used for many purposes, among which we can cite :
83
.. i18n: * initialization and demonstration data declaration,
84
.. i18n: * views declaration,
85
.. i18n: * reports declaration,
86
.. i18n: * wizards declaration,
87
.. i18n: * workflows declaration.
90
* initialization and demonstration data declaration,
92
* reports declaration,
93
* wizards declaration,
94
* workflows declaration.
96
.. i18n: General structure of OpenERP XML files is more detailed in the
97
.. i18n: :ref:`xml-serialization` section. Look here if you are interested in learning
98
.. i18n: more about *initialization* and *demonstration data declaration* XML files. The
99
.. i18n: following section are only related to XML specific to *actions, menu entries,
100
.. i18n: reports, wizards* and *workflows* declaration.
103
General structure of OpenERP XML files is more detailed in the
104
:ref:`xml-serialization` section. Look here if you are interested in learning
105
more about *initialization* and *demonstration data declaration* XML files. The
106
following section are only related to XML specific to *actions, menu entries,
107
reports, wizards* and *workflows* declaration.
109
.. i18n: Python Module Descriptor File __init__.py
110
.. i18n: +++++++++++++++++++++++++++++++++++++++++
113
Python Module Descriptor File __init__.py
114
+++++++++++++++++++++++++++++++++++++++++
116
.. i18n: **The __init__.py file**
119
**The __init__.py file**
121
.. i18n: The __init__.py file is, like any Python module, executed at the start of the program. It needs to import the Python files that need to be loaded.
124
The __init__.py file is, like any Python module, executed at the start of the program. It needs to import the Python files that need to be loaded.
126
.. i18n: So, if you create a "module.py" file, containing the description of your objects, you have to write one line in __init__.py::
128
.. i18n: import module
131
So, if you create a "module.py" file, containing the description of your objects, you have to write one line in __init__.py::
135
.. i18n: OpenERP Module Descriptor File __terp__.py
136
.. i18n: ++++++++++++++++++++++++++++++++++++++++++
139
OpenERP Module Descriptor File __terp__.py
140
++++++++++++++++++++++++++++++++++++++++++
142
.. i18n: In the created module directory, you must add a **__terp__.py** file. This file, which must be in Python format, is responsible to
145
In the created module directory, you must add a **__terp__.py** file. This file, which must be in Python format, is responsible to
147
.. i18n: 1. determine the *XML files that will be parsed* during the initialization of the server, and also to
148
.. i18n: 2. determine the *dependencies* of the created module.
151
1. determine the *XML files that will be parsed* during the initialization of the server, and also to
152
2. determine the *dependencies* of the created module.
154
.. i18n: This file must contain a Python dictionary with the following values:
157
This file must contain a Python dictionary with the following values:
164
.. i18n: The (Plain English) name of the module.
167
The (Plain English) name of the module.
174
.. i18n: The version of the module.
177
The version of the module.
179
.. i18n: **description**
184
.. i18n: The module description (text).
187
The module description (text).
194
.. i18n: The author of the module.
197
The author of the module.
204
.. i18n: The website of the module.
207
The website of the module.
214
.. i18n: The license of the module (default:GPL-2).
217
The license of the module (default:GPL-2).
224
.. i18n: List of modules on which this module depends. The base module must almost always be in the dependencies because some necessary data for the views, reports, ... are in the base module.
227
List of modules on which this module depends. The base module must almost always be in the dependencies because some necessary data for the views, reports, ... are in the base module.
229
.. i18n: **init_xml**
234
.. i18n: List of .xml files to load when the server is launched with the "--init=module" argument. Filepaths must be relative to the directory where the module is. OpenERP XML File Format is detailed in this section.
237
List of .xml files to load when the server is launched with the "--init=module" argument. Filepaths must be relative to the directory where the module is. OpenERP XML File Format is detailed in this section.
239
.. i18n: **update_xml**
244
.. i18n: List of .xml files to load when the server is launched with the "--update=module" launched. Filepaths must be relative to the directory where the module is. OpenERP XML File Format is detailed in this section.
247
List of .xml files to load when the server is launched with the "--update=module" launched. Filepaths must be relative to the directory where the module is. OpenERP XML File Format is detailed in this section.
249
.. i18n: **installable**
254
.. i18n: True or False. Determines if the module is installable or not.
257
True or False. Determines if the module is installable or not.
264
.. i18n: True or False (default: False). Determines the modules that are installed on the database creation.
267
True or False (default: False). Determines the modules that are installed on the database creation.
274
.. i18n: Here is an example of __terp__.py file for the product module
277
Here is an example of __terp__.py file for the product module
279
.. i18n: .. code-block:: python
282
.. i18n: "name" : "Products & Pricelists",
283
.. i18n: "version" : "1.1",
284
.. i18n: "author" : "Open",
285
.. i18n: "category" : "Generic Modules/Inventory Control",
286
.. i18n: "depends" : ["base", "account"],
287
.. i18n: "init_xml" : [],
288
.. i18n: "demo_xml" : ["product_demo.xml"],
289
.. i18n: "update_xml" : ["product_data.xml", "product_report.xml", "product_wizard.xml",
290
.. i18n: "product_view.xml", "pricelist_view.xml"],
291
.. i18n: "installable": True,
292
.. i18n: "active": True
296
.. code-block:: python
299
"name" : "Products & Pricelists",
302
"category" : "Generic Modules/Inventory Control",
303
"depends" : ["base", "account"],
305
"demo_xml" : ["product_demo.xml"],
306
"update_xml" : ["product_data.xml", "product_report.xml", "product_wizard.xml",
307
"product_view.xml", "pricelist_view.xml"],
312
.. i18n: The files that must be placed in init_xml are the ones that relate to the workflow definition, data to load at the installation of the software and the data for the demonstrations.
315
The files that must be placed in init_xml are the ones that relate to the workflow definition, data to load at the installation of the software and the data for the demonstrations.
317
.. i18n: The files in **update_xml** concern: views, reports and wizards.
320
The files in **update_xml** concern: views, reports and wizards.
329
.. i18n: All OpenERP resources are objects: menus, actions, reports, invoices, partners, ... OpenERP is based on an object relational mapping of a database to control the information. Object names are hierarchical, as in the following examples:
332
All OpenERP resources are objects: menus, actions, reports, invoices, partners, ... OpenERP is based on an object relational mapping of a database to control the information. Object names are hierarchical, as in the following examples:
334
.. i18n: * account.transfer : a money transfer
335
.. i18n: * account.invoice : an invoice
336
.. i18n: * account.invoice.line : an invoice line
339
* account.transfer : a money transfer
340
* account.invoice : an invoice
341
* account.invoice.line : an invoice line
343
.. i18n: Generally, the first word is the name of the module: account, stock, sale.
346
Generally, the first word is the name of the module: account, stock, sale.
348
.. i18n: Other advantages of an ORM;
351
Other advantages of an ORM;
353
.. i18n: * simpler relations : invoice.partner.address[0].city
354
.. i18n: * objects have properties and methods: invoice.pay(3400 EUR),
355
.. i18n: * inheritance, high level constraints, ...
358
* simpler relations : invoice.partner.address[0].city
359
* objects have properties and methods: invoice.pay(3400 EUR),
360
* inheritance, high level constraints, ...
362
.. i18n: It is easier to manipulate one object (example, a partner) than several tables (partner address, categories, events, ...)
365
It is easier to manipulate one object (example, a partner) than several tables (partner address, categories, events, ...)
367
.. i18n: .. figure:: images/pom_3_0_3.png
369
.. i18n: :align: center
371
.. i18n: *The Physical Objects Model of [OpenERP version 3.0.3]*
374
.. figure:: images/pom_3_0_3.png
378
*The Physical Objects Model of [OpenERP version 3.0.3]*
387
.. i18n: The ORM of OpenERP is constructed over PostgreSQL. It is thus possible to
388
.. i18n: query the object used by OpenERP using the object interface or by directly
389
.. i18n: using SQL statements.
392
The ORM of OpenERP is constructed over PostgreSQL. It is thus possible to
393
query the object used by OpenERP using the object interface or by directly
394
using SQL statements.
396
.. i18n: But it is dangerous to write or read directly in the PostgreSQL database, as
397
.. i18n: you will shortcut important steps like constraints checking or workflow
398
.. i18n: modification.
401
But it is dangerous to write or read directly in the PostgreSQL database, as
402
you will shortcut important steps like constraints checking or workflow
407
.. i18n: The Physical Database Model of OpenERP
412
The Physical Database Model of OpenERP
414
.. i18n: Pre-Installed Data
415
.. i18n: ++++++++++++++++++
421
.. i18n: Data can be inserted or updated into the PostgreSQL tables corresponding to the
422
.. i18n: OpenERP objects using XML files. The general structure of an OpenERP XML file
423
.. i18n: is as follows:
426
Data can be inserted or updated into the PostgreSQL tables corresponding to the
427
OpenERP objects using XML files. The general structure of an OpenERP XML file
430
.. i18n: .. code-block:: xml
432
.. i18n: <?xml version="1.0"?>
435
.. i18n: <record model="model.name_1" id="id_name_1">
436
.. i18n: <field name="field1">
437
.. i18n: "field1 content"
439
.. i18n: <field name="field2">
440
.. i18n: "field2 content"
444
.. i18n: <record model="model.name_2" id="id_name_2">
454
<?xml version="1.0"?>
457
<record model="model.name_1" id="id_name_1">
458
<field name="field1">
461
<field name="field2">
466
<record model="model.name_2" id="id_name_2">
473
.. i18n: Fields content are strings that must be encoded as *UTF-8* in XML files.
476
Fields content are strings that must be encoded as *UTF-8* in XML files.
478
.. i18n: Let's review an example taken from the OpenERP source (base_demo.xml in the base module):
481
Let's review an example taken from the OpenERP source (base_demo.xml in the base module):
483
.. i18n: .. code-block:: xml
485
.. i18n: <record model="res.company" id="main_company">
486
.. i18n: <field name="name">Tiny sprl</field>
487
.. i18n: <field name="partner_id" ref="main_partner"/>
488
.. i18n: <field name="currency_id" ref="EUR"/>
494
<record model="res.company" id="main_company">
495
<field name="name">Tiny sprl</field>
496
<field name="partner_id" ref="main_partner"/>
497
<field name="currency_id" ref="EUR"/>
500
.. i18n: .. code-block:: xml
502
.. i18n: <record model="res.users" id="user_admin">
503
.. i18n: <field name="login">admin</field>
504
.. i18n: <field name="password">admin</field>
505
.. i18n: <field name="name">Administrator</field>
506
.. i18n: <field name="signature">Administrator</field>
507
.. i18n: <field name="action_id" ref="action_menu_admin"/>
508
.. i18n: <field name="menu_id" ref="action_menu_admin"/>
509
.. i18n: <field name="address_id" ref="main_address"/>
510
.. i18n: <field name="groups_id" eval="[(6,0,[group_admin])]"/>
511
.. i18n: <field name="company_id" ref="main_company"/>
517
<record model="res.users" id="user_admin">
518
<field name="login">admin</field>
519
<field name="password">admin</field>
520
<field name="name">Administrator</field>
521
<field name="signature">Administrator</field>
522
<field name="action_id" ref="action_menu_admin"/>
523
<field name="menu_id" ref="action_menu_admin"/>
524
<field name="address_id" ref="main_address"/>
525
<field name="groups_id" eval="[(6,0,[group_admin])]"/>
526
<field name="company_id" ref="main_company"/>
529
.. i18n: This last record defines the admin user :
532
This last record defines the admin user :
534
.. i18n: * The fields login, password, etc are straightforward.
535
.. i18n: * The ref attribute allows to fill relations between the records :
538
* The fields login, password, etc are straightforward.
539
* The ref attribute allows to fill relations between the records :
541
.. i18n: .. code-block:: xml
543
.. i18n: <field name="company_id" ref="main_company"/>
548
<field name="company_id" ref="main_company"/>
550
.. i18n: The field **company_id** is a many-to-one relation from the user object to the company object, and **main_company** is the id of to associate.
553
The field **company_id** is a many-to-one relation from the user object to the company object, and **main_company** is the id of to associate.
555
.. i18n: * The **eval** attribute allows to put some python code in the xml: here the groups_id field is a many2many. For such a field, "[(6,0,[group_admin])]" means : Remove all the groups associated with the current user and use the list [group_admin] as the new associated groups (and group_admin is the id of another record).
557
.. i18n: * The **search** attribute allows to find the record to associate when you do not know its xml id. You can thus specify a search criteria to find the wanted record. The criteria is a list of tuples of the same form than for the predefined search method. If there are several results, an arbitrary one will be chosen (the first one):
560
* The **eval** attribute allows to put some python code in the xml: here the groups_id field is a many2many. For such a field, "[(6,0,[group_admin])]" means : Remove all the groups associated with the current user and use the list [group_admin] as the new associated groups (and group_admin is the id of another record).
562
* The **search** attribute allows to find the record to associate when you do not know its xml id. You can thus specify a search criteria to find the wanted record. The criteria is a list of tuples of the same form than for the predefined search method. If there are several results, an arbitrary one will be chosen (the first one):
564
.. i18n: .. code-block:: xml
566
.. i18n: <field name="partner_id" search="[]" model="res.partner"/>
571
<field name="partner_id" search="[]" model="res.partner"/>
573
.. i18n: This is a classical example of the use of **search** in demo data: here we do not really care about which partner we want to use for the test, so we give an empty list. Notice the **model** attribute is currently mandatory.
576
This is a classical example of the use of **search** in demo data: here we do not really care about which partner we want to use for the test, so we give an empty list. Notice the **model** attribute is currently mandatory.
585
.. i18n: **Description**
590
.. i18n: The addition of new data is made with the record tag. This one takes a mandatory attribute : model. Model is the object name where the insertion has to be done. The tag record can also take an optional attribute: id. If this attribute is given, a variable of this name can be used later on, in the same file, to make reference to the newly created resource ID.
593
The addition of new data is made with the record tag. This one takes a mandatory attribute : model. Model is the object name where the insertion has to be done. The tag record can also take an optional attribute: id. If this attribute is given, a variable of this name can be used later on, in the same file, to make reference to the newly created resource ID.
595
.. i18n: A record tag may contain field tags. They indicate the record's fields value. If a field is not specified the default value will be used.
598
A record tag may contain field tags. They indicate the record's fields value. If a field is not specified the default value will be used.
605
.. i18n: .. code-block:: xml
607
.. i18n: <record model="ir.actions.report.xml" id="l0">
608
.. i18n: <field name="model">account.invoice</field>
609
.. i18n: <field name="name">Invoices List</field>
610
.. i18n: <field name="report_name">account.invoice.list</field>
611
.. i18n: <field name="report_xsl">account/report/invoice.xsl</field>
612
.. i18n: <field name="report_xml">account/report/invoice.xml</field>
618
<record model="ir.actions.report.xml" id="l0">
619
<field name="model">account.invoice</field>
620
<field name="name">Invoices List</field>
621
<field name="report_name">account.invoice.list</field>
622
<field name="report_xsl">account/report/invoice.xsl</field>
623
<field name="report_xml">account/report/invoice.xml</field>
633
.. i18n: The attributes for the field tag are the following:
636
The attributes for the field tag are the following:
638
.. i18n: name : mandatory
639
.. i18n: the field name
645
.. i18n: eval : optional
646
.. i18n: python expression that indicating the value to add
649
.. i18n: reference to an id defined in this file
653
python expression that indicating the value to add
656
reference to an id defined in this file
659
.. i18n: model to be looked up in the search
663
model to be looked up in the search
672
.. i18n: Function tag
673
.. i18n: """"""""""""
679
.. i18n: A function tag can contain other function tags.
682
A function tag can contain other function tags.
684
.. i18n: model : mandatory
685
.. i18n: The model to be used
691
.. i18n: name : mandatory
692
.. i18n: the function given name
696
the function given name
699
.. i18n: should evaluate to the list of parameters of the method to be called, excluding cr and uid
703
should evaluate to the list of parameters of the method to be called, excluding cr and uid
710
.. i18n: .. code-block:: xml
712
.. i18n: <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
717
<function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
726
.. i18n: Takes a subset of the evaluation of the last child node of the tag.
729
Takes a subset of the evaluation of the last child node of the tag.
731
.. i18n: type : mandatory
738
.. i18n: index : mandatory
739
.. i18n: int or string (a key of a dictionary)
743
int or string (a key of a dictionary)
750
.. i18n: Evaluates to the first element of the list of ids returned by the function node
753
Evaluates to the first element of the list of ids returned by the function node
755
.. i18n: .. code-block:: xml
757
.. i18n: <getitem index="0" type="list">
758
.. i18n: <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
764
<getitem index="0" type="list">
765
<function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
775
.. i18n: Improving Translations
776
.. i18n: """"""""""""""""""""""
779
Improving Translations
780
""""""""""""""""""""""
782
.. i18n: .. describe:: Translating in launchpad
785
.. describe:: Translating in launchpad
787
.. i18n: Translations are managed by
788
.. i18n: the `Launchpad Web interface <https://translations.launchpad.net/openobject>`_. Here, you'll
789
.. i18n: find the list of translatable projects.
792
Translations are managed by
793
the `Launchpad Web interface <https://translations.launchpad.net/openobject>`_. Here, you'll
794
find the list of translatable projects.
796
.. i18n: Please read the `FAQ <https://answers.launchpad.net/rosetta/+faqs>`_ before asking questions.
799
Please read the `FAQ <https://answers.launchpad.net/rosetta/+faqs>`_ before asking questions.
801
.. i18n: .. describe:: Translating your own module
804
.. describe:: Translating your own module
806
.. i18n: .. versionchanged:: 5.0
809
.. versionchanged:: 5.0
811
.. i18n: Contrary to the 4.2.x version, the translations are now done by module. So,
812
.. i18n: instead of an unique ``i18n`` folder for the whole application, each module has
813
.. i18n: its own ``i18n`` folder. In addition, OpenERP can now deal with ``.po`` [#f_po]_
814
.. i18n: files as import/export format. The translation files of the installed languages
815
.. i18n: are automatically loaded when installing or updating a module. OpenERP can also
816
.. i18n: generate a .tgz archive containing well organised ``.po`` files for each selected
820
Contrary to the 4.2.x version, the translations are now done by module. So,
821
instead of an unique ``i18n`` folder for the whole application, each module has
822
its own ``i18n`` folder. In addition, OpenERP can now deal with ``.po`` [#f_po]_
823
files as import/export format. The translation files of the installed languages
824
are automatically loaded when installing or updating a module. OpenERP can also
825
generate a .tgz archive containing well organised ``.po`` files for each selected
828
.. i18n: .. [#f_po] http://www.gnu.org/software/autoconf/manual/gettext/PO-Files.html#PO-Files
831
.. [#f_po] http://www.gnu.org/software/autoconf/manual/gettext/PO-Files.html#PO-Files
840
.. i18n: Defining the process
841
.. i18n: """"""""""""""""""""
847
.. i18n: Through the interface and module recorder.
848
.. i18n: Then, put the generated XML in your own module.
851
Through the interface and module recorder.
852
Then, put the generated XML in your own module.
861
.. i18n: Technical Specifications - Architecture - Views
862
.. i18n: """""""""""""""""""""""""""""""""""""""""""""""
865
Technical Specifications - Architecture - Views
866
"""""""""""""""""""""""""""""""""""""""""""""""
868
.. i18n: Views are a way to represent the objects on the client side. They indicate to the client how to lay out the data coming from the objects on the screen.
871
Views are a way to represent the objects on the client side. They indicate to the client how to lay out the data coming from the objects on the screen.
873
.. i18n: There are two types of views:
876
There are two types of views:
878
.. i18n: * form views
879
.. i18n: * tree views
885
.. i18n: Lists are simply a particular case of tree views.
888
Lists are simply a particular case of tree views.
890
.. i18n: A same object may have several views: the first defined view of a kind (*tree, form*, ...) will be used as the default view for this kind. That way you can have a default tree view (that will act as the view of a one2many) and a specialized view with more or less information that will appear when one double-clicks on a menu item. For example, the products have several views according to the product variants.
893
A same object may have several views: the first defined view of a kind (*tree, form*, ...) will be used as the default view for this kind. That way you can have a default tree view (that will act as the view of a one2many) and a specialized view with more or less information that will appear when one double-clicks on a menu item. For example, the products have several views according to the product variants.
895
.. i18n: Views are described in XML.
898
Views are described in XML.
900
.. i18n: If no view has been defined for an object, the object is able to generate a view to represent itself. This can limit the developer's work but results in less ergonomic views.
903
If no view has been defined for an object, the object is able to generate a view to represent itself. This can limit the developer's work but results in less ergonomic views.
905
.. i18n: Usage example
906
.. i18n: """""""""""""
912
.. i18n: When you open an invoice, here is the chain of operations followed by the client:
915
When you open an invoice, here is the chain of operations followed by the client:
917
.. i18n: * An action asks to open the invoice (it gives the object's data (account.invoice), the view, the domain (e.g. only unpaid invoices) ).
918
.. i18n: * 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.
919
.. i18n: * The client displays the form according to the view
922
* An action asks to open the invoice (it gives the object's data (account.invoice), the view, the domain (e.g. only unpaid invoices) ).
923
* 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.
924
* The client displays the form according to the view
926
.. i18n: .. figure:: images/arch_view_use.png
928
.. i18n: :align: center
931
.. figure:: images/arch_view_use.png
935
.. i18n: To develop new objects
936
.. i18n: """"""""""""""""""""""
939
To develop new objects
940
""""""""""""""""""""""
942
.. i18n: The design of new objects is restricted to the minimum: create the objects and optionally create the views to represent them. The PostgreSQL tables do not have to be written by hand because the objects are able to automatically create them (or adapt them in case they already exist).
945
The design of new objects is restricted to the minimum: create the objects and optionally create the views to represent them. The PostgreSQL tables do not have to be written by hand because the objects are able to automatically create them (or adapt them in case they already exist).
954
.. i18n: OpenERP uses a flexible and powerful reporting system. Reports are generated either in PDF or in HTML. Reports are designed on the principle of separation between the data layer and the presentation layer.
957
OpenERP uses a flexible and powerful reporting system. Reports are generated either in PDF or in HTML. Reports are designed on the principle of separation between the data layer and the presentation layer.
959
.. i18n: Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
962
Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
971
.. i18n: Here's an example of a .XML file that declares a wizard.
974
Here's an example of a .XML file that declares a wizard.
976
.. i18n: .. code-block:: xml
978
.. i18n: <?xml version="1.0"?>
981
.. i18n: <wizard string="Employee Info"
982
.. i18n: model="hr.employee"
983
.. i18n: name="employee.info.wizard"
984
.. i18n: id="wizard_employee_info"/>
991
<?xml version="1.0"?>
994
<wizard string="Employee Info"
996
name="employee.info.wizard"
997
id="wizard_employee_info"/>
1001
.. i18n: A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
1004
A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
1006
.. i18n: also you can add wizard in menu using following xml entry
1009
also you can add wizard in menu using following xml entry
1011
.. i18n: .. code-block:: xml
1013
.. i18n: <?xml version="1.0"?>
1016
.. i18n: <wizard string="Employee Info"
1017
.. i18n: model="hr.employee"
1018
.. i18n: name="employee.info.wizard"
1019
.. i18n: id="wizard_employee_info"/>
1021
.. i18n: name="Human Resource/Employee Info"
1022
.. i18n: action="wizard_employee_info"
1023
.. i18n: type="wizard"
1024
.. i18n: id="menu_wizard_employee_info"/>
1031
<?xml version="1.0"?>
1034
<wizard string="Employee Info"
1036
name="employee.info.wizard"
1037
id="wizard_employee_info"/>
1039
name="Human Resource/Employee Info"
1040
action="wizard_employee_info"
1042
id="menu_wizard_employee_info"/>
1053
.. i18n: The objects and the views allow you to define new forms very simply, lists/trees and interactions between them. But it is not enough : you have to define the dynamics of these objects.
1056
The objects and the views allow you to define new forms very simply, lists/trees and interactions between them. But it is not enough : you have to define the dynamics of these objects.
1058
.. i18n: A few examples:
1063
.. i18n: * a confirmed sale order must generate an invoice, according to certain conditions
1064
.. i18n: * a paid invoice must, only under certain conditions, start the shipping order
1067
* a confirmed sale order must generate an invoice, according to certain conditions
1068
* a paid invoice must, only under certain conditions, start the shipping order
1070
.. i18n: The workflows describe these interactions with graphs. One or several workflows may be associated to the objects. Workflows are not mandatory; some objects don't have workflows.
1073
The workflows describe these interactions with graphs. One or several workflows may be associated to the objects. Workflows are not mandatory; some objects don't have workflows.
1075
.. i18n: Below is an example workflow used for sale orders. It must generate invoices and shipments according to certain conditions.
1078
Below is an example workflow used for sale orders. It must generate invoices and shipments according to certain conditions.
1080
.. i18n: .. figure:: images/arch_workflow_sale.png
1082
.. i18n: :align: center
1085
.. figure:: images/arch_workflow_sale.png
1089
.. i18n: In this graph, the nodes represent the actions to be done:
1092
In this graph, the nodes represent the actions to be done:
1094
.. i18n: * create an invoice,
1095
.. i18n: * cancel the sale order,
1096
.. i18n: * generate the shipping order, ...
1099
* create an invoice,
1100
* cancel the sale order,
1101
* generate the shipping order, ...
1103
.. i18n: The arrows are the conditions;
1106
The arrows are the conditions;
1108
.. i18n: * waiting for the order validation,
1109
.. i18n: * invoice paid,
1110
.. i18n: * click on the cancel button, ...
1113
* waiting for the order validation,
1115
* click on the cancel button, ...
1117
.. i18n: The squared nodes represent other Workflows;
1120
The squared nodes represent other Workflows;
1122
.. i18n: * the invoice
1123
.. i18n: * the shipping
added
removed
i18n/ru/source/developer/2_4_module_development/4_1_module_structure.rst
