[ROADMAP] Module prototyper

[max3903]

Backlog

• Fix icon file extension
• Fix copying existing models and fields by prefixing new models and fields with x_
• Security files (rules, ir.model.access.csv)
• Add an action on the list view to export many modules in the same zip file
• Attach images to the prototype and export them to be used in the 'images' module manifest
• Provide links on the prototype to easily access Models, Fields, Views, Menu Items, Groups, Access Rights, Security Rules, Workflows, Reports
• Add a Report tab to select and export reports
• Add a Workflow tab to select and export workflows, nodes, transitions, actions
• Add a Website tab to select Menu Item and Pages
• Include controllers.py and templates.xml from scaffold

Private suggestion by @blaggacao

Odoo scaffolding already constructs a basic template for a web interface in the controllers.py and the templates.xml in the sci/templates/default folder...

I think maybe it would be good practice to include such templates into the prototype module, even if they only have limited significance (like the listing of objects and fields in the offical templates). It would help to make people aware of the possibility to have some front-end part for a module...

• Allow export of attachments with data

We would like to export files attached to document pages (images for example, see OCA/knowledge#39), so that when we install the exported module, we have the document page content and its attachments.

[blaggacao]

👍 thanks

[max3903]

ping @bealdav @foutoucour

[OSguard]

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.

[foutoucour]

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?

[OSguard]

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.

[foutoucour]

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

On Sun, Feb 22, 2015, 16:14 Markus Schneider notifications@github.com
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
#104 (comment).

[bealdav]

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

[blaggacao]

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

[max3903]

@blaggacao yes you can

[blaggacao]

@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?

[max3903]

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

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

[veloutin]

@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".

[blaggacao]

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

[blaggacao]

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

[blaggacao]

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.

[blaggacao]

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...

[pedrobaeza]

We can close as module is developed.

[max3903]

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

[github-actions]

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.