← Back to branch summary

~xrg/openobject-doc/trunk-xrg

« back to all changes in this revision

Viewing changes to i18n/vi/source/developer/5_18_upgrading_server/19_1_upgrading_server.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/5_18_upgrading_server/19_1_upgrading_server.rst
 
1
 
 
2
.. i18n: Data Loading
 
3
.. i18n: ============
 
4
 
 
5
Data Loading
 
6
============
 
7
 
 
8
.. i18n: During Open ERP installation, two steps are necessary to create and feed the database:
 
9
 
 
10
During Open ERP installation, two steps are necessary to create and feed the database:
 
11
 
 
12
.. i18n:    1. Create the SQL tables
 
13
.. i18n:    2. Insert the different data into the tables
 
14
 
 
15
   1. Create the SQL tables
 
16
   2. Insert the different data into the tables
 
17
 
 
18
.. i18n: The creation (or modification in the case of an upgrade) of SQL tables is automated thanks to the description of objects in the server.
 
19
 
 
20
The creation (or modification in the case of an upgrade) of SQL tables is automated thanks to the description of objects in the server.
 
21
 
 
22
.. i18n: Into Open ERP, all the logic of the application is stored in the database. We find for example:
 
23
 
 
24
Into Open ERP, all the logic of the application is stored in the database. We find for example:
 
25
 
 
26
.. i18n:     * the definitions of the reports,
 
27
.. i18n:     * the object default values,
 
28
.. i18n:     * the form description of the interface client,
 
29
.. i18n:     * the relations between the menu and the client buttons, ...
 
30
 
 
31
    * the definitions of the reports,
 
32
    * the object default values,
 
33
    * the form description of the interface client,
 
34
    * the relations between the menu and the client buttons, ...
 
35
 
 
36
.. i18n: There must be a mechanism to describe, modify and reload the different data. These data are represented into a set of XML files that can possibly be loaded during start of the program in order to fill in the tables.
 
37
 
 
38
There must be a mechanism to describe, modify and reload the different data. These data are represented into a set of XML files that can possibly be loaded during start of the program in order to fill in the tables.
 
39
 
 
40
.. i18n: Files: .XML
 
41
.. i18n: -----------
 
42
.. i18n: ::
 
43
.. i18n: 
 
44
.. i18n:     %define=lightblue color=#27adfb%
 
45
 
 
46
Files: .XML
 
47
-----------
 
48
::
 
49
 
 
50
    %define=lightblue color=#27adfb%
 
51
 
 
52
.. 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 :
 
53
.. i18n: ::
 
54
.. i18n: 
 
55
.. i18n:      <?xml version="1.0"?>
 
56
.. i18n:      <terp>
 
57
.. i18n:          <data>
 
58
.. i18n:          <record model="model.name_1" id="id_name_1">
 
59
.. i18n:              <field name="field1">
 
60
.. i18n:                  %lightblue%"field1 content"
 
61
.. i18n:              </field>
 
62
.. i18n:              <field name="field2">
 
63
.. i18n:                  %lightblue%"field2 content"
 
64
.. i18n:              </field>
 
65
.. i18n:              (...)
 
66
.. i18n:          </record>
 
67
.. i18n:          <record model="model.name_2" id="id_name_2">
 
68
.. i18n:              (...)
 
69
.. i18n:          </record>
 
70
.. i18n:          (...)
 
71
.. i18n:          </data>
 
72
.. i18n:      </terp>
 
73
 
 
74
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 :
 
75
::
 
76
 
 
77
     <?xml version="1.0"?>
 
78
     <terp>
 
79
         <data>
 
80
         <record model="model.name_1" id="id_name_1">
 
81
             <field name="field1">
 
82
                 %lightblue%"field1 content"
 
83
             </field>
 
84
             <field name="field2">
 
85
                 %lightblue%"field2 content"
 
86
             </field>
 
87
             (...)
 
88
         </record>
 
89
         <record model="model.name_2" id="id_name_2">
 
90
             (...)
 
91
         </record>
 
92
         (...)
 
93
         </data>
 
94
     </terp>
 
95
 
 
96
.. i18n: Fields content are strings that must be encoded as UTF-8 in XML files.
 
97
 
 
98
Fields content are strings that must be encoded as UTF-8 in XML files.
 
99
 
 
100
.. i18n: Let's review an example taken from the TinyERP source (base_demo.xml in the base module):
 
101
.. i18n: ::
 
102
.. i18n: 
 
103
.. i18n:        <record model="res.company" id="main_company">
 
104
.. i18n:            <field name="name">Tiny sprl</field>
 
105
.. i18n:            <field name="partner_id" ref="main_partner"/>
 
106
.. i18n:            <field name="currency_id" ref="EUR"/>
 
107
.. i18n:        </record>
 
108
 
 
109
Let's review an example taken from the TinyERP source (base_demo.xml in the base module):
 
110
::
 
111
 
 
112
       <record model="res.company" id="main_company">
 
113
           <field name="name">Tiny sprl</field>
 
114
           <field name="partner_id" ref="main_partner"/>
 
115
           <field name="currency_id" ref="EUR"/>
 
116
       </record>
 
117
 
 
118
.. i18n: ::
 
119
.. i18n: 
 
120
.. i18n:        <record model="res.users" id="user_admin">
 
121
.. i18n:            <field name="login">admin</field>
 
122
.. i18n:            <field name="password">admin</field>
 
123
.. i18n:            <field name="name">Administrator</field>
 
124
.. i18n:            <field name="signature">Administrator</field>
 
125
.. i18n:            <field name="action_id" ref="action_menu_admin"/>
 
126
.. i18n:            <field name="menu_id" ref="action_menu_admin"/>
 
127
.. i18n:            <field name="address_id" ref="main_address"/>
 
128
.. i18n:            <field name="groups_id" eval="[(6,0,[group_admin])]"/>
 
129
.. i18n:            <field name="company_id" ref="main_company"/>
 
130
.. i18n:        </record>
 
131
 
 
132
::
 
133
 
 
134
       <record model="res.users" id="user_admin">
 
135
           <field name="login">admin</field>
 
136
           <field name="password">admin</field>
 
137
           <field name="name">Administrator</field>
 
138
           <field name="signature">Administrator</field>
 
139
           <field name="action_id" ref="action_menu_admin"/>
 
140
           <field name="menu_id" ref="action_menu_admin"/>
 
141
           <field name="address_id" ref="main_address"/>
 
142
           <field name="groups_id" eval="[(6,0,[group_admin])]"/>
 
143
           <field name="company_id" ref="main_company"/>
 
144
       </record>
 
145
 
 
146
.. i18n: This last record defines the admin user :
 
147
 
 
148
This last record defines the admin user :
 
149
 
 
150
.. i18n:     * The fields login, password, etc are straightforward.
 
151
.. i18n:     * The **ref** attribute allows to fill relations between the records :
 
152
 
 
153
    * The fields login, password, etc are straightforward.
 
154
    * The **ref** attribute allows to fill relations between the records :
 
155
 
 
156
.. i18n: ::
 
157
.. i18n: 
 
158
.. i18n:     <field name="company_id" ref="main_company"/>
 
159
 
 
160
::
 
161
 
 
162
    <field name="company_id" ref="main_company"/>
 
163
 
 
164
.. 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.
 
165
 
 
166
->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.
 
167
 
 
168
.. 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).
 
169
.. i18n: 
 
170
.. 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):
 
171
 
 
172
    * 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).
 
173
 
 
174
    * 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):
 
175
 
 
176
.. i18n:     <field name="partner_id" search="[]" model="res.partner"/>
 
177
 
 
178
    <field name="partner_id" search="[]" model="res.partner"/>
 
179
 
 
180
.. 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.
 
181
 
 
182
->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.
 
183
 
 
184
.. i18n: The Data
 
185
.. i18n: ++++++++
 
186
 
 
187
The Data
 
188
++++++++
 
189
 
 
190
.. i18n: Record Tag
 
191
.. i18n: """"""""""
 
192
 
 
193
Record Tag
 
194
""""""""""
 
195
 
 
196
.. i18n: Description
 
197
.. i18n: ~~~~~~~~~~~
 
198
 
 
199
Description
 
200
~~~~~~~~~~~
 
201
 
 
202
.. 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.
 
203
 
 
204
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.
 
205
 
 
206
.. 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.
 
207
 
 
208
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.
 
209
 
 
210
.. i18n: Example
 
211
.. i18n: ~~~~~~~
 
212
.. i18n: ::
 
213
.. i18n: 
 
214
.. i18n:     <record model="ir.actions.report.xml" id="l0">
 
215
.. i18n:          <field name="model">account.invoice</field>
 
216
.. i18n:          <field name="name">Invoices List</field>
 
217
.. i18n:          <field name="report_name">account.invoice.list</field>
 
218
.. i18n:          <field name="report_xsl">account/report/invoice.xsl</field>
 
219
.. i18n:          <field name="report_xml">account/report/invoice.xml</field>
 
220
.. i18n:     </record>
 
221
 
 
222
Example
 
223
~~~~~~~
 
224
::
 
225
 
 
226
    <record model="ir.actions.report.xml" id="l0">
 
227
         <field name="model">account.invoice</field>
 
228
         <field name="name">Invoices List</field>
 
229
         <field name="report_name">account.invoice.list</field>
 
230
         <field name="report_xsl">account/report/invoice.xsl</field>
 
231
         <field name="report_xml">account/report/invoice.xml</field>
 
232
    </record>
 
233
 
 
234
.. i18n: field tag
 
235
.. i18n: ~~~~~~~~~
 
236
 
 
237
field tag
 
238
~~~~~~~~~
 
239
 
 
240
.. i18n: The attributes for the field tag are the following:
 
241
 
 
242
The attributes for the field tag are the following:
 
243
 
 
244
.. i18n:     * **name**
 
245
.. i18n:           o mandatory attribute indicating the field name
 
246
.. i18n:     * **eval**
 
247
.. i18n:           o python expression that indicating the value to add
 
248
.. i18n:     * **ref**
 
249
.. i18n:           o reference to an id defined in this file
 
250
 
 
251
    * **name**
 
252
          o mandatory attribute indicating the field name
 
253
    * **eval**
 
254
          o python expression that indicating the value to add
 
255
    * **ref**
 
256
          o reference to an id defined in this file
 
257
 
 
258
.. i18n: function tag
 
259
.. i18n: ~~~~~~~~~~~~
 
260
 
 
261
function tag
 
262
~~~~~~~~~~~~
 
263
 
 
264
.. i18n:     * model:
 
265
.. i18n:     * name:
 
266
.. i18n:     * eval
 
267
.. i18n:           o should evaluate to the list of parameters of the method to be called, excluding cr and uid
 
268
 
 
269
    * model:
 
270
    * name:
 
271
    * eval
 
272
          o should evaluate to the list of parameters of the method to be called, excluding cr and uid
 
273
 
 
274
.. i18n: Example
 
275
.. i18n: ~~~~~~~
 
276
.. i18n: ::
 
277
.. i18n: 
 
278
.. i18n:     <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
279
 
 
280
Example
 
281
~~~~~~~
 
282
::
 
283
 
 
284
    <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
285
 
 
286
.. i18n: getitem tag
 
287
 
 
288
getitem tag
 
289
 
 
290
.. i18n: Takes a subset of the evaluation of the last child node of the tag.
 
291
 
 
292
Takes a subset of the evaluation of the last child node of the tag.
 
293
 
 
294
.. i18n:     * type
 
295
.. i18n:           - int or list
 
296
.. i18n:     * index
 
297
.. i18n:     * int or string (a key of a dictionary)
 
298
 
 
299
    * type
 
300
          - int or list
 
301
    * index
 
302
    * int or string (a key of a dictionary)
 
303
 
 
304
.. i18n: Example
 
305
.. i18n: ~~~~~~~
 
306
 
 
307
Example
 
308
~~~~~~~
 
309
 
 
310
.. i18n: Evaluates to the first element of the list of ids returned by the function node
 
311
 
 
312
Evaluates to the first element of the list of ids returned by the function node
 
313
 
 
314
.. i18n: .. code-block:: python
 
315
.. i18n: 
 
316
.. i18n:     <getitem index="0" type="list">
 
317
.. i18n:         <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
318
.. i18n:     </getitem>
 
319
 
 
320
.. code-block:: python
 
321
 
 
322
    <getitem index="0" type="list">
 
323
        <function model="ir.ui.menu" name="search" eval="[[('name','=','Operations')]]"/>
 
324
    </getitem>
 
325
 
 
326
.. i18n: CSV Files
 
327
.. i18n: ---------
 
328
 
 
329
CSV Files
 
330
---------
 
331
 
 
332
.. i18n: Importing from a CSV
 
333
.. i18n: ++++++++++++++++++++
 
334
 
 
335
Importing from a CSV
 
336
++++++++++++++++++++
 
337
 
 
338
.. i18n: Instead of using .XML file, you can import .CSV files. It is simpler but the migration system does not migrate the data imported from the .CSV files. It's like the noupdate attribute in .XML files. It's also more difficult to keep track of relations between ressources and it is more slower at the installation of the server.
 
339
 
 
340
Instead of using .XML file, you can import .CSV files. It is simpler but the migration system does not migrate the data imported from the .CSV files. It's like the noupdate attribute in .XML files. It's also more difficult to keep track of relations between ressources and it is more slower at the installation of the server.
 
341
 
 
342
.. i18n: Use this only for demo data that will never been upgraded from one version of Tiny ERP to another.
 
343
 
 
344
Use this only for demo data that will never been upgraded from one version of Tiny ERP to another.
 
345
 
 
346
.. i18n: The name of the object is the name of the file before the first '-'. You must use one file per object to import. For example, to import a file with partners (including their multiple contacts and events), the file must be named like one of the following example:
 
347
 
 
348
The name of the object is the name of the file before the first '-'. You must use one file per object to import. For example, to import a file with partners (including their multiple contacts and events), the file must be named like one of the following example:
 
349
 
 
350
.. i18n:     * res.partner.csv
 
351
.. i18n:     * res.partner-tiny_demo.csv
 
352
.. i18n:     * res.partner-tiny.demo.csv
 
353
 
 
354
    * res.partner.csv
 
355
    * res.partner-tiny_demo.csv
 
356
    * res.partner-tiny.demo.csv
 
357
 
 
358
.. i18n: Structure of the CSV file
 
359
.. i18n: +++++++++++++++++++++++++
 
360
 
 
361
Structure of the CSV file
 
362
+++++++++++++++++++++++++
 
363
 
 
364
.. i18n: Have a look at the user manual for a complete description on how to construct your .CSV file.
 
365
 
 
366
Have a look at the user manual for a complete description on how to construct your .CSV file.
 
367
 
 
368
.. i18n: Usefull info:
 
369
 
 
370
Usefull info:
 
371
 
 
372
.. i18n:     * Separator of field: ,
 
373
.. i18n:     * Quote of fields: "
 
374
.. i18n:     * Encoding to use: UTF-8
 
375
 
 
376
    * Separator of field: ,
 
377
    * Quote of fields: "
 
378
    * Encoding to use: UTF-8
 
379
 
 
380
.. i18n: Export demo data and import it from a module
 
381
.. i18n: ++++++++++++++++++++++++++++++++++++++++++++
 
382
 
 
383
Export demo data and import it from a module
 
384
++++++++++++++++++++++++++++++++++++++++++++
 
385
 
 
386
.. i18n: You can import .CSV file that have been exported from the Tiny ERP client. This is interesting to create your own demo module. But both formats are not exactly the same, mainly due to the conversion: Structured Data -> Flat Data -> Structured Data.
 
387
 
 
388
You can import .CSV file that have been exported from the Tiny ERP client. This is interesting to create your own demo module. But both formats are not exactly the same, mainly due to the conversion: Structured Data -> Flat Data -> Structured Data.
 
389
 
 
390
.. i18n:     * The name of the column (first line of the .CSV file) use the end user term in his own language when you export from the client. If you want to import from a module, you must convert the first column using the fields names. Example, from the partner form:
 
391
 
 
392
    * The name of the column (first line of the .CSV file) use the end user term in his own language when you export from the client. If you want to import from a module, you must convert the first column using the fields names. Example, from the partner form:
 
393
 
 
394
.. i18n:     Name,Code,Contacts/Contact Name,Contacts/Street,Contacts/Zip
 
395
 
 
396
    Name,Code,Contacts/Contact Name,Contacts/Street,Contacts/Zip
 
397
 
 
398
.. i18n:         becomes
 
399
 
 
400
        becomes
 
401
 
 
402
.. i18n:     name,ref,address/name,address/street,address/zip
 
403
 
 
404
    name,ref,address/name,address/street,address/zip
 
405
 
 
406
.. i18n:     * When you export from the Tiny ERP client, you can select any many2one fields and their child's relation. When you import from a module, Tiny ERP tries to recreate the relation between the two resources. For example, do not export something like this from a sale order form - otherwise Tiny ERP will not be able to import your file:
 
407
 
 
408
    * When you export from the Tiny ERP client, you can select any many2one fields and their child's relation. When you import from a module, Tiny ERP tries to recreate the relation between the two resources. For example, do not export something like this from a sale order form - otherwise Tiny ERP will not be able to import your file:
 
409
 
 
410
.. i18n:     Order Description,Partner/Name,Partner/Payable,Partner/Address/Name
 
411
 
 
412
    Order Description,Partner/Name,Partner/Payable,Partner/Address/Name
 
413
 
 
414
.. i18n:     * To find the link for a many2one or many2many field, the server use the name_search function when importing. So, for a many2one field, it is better to export the field 'name' or 'code' of the related resource only. Use the more unique one. Be sure that the field you export is searchable by the name_search function. (the 'name' column is always searchable).
 
415
 
 
416
    * To find the link for a many2one or many2many field, the server use the name_search function when importing. So, for a many2one field, it is better to export the field 'name' or 'code' of the related resource only. Use the more unique one. Be sure that the field you export is searchable by the name_search function. (the 'name' column is always searchable).
 
417
 
 
418
.. i18n:     Order Description,Partner/Code
 
419
 
 
420
    Order Description,Partner/Code
 
421
 
 
422
.. i18n:     * Change the title of the column for all many2many or many2one fields. It's because you export the related resource and you import a link on the resource. Example from a sale order: Partner/Code should become partner_id and not partner_id/code. If you kept the @@/code@@, Tiny ERP will try to create those entries in the database instead of finding reference to existing ones.
 
423
.. i18n: 
 
424
.. i18n:     * Many2many fields. If all the exported data contains 0 or 1 relation on each many2many fields, there will be no problem. Otherwise, the export will result in one line per many2many. The import function expect to get all many2many relations in one column, separated by a comma. So, you have to make to transformation. For example, if the categories "Customer" and "Supplier" already exists :
 
425
 
 
426
    * Change the title of the column for all many2many or many2one fields. It's because you export the related resource and you import a link on the resource. Example from a sale order: Partner/Code should become partner_id and not partner_id/code. If you kept the @@/code@@, Tiny ERP will try to create those entries in the database instead of finding reference to existing ones.
 
427
 
 
428
    * Many2many fields. If all the exported data contains 0 or 1 relation on each many2many fields, there will be no problem. Otherwise, the export will result in one line per many2many. The import function expect to get all many2many relations in one column, separated by a comma. So, you have to make to transformation. For example, if the categories "Customer" and "Supplier" already exists :
 
429
 
 
430
.. i18n:     name,category_id
 
431
.. i18n:     Smith, "Customer, Supplier"
 
432
 
 
433
    name,category_id
 
434
    Smith, "Customer, Supplier"
 
435
 
 
436
.. i18n: If you want to create these two categories you can try :
 
437
 
 
438
If you want to create these two categories you can try :
 
439
 
 
440
.. i18n:     name,category_id/name
 
441
.. i18n:     Smith, "Customer, Supplier"
 
442
 
 
443
    name,category_id/name
 
444
    Smith, "Customer, Supplier"
 
445
 
 
446
.. i18n: This does not work as expected: a category "Customer, Supplier" is created. The solution is to create an empty line with only the second category:
 
447
 
 
448
This does not work as expected: a category "Customer, Supplier" is created. The solution is to create an empty line with only the second category:
 
449
 
 
450
.. i18n:     name,category_id/name
 
451
.. i18n:     Smith, Customer
 
452
.. i18n:     ,Supplier
 
453
 
 
454
    name,category_id/name
 
455
    Smith, Customer
 
456
    ,Supplier
 
457
 
 
458
.. i18n: (Note the comma before "Supplier").
 
459
 
 
460
(Note the comma before "Supplier").
 
461
 
 
462
.. i18n:     * Read only fields. Do not try to import read only fields like the amount receivable or payable for a partner. Otherwise, Tiny ERP will not accept to import your file.
 
463
.. i18n: 
 
464
.. i18n:     * Exporting trees. You can export and import tree structures using the parent field. You just have to take care of the import order. The parent have to be created before his child's.
 
465
 
 
466
    * Read only fields. Do not try to import read only fields like the amount receivable or payable for a partner. Otherwise, Tiny ERP will not accept to import your file.
 
467
 
 
468
    * Exporting trees. You can export and import tree structures using the parent field. You just have to take care of the import order. The parent have to be created before his child's.
 
469
 
 
470
.. i18n: Use record id like in xml file:
 
471
.. i18n: +++++++++++++++++++++++++++++++
 
472
 
 
473
Use record id like in xml file:
 
474
+++++++++++++++++++++++++++++++
 
475
 
 
476
.. i18n: It's possible to define an id for each line of the csv file. This allow to define references between records:
 
477
 
 
478
It's possible to define an id for each line of the csv file. This allow to define references between records:
 
479
 
 
480
.. i18n:     id, name, parent_id:id
 
481
.. i18n:     record_one, Father,
 
482
.. i18n:     record_two, Child, record_one
 
483
 
 
484
    id, name, parent_id:id
 
485
    record_one, Father,
 
486
    record_two, Child, record_one
 
487
 
 
488
.. i18n: If you do this, the line with the parent data must be before the child lines in the file.
 
489
 
 
490
If you do this, the line with the parent data must be before the child lines in the file.
 
491
 
 
492
.. i18n: Multiple CSV Files
 
493
.. i18n: ------------------
 
494
 
 
495
Multiple CSV Files
 
496
------------------
 
497
 
 
498
.. i18n: Importing from multiple CSV a full group of linked data
 
499
.. i18n: +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
500
 
 
501
Importing from multiple CSV a full group of linked data
 
502
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
503
 
 
504
.. i18n: It' possible to import a lot of data, with multiple CSV files imported as a single operation. Assume we have a database with books and authors with a relation many2many between book and author.
 
505
 
 
506
It' possible to import a lot of data, with multiple CSV files imported as a single operation. Assume we have a database with books and authors with a relation many2many between book and author.
 
507
 
 
508
.. i18n: And that you already have a file with a lot of books (like a library) and an other file with a lot of authors and a third file with the links between them.
 
509
 
 
510
And that you already have a file with a lot of books (like a library) and an other file with a lot of authors and a third file with the links between them.
 
511
 
 
512
.. i18n: How to import that easily in openERP ?
 
513
 
 
514
How to import that easily in openERP ?
 
515
 
 
516
.. i18n: Definition of an import module
 
517
.. i18n: ++++++++++++++++++++++++++++++
 
518
 
 
519
Definition of an import module
 
520
++++++++++++++++++++++++++++++
 
521
 
 
522
.. i18n: You can do this in the module you have defined to manage yours books and authors. but Sometimes, the tables to import can also be in several modules.
 
523
 
 
524
You can do this in the module you have defined to manage yours books and authors. but Sometimes, the tables to import can also be in several modules.
 
525
 
 
526
.. i18n: For this example, let's say that 'book' object is defined in a module called 'library_management' and that 'Author' object in a module called 'contact_name'.
 
527
 
 
528
For this example, let's say that 'book' object is defined in a module called 'library_management' and that 'Author' object in a module called 'contact_name'.
 
529
 
 
530
.. i18n: In this case, you can create a 'fake' module, just to import the data for all these multiples modules. Call this importation module : 'import_my_books'.
 
531
 
 
532
In this case, you can create a 'fake' module, just to import the data for all these multiples modules. Call this importation module : 'import_my_books'.
 
533
 
 
534
.. i18n: You create this module as others modules of OpenObject :
 
535
 
 
536
You create this module as others modules of OpenObject :
 
537
 
 
538
.. i18n:    1. create a folder 'import_my_books'
 
539
.. i18n:    2. inside, create a '__init__.py' file with only one line : import import_my_books
 
540
.. i18n:    3. again, in the same folder, create a '__terp__.py' file and in this file, write the following code :
 
541
 
 
542
   1. create a folder 'import_my_books'
 
543
   2. inside, create a '__init__.py' file with only one line : import import_my_books
 
544
   3. again, in the same folder, create a '__terp__.py' file and in this file, write the following code :
 
545
 
 
546
.. i18n: .. code-block:: python
 
547
.. i18n: 
 
548
.. i18n:      # -*- encoding: utf-8 -*-
 
549
.. i18n:      {
 
550
.. i18n:        'name': 'My Book Import',
 
551
.. i18n:        'category': 'Data Module 1',
 
552
.. i18n:        'init_xml':[],
 
553
.. i18n:        'author': 'mySelf & I',
 
554
.. i18n:        'depends': ['base','library_management','contact_name'],
 
555
.. i18n:        'version': '1.0',
 
556
.. i18n:        'active': False,
 
557
.. i18n:        'demo_xml': [],
 
558
.. i18n:        'update_xml':['contact_name.author.csv','library.book.csv'],
 
559
.. i18n:        'installable': True
 
560
.. i18n:      }
 
561
 
 
562
.. code-block:: python
 
563
 
 
564
     # -*- encoding: utf-8 -*-
 
565
     {
 
566
       'name': 'My Book Import',
 
567
       'category': 'Data Module 1',
 
568
       'init_xml':[],
 
569
       'author': 'mySelf & I',
 
570
       'depends': ['base','library_management','contact_name'],
 
571
       'version': '1.0',
 
572
       'active': False,
 
573
       'demo_xml': [],
 
574
       'update_xml':['contact_name.author.csv','library.book.csv'],
 
575
       'installable': True
 
576
     }
 
577
 
 
578
.. i18n: Creation of CSV files
 
579
.. i18n: +++++++++++++++++++++
 
580
 
 
581
Creation of CSV files
 
582
+++++++++++++++++++++
 
583
 
 
584
.. i18n: For the CSV files, you'll import one the after, the other one.
 
585
 
 
586
For the CSV files, you'll import one the after, the other one.
 
587
 
 
588
.. i18n: So you have to choose, in which way you'll treat the many2many relation. For our example, we've choose to import all the authors, then all the books with the links to the authors.
 
589
 
 
590
So you have to choose, in which way you'll treat the many2many relation. For our example, we've choose to import all the authors, then all the books with the links to the authors.
 
591
 
 
592
.. i18n:    1. authors CSV file
 
593
 
 
594
   1. authors CSV file
 
595
 
 
596
.. i18n: You have to put your data in a CSV file without any link to books (because the book ids will be known only AFTERWARDS...) For example : ("contact_name.author.csv")
 
597
 
 
598
You have to put your data in a CSV file without any link to books (because the book ids will be known only AFTERWARDS...) For example : ("contact_name.author.csv")
 
599
 
 
600
.. i18n: ::
 
601
.. i18n: 
 
602
.. i18n:      id,last_name,first_name,type
 
603
.. i18n:      author_1,Bradley,Marion Zimmer,Book writer
 
604
.. i18n:      author_2,"Szu T'su",,Chinese philosopher
 
605
.. i18n:      author_3,Zelazny,Roger,Book writer
 
606
.. i18n:      author_4,Arleston,Scotch,Screen Writer
 
607
.. i18n:      author_5,Magnin,Florence,Comics Drawer
 
608
.. i18n:      ...
 
609
 
 
610
::
 
611
 
 
612
     id,last_name,first_name,type
 
613
     author_1,Bradley,Marion Zimmer,Book writer
 
614
     author_2,"Szu T'su",,Chinese philosopher
 
615
     author_3,Zelazny,Roger,Book writer
 
616
     author_4,Arleston,Scotch,Screen Writer
 
617
     author_5,Magnin,Florence,Comics Drawer
 
618
     ...
 
619
 
 
620
.. i18n:    1. Books CSV file
 
621
 
 
622
   1. Books CSV file
 
623
 
 
624
.. i18n: Here, you can put the data about your books, but also, the links to the authors, using the same id as the column 'id' of the author CSV file. For example : ("library.book.csv" )
 
625
 
 
626
Here, you can put the data about your books, but also, the links to the authors, using the same id as the column 'id' of the author CSV file. For example : ("library.book.csv" )
 
627
 
 
628
.. i18n: ::
 
629
.. i18n: 
 
630
.. i18n:      id,title,isbn,pages,date,author_ids:id
 
631
.. i18n:      book_a,Les Cours du Chaos,1234567890123,268,1975-12-25,"author_3"
 
632
.. i18n:      book_b,"L'art de la Guerre, en 219 volumes",1234567890124,1978-01-01,"author_2"
 
633
.. i18n:      book_c,"new marvellous comics",1587459248579,2009-01-01,"author_5,author_4"
 
634
.. i18n:      ...
 
635
 
 
636
::
 
637
 
 
638
     id,title,isbn,pages,date,author_ids:id
 
639
     book_a,Les Cours du Chaos,1234567890123,268,1975-12-25,"author_3"
 
640
     book_b,"L'art de la Guerre, en 219 volumes",1234567890124,1978-01-01,"author_2"
 
641
     book_c,"new marvellous comics",1587459248579,2009-01-01,"author_5,author_4"
 
642
     ...
 
643
 
 
644
.. i18n: Five remarks :
 
645
 
 
646
Five remarks :
 
647
 
 
648
.. i18n:    1. the field content must be enclosed in double quotes (") if there is a double quote or a comma in the field.
 
649
.. i18n:    2. the dates are in the format YYYY-MM-DD
 
650
.. i18n:    3. if you have many ids in the same column, you must separate them with a comma, and, by the way, you must enclosed the content of the column between double quotes...
 
651
.. i18n:    4. the name of the field is the same as the name of the field in the class definition AND must be followed by ':id' if the content is an ID that must be interpreted by the import module. In fact, "author_4" will be transformed by the import module in an integer id for the database module and this numercial id will be put also in the table between author and book, not the literal ID (author_4).
 
652
.. i18n:    5. the encoding to be used by the CSV file is the 'UTF-8' encoding
 
653
 
 
654
   1. the field content must be enclosed in double quotes (") if there is a double quote or a comma in the field.
 
655
   2. the dates are in the format YYYY-MM-DD
 
656
   3. if you have many ids in the same column, you must separate them with a comma, and, by the way, you must enclosed the content of the column between double quotes...
 
657
   4. the name of the field is the same as the name of the field in the class definition AND must be followed by ':id' if the content is an ID that must be interpreted by the import module. In fact, "author_4" will be transformed by the import module in an integer id for the database module and this numercial id will be put also in the table between author and book, not the literal ID (author_4).
 
658
   5. the encoding to be used by the CSV file is the 'UTF-8' encoding
 
659
 
 
660
.. i18n: Links between id if the CSV files
 
661
.. i18n: +++++++++++++++++++++++++++++++++
 
662
 
 
663
Links between id if the CSV files
 
664
+++++++++++++++++++++++++++++++++
 
665
 
 
666
.. i18n: Links to id already in the system
 
667
.. i18n: +++++++++++++++++++++++++++++++++
 
668
 
 
669
Links to id already in the system
 
670
+++++++++++++++++++++++++++++++++
 
671
 
 
672
.. i18n: XML data files convention
 
673
.. i18n: -------------------------
 
674
 
 
675
XML data files convention
 
676
-------------------------
 
677
 
 
678
.. i18n: Developers:Developper's Book/Data Loading/XMLFilesConventions
 
679
 
 
680
Developers:Developper's Book/Data Loading/XMLFilesConventions
 
681
 
 
682
.. i18n: Jump to: navigation, search
 
683
 
 
684
Jump to: navigation, search
 
685
 
 
686
.. i18n: The ressources are placed in different files according to their uses. By convention;
 
687
 
 
688
The ressources are placed in different files according to their uses. By convention;
 
689
 
 
690
.. i18n:  .. csv-table::
 
691
.. i18n:    :header: "Name","Description"
 
692
.. i18n:    :widths: 25, 25
 
693
.. i18n: 
 
694
.. i18n:    "modulename_workflow.xml","the definitions of workflows"
 
695
.. i18n:    "modulename_view.xml","the views"
 
696
.. i18n:    "modulename_data.xml","the important datas to download"
 
697
.. i18n:    "modulename_report.xml","the reports declarations"
 
698
.. i18n:    "modulename_demo.xml","the useful datas for the demo version"
 
699
 
 
700
 .. csv-table::
 
701
   :header: "Name","Description"
 
702
   :widths: 25, 25
 
703
 
 
704
   "modulename_workflow.xml","the definitions of workflows"
 
705
   "modulename_view.xml","the views"
 
706
   "modulename_data.xml","the important datas to download"
 
707
   "modulename_report.xml","the reports declarations"
 
708
   "modulename_demo.xml","the useful datas for the demo version"
 
709
 
 
710
.. i18n: The workflow files have to be loaded before the datas ! Otherwise, the ressource created won't be integrated inside the workflow because the later is not yet defined.
 
711
 
 
712
The workflow files have to be loaded before the datas ! Otherwise, the ressource created won't be integrated inside the workflow because the later is not yet defined.
 
713
 
 
714
.. i18n: Managing updates
 
715
.. i18n: ----------------
 
716
 
 
717
Managing updates
 
718
----------------
 
719
 
 
720
.. i18n: Managing updates and migrations
 
721
.. i18n: +++++++++++++++++++++++++++++++
 
722
 
 
723
Managing updates and migrations
 
724
+++++++++++++++++++++++++++++++
 
725
 
 
726
.. i18n: Open ERP has a built'in migration and upgrade system which allows updates to be nearly (or often) automatic. This system also allows to easily incorporate custom modules.
 
727
 
 
728
Open ERP has a built'in migration and upgrade system which allows updates to be nearly (or often) automatic. This system also allows to easily incorporate custom modules.
 
729
 
 
730
.. i18n: Table/Object structure
 
731
.. i18n: """"""""""""""""""""""
 
732
 
 
733
Table/Object structure
 
734
""""""""""""""""""""""
 
735
 
 
736
.. i18n: When you run openerp-server with option --init or --update, the table structure are updated to match the new description that is in .py files. Fields that are removed are not removed in the postgresql database not to lose data.
 
737
 
 
738
When you run openerp-server with option --init or --update, the table structure are updated to match the new description that is in .py files. Fields that are removed are not removed in the postgresql database not to lose data.
 
739
 
 
740
.. i18n: So, simply running --update or --init, will upgrade your table structure.
 
741
 
 
742
So, simply running --update or --init, will upgrade your table structure.
 
743
 
 
744
.. i18n: It's important to run --init=module the first time you install the module. Next time, you must use the --update=module argument instead of the init one. This is because init loads ressources that are loaded only once and never upgraded (eg: ressources with no id="" attribute or within a noupdate="1" <data> tag).
 
745
 
 
746
It's important to run --init=module the first time you install the module. Next time, you must use the --update=module argument instead of the init one. This is because init loads ressources that are loaded only once and never upgraded (eg: ressources with no id="" attribute or within a noupdate="1" <data> tag).
 
747
 
 
748
.. i18n: Data
 
749
.. i18n: """"
 
750
.. i18n: Some data is automatically loaded at the installation of Tiny ERP:
 
751
 
 
752
Data
 
753
""""
 
754
Some data is automatically loaded at the installation of Tiny ERP:
 
755
 
 
756
.. i18n:     * views, actions, menus,
 
757
.. i18n:     * workflows,
 
758
.. i18n:     * demo data
 
759
 
 
760
    * views, actions, menus,
 
761
    * workflows,
 
762
    * demo data
 
763
 
 
764
.. i18n: This data is also migrated to a new version if you run --update or --init.
 
765
 
 
766
This data is also migrated to a new version if you run --update or --init.
 
767
 
 
768
.. i18n: Workflows
 
769
.. i18n: """""""""
 
770
 
 
771
Workflows
 
772
"""""""""
 
773
 
 
774
.. i18n: Workflows are also upgraded automatically. If some activities are removed, the documents states evolves automatically to the preceding activities. That ensure that all documents are always in valid states.
 
775
 
 
776
Workflows are also upgraded automatically. If some activities are removed, the documents states evolves automatically to the preceding activities. That ensure that all documents are always in valid states.
 
777
 
 
778
.. i18n: You can freely remove activities in your XML files. If workitems are in this activity, they will evolve to the preceding unlinked activity. And after the activity will be removed.
 
779
 
 
780
You can freely remove activities in your XML files. If workitems are in this activity, they will evolve to the preceding unlinked activity. And after the activity will be removed.
 
781
 
 
782
.. i18n: Things to care about during development
 
783
.. i18n: """""""""""""""""""""""""""""""""""""""
 
784
 
 
785
Things to care about during development
 
786
"""""""""""""""""""""""""""""""""""""""
 
787
 
 
788
.. i18n: Since version 3.0.2 of Tiny ERP, you can not use twice the same 'id="..."' during resource creation in your XML files, unless they are in two different modules.
 
789
 
 
790
Since version 3.0.2 of Tiny ERP, you can not use twice the same 'id="..."' during resource creation in your XML files, unless they are in two different modules.
 
791
 
 
792
.. i18n: Resources which don't contain an id are created (and updated) only once; at the installation of the module or when you use the --init argument.
 
793
 
 
794
Resources which don't contain an id are created (and updated) only once; at the installation of the module or when you use the --init argument.
 
795
 
 
796
.. i18n: If a resource has an id and this resource is not present anymore in the next version of the XML file, Open ERP will automatically remove it from the database. If this resource is still present, Open ERP will update the modifications to this resource.
 
797
 
 
798
If a resource has an id and this resource is not present anymore in the next version of the XML file, Open ERP will automatically remove it from the database. If this resource is still present, Open ERP will update the modifications to this resource.
 
799
 
 
800
.. i18n: If you use a new id, the resource will be automatically created at the next update of this module.
 
801
 
 
802
If you use a new id, the resource will be automatically created at the next update of this module.
 
803
 
 
804
.. i18n: **Use explicit id declaration !**, Example:
 
805
 
 
806
**Use explicit id declaration !**, Example:
 
807
 
 
808
.. i18n:     * view_invoice_form,
 
809
.. i18n:     * view_move_line_tree,
 
810
.. i18n:     * action_invoice_form_open, ...
 
811
 
 
812
    * view_invoice_form,
 
813
    * view_move_line_tree,
 
814
    * action_invoice_form_open, ...
 
815
 
 
816
.. i18n: It is important to put id="...." to all record that are important for the next version migrations. For example, do not forget to put some id="..." on all workflows transitions. This will allows Open ERP to know which transition has been removed and which transition is new or updated.
 
817
 
 
818
It is important to put id="...." to all record that are important for the next version migrations. For example, do not forget to put some id="..." on all workflows transitions. This will allows Open ERP to know which transition has been removed and which transition is new or updated.
 
819
 
 
820
.. i18n: Custom modules
 
821
.. i18n: """"""""""""""
 
822
 
 
823
Custom modules
 
824
""""""""""""""
 
825
 
 
826
.. i18n: For example, if you want to override the view of an object named 'invoice_form' in your xml file (id="invoice_form"). All you have to do is redefine this view in your custom module with the same id. You can prefix ids with the name of the module to reference an id defined in another module.
 
827
 
 
828
For example, if you want to override the view of an object named 'invoice_form' in your xml file (id="invoice_form"). All you have to do is redefine this view in your custom module with the same id. You can prefix ids with the name of the module to reference an id defined in another module.
 
829
 
 
830
.. i18n: Example:
 
831
 
 
832
Example:
 
833
 
 
834
.. i18n:     <record model="ir.ui.view" id="account.invoice_form">
 
835
.. i18n:     ...
 
836
.. i18n:     <record>
 
837
 
 
838
    <record model="ir.ui.view" id="account.invoice_form">
 
839
    ...
 
840
    <record>
 
841
 
 
842
.. i18n: This will override the invoice form view. You do not have to delete the old view, like in 3.0 versions of Open ERP.
 
843
 
 
844
This will override the invoice form view. You do not have to delete the old view, like in 3.0 versions of Open ERP.
 
845
 
 
846
.. i18n: Note that it is often better to use view inherytancy instead of overwritting views.
 
847
 
 
848
Note that it is often better to use view inherytancy instead of overwritting views.
 
849
 
 
850
.. i18n: In this migration system, you do not have to delete any ressource. The migration system will detect if it is an update or a delete using id="..." attributes. This is important to preserve references duing migrations.
 
851
 
 
852
In this migration system, you do not have to delete any ressource. The migration system will detect if it is an update or a delete using id="..." attributes. This is important to preserve references duing migrations.
 
853
 
 
854
.. i18n: Demo datas
 
855
.. i18n: """"""""""
 
856
 
 
857
Demo datas
 
858
""""""""""
 
859
 
 
860
.. i18n: Demo datas do not have to be upgraded; because they are probably modified, deleted, ... by users. So, to avoid demo data to be upgraded, you can put a noupdate="1" attribute in the <data> tag of your .xml data files.
 
861
 
 
862
Demo datas do not have to be upgraded; because they are probably modified, deleted, ... by users. So, to avoid demo data to be upgraded, you can put a noupdate="1" attribute in the <data> tag of your .xml data files.
 
863
 
 
864
.. i18n: Summary of update and init process
 
865
.. i18n: ++++++++++++++++++++++++++++++++++
 
866
 
 
867
Summary of update and init process
 
868
++++++++++++++++++++++++++++++++++
 
869
 
 
870
.. i18n: init:
 
871
 
 
872
init:
 
873
 
 
874
.. i18n:     modify/add/delete demo data and builtin data
 
875
 
 
876
    modify/add/delete demo data and builtin data
 
877
 
 
878
.. i18n: update:
 
879
 
 
880
update:
 
881
 
 
882
.. i18n:     modifiy/add/delete non demo data
 
883
 
 
884
    modifiy/add/delete non demo data
 
885
 
 
886
.. i18n: Examples of builtin (non demo) data:
 
887
 
 
888
Examples of builtin (non demo) data:
 
889
 
 
890
.. i18n:     * Menu structure,
 
891
.. i18n:     * View definition,
 
892
.. i18n:     * Workflow description, ...
 
893
.. i18n:       -> Everything that as an id="..." in the .XML data declaration (if no attr noupdate="1" in the header)
 
894
 
 
895
    * Menu structure,
 
896
    * View definition,
 
897
    * Workflow description, ...
 
898
      -> Everything that as an id="..." in the .XML data declaration (if no attr noupdate="1" in the header)
 
899
 
 
900
.. i18n: What's going on on a update process:
 
901
 
 
902
What's going on on a update process:
 
903
 
 
904
.. i18n:    1. If you manually added data within the client:
 
905
.. i18n:           * the update process will not change them
 
906
.. i18n:    2. If you dropped data:
 
907
.. i18n:           * if it was demo data, the update process will do nothing
 
908
.. i18n:           * it it was builtin data (like a view), the update process will recreate it
 
909
.. i18n:    3. If you modified data (either in the .XML or the client):
 
910
.. i18n:           * if it's demo data: nothing
 
911
.. i18n:           * if it's builtin data, data are updated
 
912
.. i18n:    4. If builtin data have been deleted in the .XML file:
 
913
.. i18n:           * this data will be deleted in the database.
 
914
 
 
915
   1. If you manually added data within the client:
 
916
          * the update process will not change them
 
917
   2. If you dropped data:
 
918
          * if it was demo data, the update process will do nothing
 
919
          * it it was builtin data (like a view), the update process will recreate it
 
920
   3. If you modified data (either in the .XML or the client):
 
921
          * if it's demo data: nothing
 
922
          * if it's builtin data, data are updated
 
923
   4. If builtin data have been deleted in the .XML file:
 
924
          * this data will be deleted in the database.