← Back to team overview

openerp-expert-framework team mailing list archive

Re: [Bug 693308] Re: Import / Export to review in Trunk

 

on a side note, just giving an example of serious "multi-referential".
Simples cases are: you have your partners in OpenERP but also in an
accounting system and in some ecommerce: already 3 referentials.
We now have a US/Brazil customer planning to connect 25 different Magento
installations on the same OpenERP v6, that's really multi-referentials, and
it's important to support it...

2010/12/29 Raphaël Valyi <rvalyi@xxxxxxxxx>

> Fabien,
>
> for the import I believe it's ok you can specify the referential indeed.
>
> Now, I believe for the export you can still no choose a specific
> referential/module, indeed, here is how the get_xml_id method is implemented
> in server/bin/orm.py:
>
>     def get_xml_id(self, cr, uid, ids, *args, **kwargs):
>         """Find out the XML ID of any database record, if there
>         is one. This method works as a possible implementation
>         for a function field, to be able to add it to any
>         model object easily, referencing it as ``osv.osv.get_xml_id``.
>
>         **Synopsis**: ``get_xml_id(cr, uid, ids) -> { 'id': 'module.xml_id'
> }``
>
>         :return: the fully qualified XML ID of the given object,
>                  defaulting to an empty string when there's none
>                  (to be usable as a function field).
>         """
>         result = dict.fromkeys(ids, '')
>         model_data_obj = self.pool.get('ir.model.data')
>         data_ids = model_data_obj.search(cr, uid,
>                 [('model', '=', self._name), ('res_id', 'in', ids)])
>         data_results = model_data_obj.read(cr, uid, data_ids,
>                 ['name', 'module', 'res_id'])
>         for record in data_results:
>             result[record['res_id']] = '%(module)s.%(name)s' % record
>         return result
>
>
>
> I think, that in the case your record has several ids in different
> referentials (a common case), then you have several data_results for the
> same result[record['res_id']], no?
> But in that case, only the last record in data_results will be returned or
> I missed something?
>
> IMHO, even if it's not implemented in the clients, in order to maximize the
> future server API stability, I think it would be nice this get_xml_id method
> accepts a 'module' argument in its context.
> If present, the given module will restrict the search in  data_ids =
> model_data_obj.search(cr, uid, [('model', '=', self._name), ('res_id', 'in',
> ids)])
>
> Then it will only be about adding the feature in the clients, migration
> will be smooth. I believe this has added value.
> On a side note: I personally don't really like calling this id "xml_id", I
> mean XML is just a format you used to feed those ids, could also have been
> YAML, webservices, whatever.
> Not sure what would be more appropriate, may be something like
> module_ref_id ? Not sure. In any case naming is very important for the
> success of a framework/API.
>
> Did I miss something?
> BTW, thanks for the video, will definitely help lots of folks getting
> started to OpenERP import/export.
>
>
> On Wed, Dec 29, 2010 at 3:29 PM, Fabien (Open ERP) <fp@xxxxxxxxxxx> wrote:
>
>> @Raphaël Valyi
>> The import / export we made support external referancials (through xml id,
>> accepting a module name)
>>
>> Note that this bug report is just for the UI of the import / export that
>> has already been implemented in trunk GTK:
>> http://www.youtube.com/watch?v=e1LbaiSa1aM
>>
>> --
>> You received this bug notification because you are a member of OpenERP
>> Framework Experts, which is subscribed to OpenObject Web Client.
>> https://bugs.launchpad.net/bugs/693308
>>
>> Title:
>>  Import / Export to review in Trunk
>>
>> Status in OpenObject Web Client:
>>   In Progress
>>
>> Bug description:
>>  Hello,
>>
>> The import/export tool must be reviewed completly in trunk in order to be
>> easier to use. The main change is the "import compatible" option that allows
>> to export any kind of data (including one2many, many2one, etc) and reimport
>> the file after to update or create new data. The v5 behaviour was unuseable
>> at all.
>>
>> I already commited the changes in the server and GTK client to support
>> this. Only the web client is remaining.
>>
>> Have a look at the attached PDF file for the useability of the two screens
>> to review.
>>
>> Import Tool
>> -----------
>>
>> The import tool must be simplified. We don't need to select the fields
>> anymore, it will automatically take the columns defined by the first row of
>> the .CSV file.
>>
>> When you select a file, the web client should make a preview of the first
>> three rows. You can change the CSV options "field separator, field
>> delimitor, encoding". Just display the columns as it, without any
>> interpretation. (if they are ID or XML ID, just display the IDs).
>>
>> Export Tool
>> -----------
>>
>> There is a real difference between the normal mode and the "Import
>> Compatible" mode.
>>
>> If you set the import compatible mode:
>> 1. For every field:
>>   - many2one: just display two children: id and .id
>>   - many2many: just display this field without children
>>   - one2many: normal behaviour
>> 2. When you export, put the name of the fields in the first columns, and
>> not their label. (example: partner_id/id)
>>
>> If you don't set the import compatible mode. For every:
>> 1. For every field:
>>   - many2one: you can see all children
>>   - many2many: you can see all children
>>   - one2many: you can see all children
>> 2. When you export, put the label of the fields in the first columns, and
>> not their name. (example: Partner/ID)
>>
>> I changed the format of the csv file. Instead of "db_id", I used ".id". An
>> example of "import compatible" file exported from partners:
>>
>>   id,.id,name,address.id,address/id,address/name
>>
>>   base.res_partner_agrolait,3,Agrolait,11,base.res_partner_address_8delivery,Paul
>>
>> This has to be done in trunk, before v6.0. I think it's critical for
>> OpenERP Online users.
>>
>> Test with the GTK client to be sure the behaviour is the same in the web
>> and GTK client.
>>
>>
>>
>>
>

References