← Back to branch summary

~xrg/openobject-doc/trunk-xrg

« back to all changes in this revision

Viewing changes to i18n/vi/source/developer/2_4_module_development/4_1_module_structure.rst

  • Committer: TruongSinh Tran
  • Date: 2009-07-17 18:59:45 UTC
  • Revision ID: truongsinh@vipescoserver-20090717185945-ajjp3zso6xh5jddm
[FIX]private issue

Show diffs side-by-side

added added

removed removed

Lines of Context:
i18n/vi/source/developer/2_4_module_development/4_1_module_structure.rst
 
1
 
 
2
.. i18n: Module Structure
 
3
.. i18n: ================
 
4
 
 
5
Module Structure
 
6
================
 
7
 
 
8
.. i18n: The Modules
 
9
.. i18n: -----------
 
10
 
 
11
The Modules
 
12
-----------
 
13
 
 
14
.. i18n:    #. Introduction
 
15
.. i18n:    #. Files & Directories
 
16
.. i18n:          #. __terp__.py
 
17
.. i18n:          #. __init__.py
 
18
.. i18n:          #. XML Files
 
19
.. i18n:                #. Actions
 
20
.. i18n:                #. Menu Entries
 
21
.. i18n:                #. Reports
 
22
.. i18n:                #. Wizards
 
23
.. i18n:    #. Profiles
 
24
 
 
25
   #. Introduction
 
26
   #. Files & Directories
 
27
         #. __terp__.py
 
28
         #. __init__.py
 
29
         #. XML Files
 
30
               #. Actions
 
31
               #. Menu Entries
 
32
               #. Reports
 
33
               #. Wizards
 
34
   #. Profiles
 
35
 
 
36
.. i18n: Modules - Files and Directories
 
37
.. i18n: -------------------------------
 
38
 
 
39
Modules - Files and Directories
 
40
-------------------------------
 
41
 
 
42
.. i18n: All the modules are located in the server/addons directory.
 
43
 
 
44
All the modules are located in the server/addons directory.
 
45
 
 
46
.. i18n: The following steps are necessary to create a new module:
 
47
 
 
48
The following steps are necessary to create a new module:
 
49
 
 
50
.. i18n:     * create a subdirectory in the server/addons directory
 
51
.. i18n:     * create a module description file: **__terp__.py**
 
52
.. i18n:     * create the **Python** file containing the **objects**
 
53
.. i18n:     * create **.xml files** that download the data (views, menu entries, demo data, ...)
 
54
.. i18n:     * optionally create **reports**, **wizards** or **workflows**.
 
55
 
 
56
    * create a subdirectory in the server/addons directory
 
57
    * create a module description file: **__terp__.py**
 
58
    * create the **Python** file containing the **objects**
 
59
    * create **.xml files** that download the data (views, menu entries, demo data, ...)
 
60
    * optionally create **reports**, **wizards** or **workflows**.
 
61
 
 
62
.. i18n: !The Modules - Files And Directories - XML Files
 
63
 
 
64
!The Modules - Files And Directories - XML Files
 
65
 
 
66
.. i18n: XML files located in the module directory are used to modify the structure of
 
67
.. i18n: the database. They are used for many purposes, among which we can cite :
 
68
 
 
69
XML files located in the module directory are used to modify the structure of
 
70
the database. They are used for many purposes, among which we can cite :
 
71
 
 
72
.. i18n:     * initialization and demonstration data declaration,
 
73
.. i18n:     * views declaration,
 
74
.. i18n:     * reports declaration,
 
75
.. i18n:     * wizards declaration,
 
76
.. i18n:     * workflows declaration.
 
77
 
 
78
    * initialization and demonstration data declaration,
 
79
    * views declaration,
 
80
    * reports declaration,
 
81
    * wizards declaration,
 
82
    * workflows declaration.
 
83
 
 
84
.. i18n: General structure of Tiny ERP XML files is more detailed in the section `Data Loading Files XML <http://doc.openerp.com/developer/index.html>`_. Look here if you are interested in learning more about *initialization* and *demonstration data declaration* XML files. The following section are only related to XML specific to *actions, menu entries, reports, wizards* and *workflows* declaration.
 
85
 
 
86
General structure of Tiny ERP XML files is more detailed in the section `Data Loading Files XML <http://doc.openerp.com/developer/index.html>`_. Look here if you are interested in learning more about *initialization* and *demonstration data declaration* XML files. The following section are only related to XML specific to *actions, menu entries, reports, wizards* and *workflows* declaration.
 
87
 
 
88
.. i18n: Python Module Descriptor File __init__.py
 
89
.. i18n: +++++++++++++++++++++++++++++++++++++++++
 
90
 
 
91
Python Module Descriptor File __init__.py
 
92
+++++++++++++++++++++++++++++++++++++++++
 
93
 
 
94
.. i18n: **The __init__.py file**
 
95
 
 
96
**The __init__.py file**
 
97
 
 
98
.. 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.
 
99
 
 
100
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.
 
101
 
 
102
.. i18n: So, if you create a "module.py" file, containing the description of your objects, you have to write one line in __init__.py::
 
103
.. i18n: 
 
104
.. i18n:     import module
 
105
 
 
106
So, if you create a "module.py" file, containing the description of your objects, you have to write one line in __init__.py::
 
107
 
 
108
    import module
 
109
 
 
110
.. i18n: OpenERP Module Descriptor File __terp__.py
 
111
.. i18n: ++++++++++++++++++++++++++++++++++++++++++
 
112
 
 
113
OpenERP Module Descriptor File __terp__.py
 
114
++++++++++++++++++++++++++++++++++++++++++
 
115
 
 
116
.. i18n: In the created module directory, you must add a **__terp__.py** file. This file, which must be in Python format, is responsible to
 
117
 
 
118
In the created module directory, you must add a **__terp__.py** file. This file, which must be in Python format, is responsible to
 
119
 
 
120
.. i18n:    1. determine the *XML files that will be parsed* during the initialization of the server, and also to
 
121
.. i18n:    2. determine the *dependencies* of the created module.
 
122
 
 
123
   1. determine the *XML files that will be parsed* during the initialization of the server, and also to
 
124
   2. determine the *dependencies* of the created module.
 
125
 
 
126
.. i18n: This file must contain a Python dictionary with the following values:
 
127
 
 
128
This file must contain a Python dictionary with the following values:
 
129
 
 
130
.. i18n: **name**
 
131
 
 
132
**name**
 
133
 
 
134
.. i18n:     The (Plain English) name of the module.
 
135
 
 
136
    The (Plain English) name of the module.
 
137
 
 
138
.. i18n: **version**
 
139
 
 
140
**version**
 
141
 
 
142
.. i18n:     The version of the module.
 
143
 
 
144
    The version of the module.
 
145
 
 
146
.. i18n: **description**
 
147
 
 
148
**description**
 
149
 
 
150
.. i18n:     The module description (text).
 
151
 
 
152
    The module description (text).
 
153
 
 
154
.. i18n: **author**
 
155
 
 
156
**author**
 
157
 
 
158
.. i18n:     The author of the module.
 
159
 
 
160
    The author of the module.
 
161
 
 
162
.. i18n: **website**
 
163
 
 
164
**website**
 
165
 
 
166
.. i18n:     The website of the module.
 
167
 
 
168
    The website of the module.
 
169
 
 
170
.. i18n: **license**
 
171
 
 
172
**license**
 
173
 
 
174
.. i18n:     The license of the module (default:GPL-2).
 
175
 
 
176
    The license of the module (default:GPL-2).
 
177
 
 
178
.. i18n: **depends**
 
179
 
 
180
**depends**
 
181
 
 
182
.. 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.
 
183
 
 
184
    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.
 
185
 
 
186
.. i18n: **init_xml**
 
187
 
 
188
**init_xml**
 
189
 
 
190
.. 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. Open ERP XML File Format is detailed in this section.
 
191
 
 
192
    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. Open ERP XML File Format is detailed in this section.
 
193
 
 
194
.. i18n: **update_xml**
 
195
 
 
196
**update_xml**
 
197
 
 
198
.. 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. Open ERP XML File Format is detailed in this section.
 
199
 
 
200
    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. Open ERP XML File Format is detailed in this section.
 
201
 
 
202
.. i18n: **installable**
 
203
 
 
204
**installable**
 
205
 
 
206
.. i18n:     True or False. Determines if the module is installable or not.
 
207
 
 
208
    True or False. Determines if the module is installable or not.
 
209
 
 
210
.. i18n: **active**
 
211
 
 
212
**active**
 
213
 
 
214
.. i18n:     True or False (default: False). Determines the modules that are installed on the database creation.
 
215
 
 
216
    True or False (default: False). Determines the modules that are installed on the database creation.
 
217
 
 
218
.. i18n: **Example**
 
219
 
 
220
**Example**
 
221
 
 
222
.. i18n: Here is an example of __terp__.py file for the product module
 
223
 
 
224
Here is an example of __terp__.py file for the product module
 
225
 
 
226
.. i18n: .. code-block:: xml
 
227
.. i18n: 
 
228
.. i18n:     {
 
229
.. i18n:         "name" : "Products & Pricelists",
 
230
.. i18n:         "version" : "1.0",
 
231
.. i18n:         "author" : "Open",
 
232
.. i18n:         "category" : "Generic Modules/Inventory Control",
 
233
.. i18n:         "depends" : ["base", "account"],
 
234
.. i18n:         "init_xml" : [],
 
235
.. i18n:         "demo_xml" : ["product_demo.xml"],
 
236
.. i18n:         "update_xml" : ["product_data.xml","product_report.xml", "product_wizard.xml","product_view.xml", "pricelist_view.xml"],
 
237
.. i18n:         "installable": True,
 
238
.. i18n:         "active": True
 
239
.. i18n:     }
 
240
 
 
241
.. code-block:: xml
 
242
 
 
243
    {
 
244
        "name" : "Products & Pricelists",
 
245
        "version" : "1.0",
 
246
        "author" : "Open",
 
247
        "category" : "Generic Modules/Inventory Control",
 
248
        "depends" : ["base", "account"],
 
249
        "init_xml" : [],
 
250
        "demo_xml" : ["product_demo.xml"],
 
251
        "update_xml" : ["product_data.xml","product_report.xml", "product_wizard.xml","product_view.xml", "pricelist_view.xml"],
 
252
        "installable": True,
 
253
        "active": True
 
254
    }
 
255
 
 
256
.. 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.
 
257
 
 
258
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.
 
259
 
 
260
.. i18n: The files in **update_xml** concern: views, reports and wizards.
 
261
 
 
262
The files in **update_xml** concern: views, reports and wizards.
 
263
 
 
264
.. i18n: Objects
 
265
.. i18n: +++++++
 
266
 
 
267
Objects
 
268
+++++++
 
269
 
 
270
.. i18n: All Tiny ERP resources are objects: menus, actions, reports, invoices, partners, ... Tiny ERP is based on an object relational mapping of a database to control the information. Object names are hierarchical, as in the following examples:
 
271
 
 
272
All Tiny ERP resources are objects: menus, actions, reports, invoices, partners, ... Tiny ERP is based on an object relational mapping of a database to control the information. Object names are hierarchical, as in the following examples:
 
273
 
 
274
.. i18n:     * account.transfer : a money transfer
 
275
.. i18n:     * account.invoice : an invoice
 
276
.. i18n:     * account.invoice.line : an invoice line
 
277
 
 
278
    * account.transfer : a money transfer
 
279
    * account.invoice : an invoice
 
280
    * account.invoice.line : an invoice line
 
281
 
 
282
.. i18n: Generally, the first word is the name of the module: account, stock, sale.
 
283
 
 
284
Generally, the first word is the name of the module: account, stock, sale.
 
285
 
 
286
.. i18n: Other advantages of an ORM;
 
287
 
 
288
Other advantages of an ORM;
 
289
 
 
290
.. i18n:     * simpler relations : invoice.partner.address[0].city
 
291
.. i18n:     * objects have properties and methods: invoice.pay(3400 EUR),
 
292
.. i18n:     * inheritance, high level constraints, ...
 
293
 
 
294
    * simpler relations : invoice.partner.address[0].city
 
295
    * objects have properties and methods: invoice.pay(3400 EUR),
 
296
    * inheritance, high level constraints, ...
 
297
 
 
298
.. i18n: It is easier to manipulate one object (example, a partner) than several tables (partner address, categories, events, ...)
 
299
 
 
300
It is easier to manipulate one object (example, a partner) than several tables (partner address, categories, events, ...)
 
301
 
 
302
.. i18n: .. figure::  images/pom_3_0_3.png
 
303
.. i18n:    :scale: 50
 
304
.. i18n:    :align: center
 
305
.. i18n: 
 
306
.. i18n:    *The Physical Objects Model of [OpenERP version 3.0.3]*
 
307
 
 
308
.. figure::  images/pom_3_0_3.png
 
309
   :scale: 50
 
310
   :align: center
 
311
 
 
312
   *The Physical Objects Model of [OpenERP version 3.0.3]*
 
313
 
 
314
.. i18n: PostgreSQL
 
315
.. i18n: """"""""""
 
316
 
 
317
PostgreSQL
 
318
""""""""""
 
319
 
 
320
.. i18n: The ORM of Open ERP is constructed over PostgreSQL. It is thus possible to
 
321
.. i18n: query the object used by Open ERP using the object interface or by directly
 
322
.. i18n: using SQL statements.
 
323
 
 
324
The ORM of Open ERP is constructed over PostgreSQL. It is thus possible to
 
325
query the object used by Open ERP using the object interface or by directly
 
326
using SQL statements.
 
327
 
 
328
.. i18n: But it is dangerous to write or read directly in the PostgreSQL database, as
 
329
.. i18n: you will shortcut important steps like constraints checking or workflow
 
330
.. i18n: modification.
 
331
 
 
332
But it is dangerous to write or read directly in the PostgreSQL database, as
 
333
you will shortcut important steps like constraints checking or workflow
 
334
modification.
 
335
 
 
336
.. i18n: .. note::
 
337
.. i18n: 
 
338
.. i18n:     The Physical Database Model of OpenERP
 
339
 
 
340
.. note::
 
341
 
 
342
    The Physical Database Model of OpenERP
 
343
 
 
344
.. i18n: Pre-Installed Data
 
345
.. i18n: ++++++++++++++++++
 
346
 
 
347
Pre-Installed Data
 
348
++++++++++++++++++
 
349
 
 
350
.. i18n: ::
 
351
.. i18n: 
 
352
.. i18n:     %define=lightblue color=#27adfb%
 
353
 
 
354
::
 
355
 
 
356
    %define=lightblue color=#27adfb%
 
357
 
 
358
.. i18n: Data can be inserted or updated into the PostgreSQL tables corresponding to the
 
359
.. i18n: Tiny ERP objects using XML files. The general structure of a Tiny ERP XML file
 
360
.. i18n: is as follows: ::
 
361
.. i18n: 
 
362
.. i18n:     <?xml version="1.0"?>
 
363
.. i18n:      <terp>
 
364
.. i18n:              <data>
 
365
.. i18n:          <record model="model.name_1" id="id_name_1">
 
366
.. i18n:              <field name="field1">
 
367
.. i18n:                  %lightblue%"field1 content"
 
368
.. i18n:              </field>
 
369
.. i18n:              <field name="field2">
 
370
.. i18n:                  %lightblue%"field2 content"
 
371
.. i18n:              </field>
 
372
.. i18n:              (...)
 
373
.. i18n:          </record>
 
374
.. i18n:          <record model="model.name_2" id="id_name_2">
 
375
.. i18n:              (...)
 
376
.. i18n:          </record>
 
377
.. i18n:          (...)
 
378
.. i18n:          </data>
 
379
.. i18n:      </terp>
 
380
 
 
381
Data can be inserted or updated into the PostgreSQL tables corresponding to the
 
382
Tiny ERP objects using XML files. The general structure of a Tiny ERP XML file
 
383
is as follows: ::
 
384
 
 
385
    <?xml version="1.0"?>
 
386
     <terp>
 
387
             <data>
 
388
         <record model="model.name_1" id="id_name_1">
 
389
             <field name="field1">
 
390
                 %lightblue%"field1 content"
 
391
             </field>
 
392
             <field name="field2">
 
393
                 %lightblue%"field2 content"
 
394
             </field>
 
395
             (...)
 
396
         </record>
 
397
         <record model="model.name_2" id="id_name_2">
 
398
             (...)
 
399
         </record>
 
400
         (...)
 
401
         </data>
 
402
     </terp>
 
403
 
 
404
.. i18n: Fields content are strings that must be encoded as *UTF-8* in XML files.
 
405
 
 
406
Fields content are strings that must be encoded as *UTF-8* in XML files.
 
407
 
 
408
.. i18n: Let's review an example taken from the TinyERP source (base_demo.xml in the base module):
 
409
 
 
410
Let's review an example taken from the TinyERP source (base_demo.xml in the base module):
 
411
 
 
412
.. i18n: .. code-block:: xml
 
413
.. i18n: 
 
414
.. i18n:        <record model="res.company" id="main_company">
 
415
.. i18n:            <field name="name">Tiny sprl</field>
 
416
.. i18n:            <field name="partner_id" ref="main_partner"/>
 
417
.. i18n:            <field name="currency_id" ref="EUR"/>
 
418
.. i18n:        </record>
 
419
 
 
420
.. code-block:: xml
 
421
 
 
422
       <record model="res.company" id="main_company">
 
423
           <field name="name">Tiny sprl</field>
 
424
           <field name="partner_id" ref="main_partner"/>
 
425
           <field name="currency_id" ref="EUR"/>
 
426
       </record>
 
427
 
 
428
.. i18n: .. code-block:: xml
 
429
.. i18n: 
 
430
.. i18n:        <record model="res.users" id="user_admin">
 
431
.. i18n:            <field name="login">admin</field>
 
432
.. i18n:            <field name="password">admin</field>
 
433
.. i18n:            <field name="name">Administrator</field>
 
434
.. i18n:            <field name="signature">Administrator</field>
 
435
.. i18n:            <field name="action_id" ref="action_menu_admin"/>
 
436
.. i18n:            <field name="menu_id" ref="action_menu_admin"/>
 
437
.. i18n:            <field name="address_id" ref="main_address"/>
 
438
.. i18n:            <field name="groups_id" eval="[(6,0,[group_admin])]"/>
 
439
.. i18n:            <field name="company_id" ref=" *main_company* "/>
 
440
.. i18n:        </record>
 
441
 
 
442
.. code-block:: xml
 
443
 
 
444
       <record model="res.users" id="user_admin">
 
445
           <field name="login">admin</field>
 
446
           <field name="password">admin</field>
 
447
           <field name="name">Administrator</field>
 
448
           <field name="signature">Administrator</field>
 
449
           <field name="action_id" ref="action_menu_admin"/>
 
450
           <field name="menu_id" ref="action_menu_admin"/>
 
451
           <field name="address_id" ref="main_address"/>
 
452
           <field name="groups_id" eval="[(6,0,[group_admin])]"/>
 
453
           <field name="company_id" ref=" *main_company* "/>
 
454
       </record>
 
455
 
 
456
.. i18n: This last record defines the admin user :
 
457
 
 
458
This last record defines the admin user :
 
459
 
 
460
.. i18n:     * The fields login, password, etc are straightforward.
 
461
.. i18n:     * The ref attribute allows to fill relations between the records :
 
462
 
 
463
    * The fields login, password, etc are straightforward.
 
464
    * The ref attribute allows to fill relations between the records :
 
465
 
 
466
.. i18n: .. code-block:: xml
 
467
.. i18n: 
 
468
.. i18n:        <field name="company_id" ref="main_company"/>
 
469
 
 
470
.. code-block:: xml
 
471
 
 
472
       <field name="company_id" ref="main_company"/>
 
473
 
 
474
.. 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.
 
475
 
 
476
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.
 
477
 
 
478
.. 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).
 
479
.. i18n: 
 
480
.. 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):
 
481
 
 
482
    * 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).
 
483
 
 
484
    * 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):
 
485
 
 
486
.. i18n: .. code-block:: xml
 
487
.. i18n: 
 
488
.. i18n:        <field name="partner_id" search="[]" model="res.partner"/>
 
489
 
 
490
.. code-block:: xml
 
491
 
 
492
       <field name="partner_id" search="[]" model="res.partner"/>
 
493
 
 
494
.. 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.
 
495
 
 
496
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.
 
497
 
 
498
.. i18n: Record Tag
 
499
.. i18n: """"""""""
 
500
 
 
501
Record Tag
 
502
""""""""""
 
503
 
 
504
.. i18n: **Description**
 
505
 
 
506
**Description**
 
507
 
 
508
.. 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.
 
509
 
 
510
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.
 
511
 
 
512
.. 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.
 
513
 
 
514
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.
 
515
 
 
516
.. i18n: **Example**
 
517
 
 
518
**Example**
 
519
 
 
520
.. i18n: .. code-block:: xml
 
521
.. i18n: 
 
522
.. i18n:     <record model="ir.actions.report.xml" id="l0">
 
523
.. i18n:          <field name="model">account.invoice</field>
 
524
.. i18n:          <field name="name">Invoices List</field>
 
525
.. i18n:          <field name="report_name">account.invoice.list</field>
 
526
.. i18n:          <field name="report_xsl">account/report/invoice.xsl</field>
 
527
.. i18n:          <field name="report_xml">account/report/invoice.xml</field>
 
528
.. i18n:     </record>
 
529
 
 
530
.. code-block:: xml
 
531
 
 
532
    <record model="ir.actions.report.xml" id="l0">
 
533
         <field name="model">account.invoice</field>
 
534
         <field name="name">Invoices List</field>
 
535
         <field name="report_name">account.invoice.list</field>
 
536
         <field name="report_xsl">account/report/invoice.xsl</field>
 
537
         <field name="report_xml">account/report/invoice.xml</field>
 
538
    </record>
 
539
 
 
540
.. i18n: **field tag**
 
541
 
 
542
**field tag**
 
543
 
 
544
.. i18n: The attributes for the field tag are the following:
 
545
 
 
546
The attributes for the field tag are the following:
 
547
 
 
548
.. i18n:     * name
 
549
.. i18n:           - mandatory attribute indicating the field name
 
550
.. i18n:     * eval
 
551
.. i18n:           - python expression that indicating the value to add
 
552
.. i18n:     * ref
 
553
.. i18n:           - reference to an id defined in this file
 
554
 
 
555
    * name
 
556
          - mandatory attribute indicating the field name
 
557
    * eval
 
558
          - python expression that indicating the value to add
 
559
    * ref
 
560
          - reference to an id defined in this file
 
561
 
 
562
.. i18n: **function tag**
 
563
 
 
564
**function tag**
 
565
 
 
566
.. i18n:     * model:
 
567
.. i18n:     * name:
 
568
.. i18n:     * eval
 
569
.. i18n:           o should evaluate to the list of parameters of the method to be called, excluding cr and uid
 
570
 
 
571
    * model:
 
572
    * name:
 
573
    * eval
 
574
          o should evaluate to the list of parameters of the method to be called, excluding cr and uid
 
575
 
 
576
.. i18n: **Example**
 
577
 
 
578
**Example**
 
579
 
 
580
.. i18n: .. code-block:: xml
 
581
.. i18n: 
 
582
.. i18n:     <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
583
 
 
584
.. code-block:: xml
 
585
 
 
586
    <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
587
 
 
588
.. i18n: **getitem tag**
 
589
 
 
590
**getitem tag**
 
591
 
 
592
.. i18n: Takes a subset of the evaluation of the last child node of the tag.
 
593
 
 
594
Takes a subset of the evaluation of the last child node of the tag.
 
595
 
 
596
.. i18n:     * type
 
597
.. i18n:           o int or list
 
598
.. i18n:     * index
 
599
.. i18n:     * int or string (a key of a dictionary)
 
600
 
 
601
    * type
 
602
          o int or list
 
603
    * index
 
604
    * int or string (a key of a dictionary)
 
605
 
 
606
.. i18n: **Example**
 
607
 
 
608
**Example**
 
609
 
 
610
.. i18n: Evaluates to the first element of the list of ids returned by the function node
 
611
 
 
612
Evaluates to the first element of the list of ids returned by the function node
 
613
 
 
614
.. i18n: .. code-block:: xml
 
615
.. i18n: 
 
616
.. i18n:     <getitem index="0" type="list">
 
617
.. i18n:         <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
618
.. i18n:     </getitem>
 
619
 
 
620
.. code-block:: xml
 
621
 
 
622
    <getitem index="0" type="list">
 
623
        <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
624
    </getitem>
 
625
 
 
626
.. i18n: i18n
 
627
.. i18n: ++++
 
628
 
 
629
i18n
 
630
++++
 
631
 
 
632
.. i18n: Improving Translations
 
633
.. i18n: """"""""""""""""""""""
 
634
 
 
635
Improving Translations
 
636
""""""""""""""""""""""
 
637
 
 
638
.. i18n: .. describe:: Translating in launchpad
 
639
 
 
640
.. describe:: Translating in launchpad
 
641
 
 
642
.. i18n: Translations are managed by
 
643
.. i18n: the `Launchpad Web interface <https://translations.launchpad.net/openobject>`_. Here, you'll
 
644
.. i18n: find the list of translatable projects.
 
645
 
 
646
Translations are managed by
 
647
the `Launchpad Web interface <https://translations.launchpad.net/openobject>`_. Here, you'll
 
648
find the list of translatable projects.
 
649
 
 
650
.. i18n: Please read the `FAQ <https://answers.launchpad.net/rosetta/+faqs>`_ before asking questions.
 
651
 
 
652
Please read the `FAQ <https://answers.launchpad.net/rosetta/+faqs>`_ before asking questions.
 
653
 
 
654
.. i18n: .. describe:: Translating your own module
 
655
 
 
656
.. describe:: Translating your own module
 
657
 
 
658
.. i18n: .. versionchanged:: 5.0
 
659
 
 
660
.. versionchanged:: 5.0
 
661
 
 
662
.. i18n: Contrary to the 4.2.x version, the translations are now done by module. So,
 
663
.. i18n: instead of an unique ``i18n`` folder for the whole application, each module has
 
664
.. i18n: its own ``i18n`` folder. In addition, OpenERP can now deal with ``.po`` [#f_po]_
 
665
.. i18n: files as import/export format. The translation files of the installed languages
 
666
.. i18n: are automatically loaded when installing or updating a module. OpenERP can also
 
667
.. i18n: generate a .tgz archive containing well organised ``.po`` files for each selected
 
668
.. i18n: module.
 
669
 
 
670
Contrary to the 4.2.x version, the translations are now done by module. So,
 
671
instead of an unique ``i18n`` folder for the whole application, each module has
 
672
its own ``i18n`` folder. In addition, OpenERP can now deal with ``.po`` [#f_po]_
 
673
files as import/export format. The translation files of the installed languages
 
674
are automatically loaded when installing or updating a module. OpenERP can also
 
675
generate a .tgz archive containing well organised ``.po`` files for each selected
 
676
module.
 
677
 
 
678
.. i18n: .. [#f_po] http://www.gnu.org/software/autoconf/manual/gettext/PO-Files.html#PO-Files
 
679
 
 
680
.. [#f_po] http://www.gnu.org/software/autoconf/manual/gettext/PO-Files.html#PO-Files
 
681
 
 
682
.. i18n: Process
 
683
.. i18n: +++++++
 
684
 
 
685
Process
 
686
+++++++
 
687
 
 
688
.. i18n: Defining the process
 
689
.. i18n: """"""""""""""""""""
 
690
 
 
691
Defining the process
 
692
""""""""""""""""""""
 
693
 
 
694
.. i18n: Thourgh the interface and module recorder
 
695
.. i18n: Then, put the generated XML in your own module
 
696
 
 
697
Thourgh the interface and module recorder
 
698
Then, put the generated XML in your own module
 
699
 
 
700
.. i18n: Views
 
701
.. i18n: +++++
 
702
 
 
703
Views
 
704
+++++
 
705
 
 
706
.. i18n: (:title Technical Specifications - Architecture - Views:) 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.
 
707
 
 
708
(:title Technical Specifications - Architecture - Views:) 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.
 
709
 
 
710
.. i18n: There are two types of views:
 
711
 
 
712
There are two types of views:
 
713
 
 
714
.. i18n:     * form views
 
715
.. i18n:     * tree views
 
716
 
 
717
    * form views
 
718
    * tree views
 
719
 
 
720
.. i18n: Lists are simply a particular case of tree views.
 
721
 
 
722
Lists are simply a particular case of tree views.
 
723
 
 
724
.. 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.
 
725
 
 
726
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.
 
727
 
 
728
.. i18n: Views are described in XML.
 
729
 
 
730
Views are described in XML.
 
731
 
 
732
.. 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.
 
733
 
 
734
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.
 
735
 
 
736
.. i18n: Usage example
 
737
.. i18n: """""""""""""
 
738
 
 
739
Usage example
 
740
"""""""""""""
 
741
 
 
742
.. i18n: When you open an invoice, here is the chain of operations followed by the client:
 
743
 
 
744
When you open an invoice, here is the chain of operations followed by the client:
 
745
 
 
746
.. 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) ).
 
747
.. 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.
 
748
.. i18n:     * The client displays the form according to the view
 
749
 
 
750
    * An action asks to open the invoice (it gives the object's data (account.invoice), the view, the domain (e.g. only unpaid invoices) ).
 
751
    * 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.
 
752
    * The client displays the form according to the view
 
753
 
 
754
.. i18n: .. figure::  images/arch_view_use.png
 
755
.. i18n:    :scale: 50
 
756
.. i18n:    :align: center
 
757
 
 
758
.. figure::  images/arch_view_use.png
 
759
   :scale: 50
 
760
   :align: center
 
761
 
 
762
.. i18n: To develop new objects
 
763
.. i18n: """"""""""""""""""""""
 
764
 
 
765
To develop new objects
 
766
""""""""""""""""""""""
 
767
 
 
768
.. 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).
 
769
 
 
770
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).
 
771
 
 
772
.. i18n: Reports
 
773
.. i18n: +++++++
 
774
 
 
775
Reports
 
776
+++++++
 
777
 
 
778
.. i18n: Open ERP 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.
 
779
 
 
780
Open ERP 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.
 
781
 
 
782
.. i18n: Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
 
783
 
 
784
Reports are described more in details in the `Reporting <http://openobject.com/wiki/index.php/Developers:Developper%27s_Book/Reports>`_ chapter.
 
785
 
 
786
.. i18n: Wizards
 
787
.. i18n: +++++++
 
788
 
 
789
Wizards
 
790
+++++++
 
791
 
 
792
.. i18n: Here's an example of a .XML file that declares a wizard.
 
793
 
 
794
Here's an example of a .XML file that declares a wizard.
 
795
 
 
796
.. i18n: ::
 
797
.. i18n: 
 
798
.. i18n:     <?xml version="1.0"?>
 
799
.. i18n:     <terp>
 
800
.. i18n:         <data>
 
801
.. i18n:          <wizard string="Employee Info"
 
802
.. i18n:                  model="hr.employee"
 
803
.. i18n:                  name="employee.info.wizard"
 
804
.. i18n:                  id="wizard_employee_info"/>
 
805
.. i18n:         </data>
 
806
.. i18n:     </terp>
 
807
 
 
808
::
 
809
 
 
810
    <?xml version="1.0"?>
 
811
    <terp>
 
812
        <data>
 
813
         <wizard string="Employee Info"
 
814
                 model="hr.employee"
 
815
                 name="employee.info.wizard"
 
816
                 id="wizard_employee_info"/>
 
817
        </data>
 
818
    </terp>
 
819
 
 
820
.. i18n: A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
 
821
 
 
822
A wizard is declared using a wizard tag. See "Add A New Wizard" for more information about wizard XML.
 
823
 
 
824
.. i18n: also you can add wizard in menu using following xml entry
 
825
 
 
826
also you can add wizard in menu using following xml entry
 
827
 
 
828
.. i18n: .. code-block:: xml
 
829
.. i18n: 
 
830
.. i18n:     <?xml version="1.0"?>
 
831
.. i18n:     <terp>
 
832
.. i18n:          <data>
 
833
.. i18n:          <wizard string="Employee Info"
 
834
.. i18n:                  model="hr.employee"
 
835
.. i18n:                  name="employee.info.wizard"
 
836
.. i18n:                  id="wizard_employee_info"/>
 
837
.. i18n:          <menuitem
 
838
.. i18n:                  name="Human Resource/Employee Info"
 
839
.. i18n:                  action="wizard_employee_info"
 
840
.. i18n:                  type="wizard"
 
841
.. i18n:                  id="menu_wizard_employee_info"/>
 
842
.. i18n:          </data>
 
843
.. i18n:     </terp>
 
844
 
 
845
.. code-block:: xml
 
846
 
 
847
    <?xml version="1.0"?>
 
848
    <terp>
 
849
         <data>
 
850
         <wizard string="Employee Info"
 
851
                 model="hr.employee"
 
852
                 name="employee.info.wizard"
 
853
                 id="wizard_employee_info"/>
 
854
         <menuitem
 
855
                 name="Human Resource/Employee Info"
 
856
                 action="wizard_employee_info"
 
857
                 type="wizard"
 
858
                 id="menu_wizard_employee_info"/>
 
859
         </data>
 
860
    </terp>
 
861
 
 
862
.. i18n: Workflow
 
863
.. i18n: ++++++++
 
864
 
 
865
Workflow
 
866
++++++++
 
867
 
 
868
.. 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.
 
869
 
 
870
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.
 
871
 
 
872
.. i18n: A few examples:
 
873
 
 
874
A few examples:
 
875
 
 
876
.. i18n:     * a confirmed sale order must generate an invoice, according to certain conditions
 
877
.. i18n:     * a paid invoice must, only under certain conditions, start the shipping order
 
878
 
 
879
    * a confirmed sale order must generate an invoice, according to certain conditions
 
880
    * a paid invoice must, only under certain conditions, start the shipping order
 
881
 
 
882
.. 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.
 
883
 
 
884
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.
 
885
 
 
886
.. i18n: Below is an example workflow used for sale orders. It must generate invoices and shipments according to certain conditions.
 
887
 
 
888
Below is an example workflow used for sale orders. It must generate invoices and shipments according to certain conditions.
 
889
 
 
890
.. i18n: .. figure::  images/arch_workflow_sale.png
 
891
.. i18n:    :scale: 85
 
892
.. i18n:    :align: center
 
893
 
 
894
.. figure::  images/arch_workflow_sale.png
 
895
   :scale: 85
 
896
   :align: center
 
897
 
 
898
.. i18n: In this graph, the nodes represent the actions to be done:
 
899
 
 
900
In this graph, the nodes represent the actions to be done:
 
901
 
 
902
.. i18n:     * create an invoice,
 
903
.. i18n:     * cancel the sale order,
 
904
.. i18n:     * generate the shipping order, ...
 
905
 
 
906
    * create an invoice,
 
907
    * cancel the sale order,
 
908
    * generate the shipping order, ...
 
909
 
 
910
.. i18n: The arrows are the conditions;
 
911
 
 
912
The arrows are the conditions;
 
913
 
 
914
.. i18n:     * waiting for the order validation,
 
915
.. i18n:     * invoice paid,
 
916
.. i18n:     * click on the cancel button, ...
 
917
 
 
918
    * waiting for the order validation,
 
919
    * invoice paid,
 
920
    * click on the cancel button, ...
 
921
 
 
922
.. i18n: The squared nodes represent other Workflows;
 
923
 
 
924
The squared nodes represent other Workflows;
 
925
 
 
926
.. i18n:     * the invoice
 
927
.. i18n:     * the shipping
 
928
 
 
929
    * the invoice
 
930
    * the shipping