[ROADMAP] Module prototyper about server-tools HOT 19 CLOSED

👍 thanks

from server-tools.

ping @bealdav @foutoucour

from server-tools.

We working at the moment on a module that it is able to export data in odoo-xml format, so that it is 'easy' to export demo data. At the moment it is highly experimental but before someone start working also on this topic get in touch.

from server-tools.

Hey @OSguard

We planned to do it in csv actually as the export in xml is way harder but if you have something to handle the export, we'll more than happy to use it :)
Escuse my inexperience but what are the benefits with an export in xml? Is it because it would be easier to maintain?

from server-tools.

hey @foutoucour

yes it is harder,
actually what we are working on that you can choose in the export wizard in odoo, which data you want to export. Like you have a sale.order and you want to export then including res.partner, product.product, sale.order.line for example. So you have it in one xml file with relation, but you need multiple csv files. The challenge is write the data in right order in the xml file ;) - this is harder than we thought in the first place as if it is dynamically depending on the model-relation and the data you want to export.

from server-tools.

Got it. Thanks for the explanation.
Let us know when you release something public.

On Sun, Feb 22, 2015, 16:14 Markus Schneider [email protected]
wrote:

hey @foutoucour https://github.com/foutoucour

yes it is harder,
actually what we are working on that you can choose in the export wizard
in odoo, which data you want to export. Like you have a sale.order and you
want to export then including res.partner, product.product, sale.order.line
for example. So you have it in one xml file with relation, but you need
multiple csv files. The challenge is write the data in right order in the
xml file ;) - this is harder than we thought in the first place as if it is
dynamically depending on the model-relation and the data you want to export.

Reply to this email directly or view it on GitHub
https://github.com/OCA/server-tools/issues/104#issuecomment-75459123.

from server-tools.

about csv -> xml.

A quick and dirty script https://github.com/akretion/csv2xml4odoo

To get less dirty it miss the connexion to odoo to define the real type of the column to avoid to guess column type with data.
Contribution welcome to support o2m

from server-tools.

Hi @max3903 , can I already use this (more or less safely)?
I'd like to test-use it as early adopter and functional dumbass with some limited technical insights 😄
ping @kurkop

from server-tools.

@blaggacao yes you can

from server-tools.

@max3903 I recently started actively using the module, so I come up with a "user story" here:
As a user, I want to be able to copy fields or entire models easily, in order to speed up the prototyping process significantly (as I can just copy, similar, but existing items). At the moment this is inhibited by the copy method which does not do the necessary adaptions ("x_", change fields with unique constraint so they be unique). One solution path would be to overwrite the copy methods on 'ir.model.fields' and 'ir.model'. Is it?

from server-tools.

@blaggacao Yes. I added this feature to the backlog.

Can you review #107 so we can merge version 0.3 ?

from server-tools.

@blaggacao I'm not sure about the impacts of overriding copy() on fields and models, but it would indeed be a way to create new fields and models with the x_ prefix. If overriding it has impacts, perhaps a new action would be a good idea as well, e.g. "Copy as Prototype".

from server-tools.

@veloutin I'm glad you took my innocent pass to the next level, thank's for your response(s)! 😄

from server-tools.

Hello, I've got another one. When exporting the module data, basic cleanup is easily done by a regex, but some stuff, such as relations (with the ref= attribute) are hard to accomplish without an additional parser script.

As for the regex, here is what I used:
.*create_.*\n|.*write_.*\n|.*"__last_update".*\n|.*"company_id".*\n|.*"id".*\n
Implicit False on some integer fields are not recognized, so there would be a cleanup needed there as well. Here is one example regex I used: (.*"parent_id">)False : $1

I was able to reorder and clean relational fields with this (parent_id">)\((\d*),.*(</field>) : $1$2$3.
It is however not trivial to get the required linked external id into the ref attribute.

Also, it would be nice to have the external id named after the modules name:
"account.tax_ : "l10n_co.tax_

ordering hasn't been a problem so far, i think if the rule is one model one xml file, this should be fine, ordering then is probably a question of which order they are referenced with in the __openerp__.py. one should however avoid to create a children before a parent, but if you're working with csv import to build your data this is impossible anyhow.

Update 1:
I'm starting my lie of thought here, amplifying the jinja template with ref and eval and maybe the {% if val %} might elegantly solve the implicit false problem.

        {% for key, ref, eval, val in record.read()[0].items() %}
            <field name="{{ key }}" {% if ref %} ref="{{ ref }}"{% endif %}{% if eval %} eval="{{ eval }}"{% endif %}>{% if val %}{{ val }}{% endif %}</field>
        {% endfor %}

Update 2:
Those are the magic fields, that nobody needs in this context. See last line...

    _env = None
    _data_files = ()
    _demo_files = ()
    _field_descriptions = None
    File_details = namedtuple('file_details', ['filename', 'filecontent'])
    template_path = '{}/../templates/'.format(os.path.dirname(__file__))
    MAGIC_FIELDS_KEY = ["create_date", "create_uid", "write_uid", "id", "__last_update", "write_date"]

Update 3:
I don't know, if this is the way to do the cleanup, just copy-guessing:

@api.model
def generate_data_files(self):
    [...]
            for model_name, records in model_data.iteritems():
                fname = self.friendly_name(self.unprefix(model_name))
                filename = '{0}/{1}.xml'.format(prefix, fname)
                self._data_files.append(filename)
                records = self.cleanup_data(self.fixup_data(records)) # this shall d the magic... first fixup, the cleaning

    @classmethod
    def cleanup_data(cls, records):
        r = dict(records)
        for key in MAGIC_FIELDS_KEY:
            del r[key]
        return r

from server-tools.

another learning, that we've had is, that if python code contains < sign, it would need to be wrapped into <![CDATA[ ]]> alternatively (and maybe better) <, >, & can be transformed to <, >, &
else element tree would complain about invalid ending tag.

from server-tools.

This is at very low scientific level, but I hope it to be useful as a template line of thought
For the sorting problem of referenced children that might have been manually created before their parents *which would suposedly give them db ids in the wrong order, so import would fail), I would suggest the following approach:

• check the highest db id of a given dict
• round to the next e10
• add this value to every dependent entry once and update referenced ids
• check if there is an item that now references a number above this e10 (this is a child of child)
• repeat this, and add every time e10
• when nothing is left, sort by this probably temporary sorting colum
• that's it

cross model precedence would be a task of the openerp.py, I think...

from server-tools.

We can close as module is developed.

from server-tools.

@pedrobaeza Module is developed but not all the features are in it yet.

from server-tools.

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

from server-tools.