I can import Comma Separated Values (CSV) data through the admin pages, into most models. This process handles the external IDs so that the data can be added to or amended as appropriate in later CSV imports. This is a manial action.
Through the API, the same records can be created and amended, and external IDs can be set. This, however, requires a lot of the logic that would otherwise be handled by the CSV importer to be coded by hand, in the external application that uses the API to push in data. Pushing data through the API can be automated.
Is there a way the API can be used (so no changes need to be made to code within Odoo) to push CSV data (so the logic for insert/update/relationships/external IDs/ etc. is handled by Odoo)? This would be a kind of hybrid approach, and I am trying to avoid the need to create import modules within Odoo.
Edit: the "external ID" is often called the "XML ID". I think it is a terminology that has stuck from earlier versions of OpenERP, rather than having anything specific to do with XML.
Edit
This page describes a load() function that pushes CSV-like data through a pipeline to load it into the system:
http://openerp-server.readthedocs.org/en/latest/06_misc_import.html
I can't see how to translate the summary on that page into an operation through the API, if indeed that is possible. I'm guessing I will need the interface (entry point), model, method (load(), probably), and some additional parameters, but the details are beyond me.
The answer is kind of "yes".
The load() method can be used against any model to load data. This method takes data in the same structure as a CSV file would provide.
The first parameter is an array of field names, like the column headings on a CSV import.
The second parameter is an array of records. Each record is an array of values matching each field.
The API will return a list of errors where they are catered for by OpenERP. Many errors, however, just result in database exceptions on OpenERP and so need to be picked up as an API failure. This is largely because the OpenERP API is not designed as a generic API, but as a part of the GUI, and so the data sent to the API is very much bound to the current state of the application through that GUI. In other words, invalid data will seldom find its way to the API using the OpenERP GUI.
I have wrapped the loader functionality, catching errors and exceptions, in my PHP OpenERP API library here:
https://github.com/academe/openerpapi/blob/master/src/App/Loader.php
Hopefully that will be useful to others too.
I think the answer is "no".
However, this technique has been explained to me:
Create a module with little in it but CSV files for importing.
Install the module.
When a new CSV file needs to be imported, transfer it into the module (FTP or similar).
Once transferred, run the update() method for the module. This can be done through the API.
The update method will scan and load all the CSV files set up within the module. Care needs to be taken to make sure only one upload/update transaction will be run at any time.
I'll post additional details here when I have got this working, or will happily accept an alternate answer if there is a better way to handle this.
Related
My company is using a CKAN instance configured with Data Store and DataPusher. When a CSV file is uploaded to CKAN, DataPusher sends it to the DataStore and creates a default Data Dictionary for the resource. The Data Dictionary is a very nice feature to display the description of data fields for the users. Here is an example (it is in Brazilian Portuguese):
I can update the Data Dictionary using the UI, or it can be sent as part of the Fields passed to datastore_create().
My problem, is that I don't control the call of datastore_create() because this method is automatically called buy the DataPusher service.
I want to programmatically set the values of the Data Dictionary, but I can't find the api call that allows me to do it. An api call that update the Fields metadata. Can I do it using the Api? Or maybe it is possible create it when I create the data resource. I'd like a code example.
You can use the API call datastore_create on top of an existing table. This will not impact the data in the table.
You should use the datastore_search to check the format of how the dictionary is saved in one of your resources (result->fields->info). Use that as your base, make the desired changes, and use it in the body of the datastore_create call.
Unfortunately, the API call datastore_info does not give you back that information.
The majority of the CKAN UI functionalities can be made through the API as well. In this case, you can make use of the "datastore_create" by the controller --> See Code here.
How to refresh the interface after you add a strip of data to the backend database in Vue.js?
I mean, if I add a item data to the database. there are two case for refresh the interface.
refresh the list api to get the page data.
append the added item data to local list.
what is the best way to do this?
I think both the solutions are valid it depends on what kind of write operation we are planning to do. Given that you do all the validations on the front-end which leaves lesser chance for errors on the backend. I do the following based on the use case.
Add/Update the item locally and then based on the response from the server I remove it again in case of an error. This is an optimistic technique used by a lot of websites and worls really well for CRUD kind of operations.
Let's say that your new operating is going to creaate a new user in a 3rd party api. So doing an optimistic thing might not be the best. So what I do is make the request, show a toast/alert that the request is happening, and then use sockets or long polling to get the changes. When the request is finally done show the data. In the meanwhile you can insert a dummy item showing loading.
I'm working with Sitefinity CMS and trying to figure out how to save the data from a "Forms Module" form to a separate database in the backend. Currently all the responses are saved into a table that is created when the form is built. What I want to do is re-route the save request to go through my code behind instead and save the data to Azure table storage. Is there a way to do this or by using the Forms Module am I stuck to saving the data to the table that is auto-created when the form is built? I've tried creating my own FormsSubmitRouteHandler as explained here (http://docs.sitefinity.com/for-developers-submit-forms-using-ajax-call#register-a-form-submit-route-handler) but I must be doing something wrong cause my code doesn't ever get hit.
Any help would be greatly appreciated. If I didn't explain myself well please let me know.
You should create a new provider that implements the FormsDataProvider class.
Currently Sitefinity uses OpenAccessFormsProvider - so you can use JustDecompile to see how that was implemented and probably do something similar.
Then you need to register your custom provider in the Administration > Settings > Advanced > Forms
If you don't mind having the form responses in the Sitefinity database and in your custom storage, then you can subscribe to the IFormEntryCreatedEvent and in your event handler you can write the logic of saving the form respose somewhere else.
See this article for more details: http://docs.sitefinity.com/for-developers-forms-events#iformentrycreatedevent
Have in mind that this will result in form responses being saved in both, the SF datbase and your custom storage. Also, you won't be able to manage the entries stored in the custyom storage through Sitefinity backend. If that's your goal, then Vesselin's answer is the correct way to go, but more complicated.
I have the need to add a licence field to the APIs published by the API manager.
It does not seems to be any extension point beyond the api.rxt file in the resource folder.
If I modify the file and run the application the carbon app correctly show the added field, but nor the publishe nor the store are able to get the field and there is no way to get it also with REST APIs since it calls a method of a class that (in later versions) outputted fields positionally.
Is it possible to add the field, without running the risk of crashing the API Manager?
Which is the correct way?
Thanks
This change cannot be done without modifying the code. When an API is created from the Publisher app, it gets stored in the registry. The api.txt you modified, only defines the structure of this stored artifact. It may add a new field to the artifact, but to correctly populate that field, you need to modify several methods in APIProviderHostObject and APIProviderImpl + several Jaggery scripts.
I'm implementing a RESTful API for what is essentially a document store, but am hitting a brick wall because I need a hybrid approach to one of the operations that can be performed on these documents.
Essentially, a user should be able to generate PDF versions of documents that are stored as JSON but also generate PDF versions of JSON strings that are passed arbitrarily (with no record in the database). The PDF reports never need to be stored anywhere, they are always generated on the fly.
My current API looks like:
/Documents
/Documents/1234
/Documents/1234?rev=4
Now, one way to implement the PDF generation would be to do:
/Documents/1234/Reports
or
/Reports/1234
But since we don't need to store PDFs (generated on the fly), both are reduced to only a GET operation, and it doesn't really act on a 'Report' object - which doesn't seem RESTful to me.
What complicates it further is that a user should be able to manually pass a JSON blob to the service and get a PDF. So something like:
/API/GeneratePDF
So does a separate stateless API make sense for this one operation? Maybe then redirect a request like /Reports/1234 to /API/GeneratePDF with the JSON blob for the 1234 document. It all seems a bit messy :)
The URL '/reports/123/' is pointing to a 'report' resource and it should not matter what backend operations will be acted on it.
When thinking about resource-url and its associated operations, the only relevant operations are "GET/PUT/POST/DELETE"
Then map the business operations (like generate PFD report) to the url+HTTP-Op+params.
Like in this case, map 'generate PDF report" to "GET /reports/123/"
use-case-1: simple get report
GET /reports/123/
return: {pdf-report}
use-case-2: customized report
GET /reports/123/
param: {"json info passed along with the get operation"
return: {pdf-report}
The the backend can detect if there are input from the client to decide what specific backend operations should be taken to generate the report.
Hope this help!