I would like to fetch records over the API using the external ID of those records. Is there a simple way to do this that I am overlooking, because my current approach seems very convoluted.
Given complete names 'l10n_uk.state_uk_99' and 'l10n_uk.state_uk_98', I would like to fetch the two states they represent.
First I need to split the complete names into modules and names. This gives me module "l10n_uk" and names "state_uk_99" and "state_uk_98". If there are several modules involved, then that is another pain point to work around, but let's assume there is just one.
Now I need to search ir.modules.data for these external IDs using this criteria:
array(
array("model", "=", "res.country.state"),
array("module", "=", "l10n_uk"),
array("name", "in", array("state_uk_99", "state_uk_98")),
)
This returns me the two IR model IDs. Then I need to fetch those IR model records - I just want the res_id field:
$my_api->read('ir.modules.data', array(5310, 5311), array('res_id'));
That gives me an array of two arrays. I need to loop through them to find and collect the res_id IDs.
Now I have those IDs, I can fetch the underlying records:
$my_api->read('res.country.states', $res_ids);
That gives me the underlying two states behind those original external IDs. BUT those records don't contain the external IDs, so I must make sure I keep the external_id:res_id lookup or distribute the external IDs over the state records I have retrieved.
What a faff! Are there any short cuts? Can I search states directly and somehow include the ir.module.data in the search criteria? When reading the states, can I include the external IDs in the retrived columns?
I realise the relationship between the states and the external IDs will be 1:1 only in context (e.g. for my locale) and may not be 1:1 at the database level, so this probably can't be done any other way. But I do need to ask...
Thanks :-)
I think your approach can benefit from a rethink if your goal is an approach that works widely and not just on a specific database. The purpose of an External ID is to allow integration with external business systems. They are not created when records are entered via the UI, only when imported via CSV or via XML. All of our customers use a global modules for Country and State/Province, so your approach would fail on all of their systems, would fail on systems that use a module other than the 'l10n_uk' module, would fail on systems that renamed that module, and would also fail if people entered in their own 'states'. Perhaps backup and outline the business problem you are trying to solve?
The business process is simple: there are country states in the ERP, imported from various sources. Each state has an external ID. They have been imported from various sources, and have different IDs in different formats. The external ID is a string. We make no assumptions as to what that string is - it is just a series of characters. We are maintaining the states on another system. On that system, against each state, we are storing the external ID of the matching state on the ERP. States that are added to that external system are given a external ID, then exported to the ERP via a CSV file, where they are imported automatically. This keeps them all in sync, which is in one direction - TO the ERP. And that's it. We have data on another system - the main system - and we push updates to OpenERP. We also have legacy external IDs to deal with, which have been generated by whatever import processes have been used in the past. So my question above is: how do I get at this data through the API? Of course, how this data works is a big game of guesswork without a decent set of documentation, which seems to have been the missing element on this project for a long time. I can only assume that what is there is in the ERP system now, is what is supposed to be there.
Also we must not forget that the simple action of *exporting* records will create system-generated external IDs for those records that don't have any. My external system cannot __export__.control that, but it still needs to be able to scan and reference and potentially update those records. External IDs can easily become a mish-mash of different formats from different sources, unfortunately.
@Bole that's useful for fetching a single model name and database ID for a record, based on its complete external ID. It can be done in one API call rather than several, as I described above, which can help performance when only one conversion is needed.