← Back to branch summary

~xrg/openobject-doc/trunk-xrg

« back to all changes in this revision

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