In my extension I would like to modify input data if the data records are saved in the backend module.
E.g. geo coordinates are to be generated from the address data.
I thought I could do this in the setter method of the address field in the domain model, but the setter is not called at all on saving.
Otherwise, creating and editing the data in the backend module works perfectly.
Can someone help me please?
Related
I am trying to modify the table of a module via webService.
I have created the class in the module to access the table, I can access the data without problem. The php code of the module;
mySql table:
WebService response:
I think the problem may come with the labels
<megaproductcarts>
<megaproductcart>
</megaproductcart>
</megaproductcarts>
I have tried to pass the data without the parent tag and now the answer appears to be correct, but I don't see the modification in the database.
I would be very grateful for any help
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.
Firstly, I love the Directus CMS and I chose to implement it on my new project. So far I am just loving it.
Now I have this issue where the user create functionality was added, with email verification etc all was good. Until I added a new o2m field in the directus_fields & proper relations were made. Works well in the admin panel, but while I want any user to signup from frontend the api now throws error code 3, 401 Unauthorized request. I tried all the permissions, for the junction collection, the field one collection and also the directus_users collection.
PS: It works back normal when I tried deleting the field from the directus_fields table. Thats why I am actually guessing that the issue is from the relations related permissions. And the relation works well and fine from the admin panel.
So again my question is, if an o2m 'many-to-many' field is added to 'directus_users' collection what are the permissions, alterations required for public user/create functionality. The field is not marked as required.
I am using version 8.8.1
For now, I made a temporary solution.
Removed the o2m field from the directus_users table, instead created a new collection containing the additional users_data and created the many-to-many field in it so the registration is secure and also doesn't require to tamper the directus_users table. All I had to do in addition was to modify the extra request parameters from the frontend.
Although, I still believe my question is a valid one.
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.
An example problem:
On Stack Overflow, a question page shows a number of different answers. In displaying these answers, the site also gives information about the author of the answer. This means that although the number of badges a given user has has nothing to do with an answer in and of itself, that data still needs to be retrieved in order to display the page.
From what I can see, there are three different ways to go about pulling this view data in a model:
A Post object could include a full User object as a member. The view would then access the user like this: $post->user->getReputation(). This seems cleaner, since a Controller could just request the posts and be done with it, but yet inefficient since a Post probably doesn't always need a full-blown User. I suppose it works well enough if the User object is relatively light, which it probably would be. The problem would then be that you would need to duplicate User retrieval code as part of the Post retrieval query.
The Post object could hold just an ID for a User. When the Post, or Posts, are returned to the Controller, the Controller could then extract the unique User IDs from the returned set and pass them to a User factory. The returned User objects would then be passed along with the original Posts set to the View as a separate collection. The view could then grab user info using something like $users[$post->getUserId()]->getReputation().
A hybrid approach: Include the User object inside the Post object, but have the unique id extraction and User retrieval as part of the Post retrieval method. i.e. Post::getPosts() would grab all relevant posts and convert them to objects with null User members, then it'd extract all user ids and pass them to User::getUsers(), then assign the Users to the relevant Posts before returning the set of Posts to the caller.
I guess what I'm getting at is, how do I know when an object needs to contain another object fundamentally? Is it unclean/a code smell to instead have such related objects returned separately, with neither object knowing the other has been retrieved. I'm leaning towards the separate retrieval concept - it seems the most efficient - but it really does feel like they're too related for that to make sense.
There is also a solution in between 1 and 2. You can have a lazy loading proxy for the user class. With this solution you can have best of both worlds because the proxy is interchangeable with the real thing so depending on the situation you can have the object itself or the proxy.
Edit:
I'll try to explain this with an example.
Say that you have a view where you don't need user info, then you can instruct/configure your post factory to use the lazy proxy (see wikipedia)for the user which will only contain an ID. So no access to users is needed.
In another view you occasionally need to access user info but only for some posts, here again you instruct/configure your factory to include the lazy proxy for the user.
But when you actually need access to the user info, you can access the proxy object that will then load the actual user object and redirect messages to it.
In yet another view you need both post and user info, so here you instruct your post factory to use actual user objects.
It seems to me that this is another case of dependency injection. A general enough idea that could help you.
DEPENDENCY INJECTION WIKI
Read something about the Inversion Of Control also.
why not add optional member to model to know informations?? you can ignore when you don't need and can use when you do need.