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 <[email protected]> > 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) <[email protected]> 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. >> >> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
