[Openerp-community] Suggestion for OCA conventions

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] Suggestion for OCA conventions

Sandy Carter (http://www.savoirfairelinux.com)
Hi,

I would like propose adding the following to the Module section in
http://odoo-community.org/page/website.how-to

Each XML and python script should be separated and named by model.

example:

_name = 'sale.order'  # goes in a file named sale_order.py and the class
name should be SaleOrder

_inherit = 'sale.order.line'  # goes in a file named sale_order_line.py
and the class name should be SaleOrderLine

<!-- Goes in a file named res_partner_data.xml -->
<!-- Or goes in a file named res_partner_demo.xml -->
<record name="example_partner" model="res.partner">...</record>

<!-- Goes in a file named res_company_view.xml -->
<record id="res_company_form" model="ir.ui.view">
  <field name="model">res.company</field>
  ...
</record>

<!-- Goes in a file named purchase_order_workflow.xml -->
<record id="purchase_order_workflow" model="ir.ui.view">
  <field name="osv">purchase.order</field>
  ...
</record>

<!-- Goes in a file named payment_order_report.xml -->
<report id="payment_order_report"
        model="payment.order"
        ...
        />


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

David BEAL
Hi Sandy,

If we do like this with an example on a module:
2 models modified: 'product.product' and 'product.category' with adding a new field for each
It takes 5 or 20 lines by model. Having 2 files for this could be a lot.
I prefer one file named 'product.py'.

And if the code grows too much, the file can be split in 2

Maybe the limitation could be the file lines number ?

What do you think ?

Should odoo small modules takes java convention ? I don't think.




David BEAL - Akretion
Odoo Development / Integration
+33 (0)6 67 22 86 89 - +33 (0)4 82 53 84 60

2014-10-17 21:40 GMT+02:00 Sandy Carter <[hidden email]>:
Hi,

I would like propose adding the following to the Module section in
http://odoo-community.org/page/website.how-to

Each XML and python script should be separated and named by model.

example:

_name = 'sale.order'  # goes in a file named sale_order.py and the class
name should be SaleOrder

_inherit = 'sale.order.line'  # goes in a file named sale_order_line.py
and the class name should be SaleOrderLine

<!-- Goes in a file named res_partner_data.xml -->
<!-- Or goes in a file named res_partner_demo.xml -->
<record name="example_partner" model="res.partner">...</record>

<!-- Goes in a file named res_company_view.xml -->
<record id="res_company_form" model="ir.ui.view">
  <field name="model">res.company</field>
  ...
</record>

<!-- Goes in a file named purchase_order_workflow.xml -->
<record id="purchase_order_workflow" model="ir.ui.view">
  <field name="osv">purchase.order</field>
  ...
</record>

<!-- Goes in a file named payment_order_report.xml -->
<report id="payment_order_report"
        model="payment.order"
        ...
        />


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Sandy Carter (http://www.savoirfairelinux.com)
If a module is picked up, it is nice for the dev to be able to see
directly without openening the files what models have been affected.

The product example might start with a single field, but there is no
guarentee that it won't grow with additions of on_change methods or
simple overwrites which end up growing the file in line numbers.

In that case would should we advocate splitting the product.py into
product_category.py? At which point do we make that transition, and how
do we make sure that the code is properly factored and won't regress?


Le 2014-10-17 16:23, David Beal a écrit :

> Hi Sandy,
>
> If we do like this with an example on a module:
> 2 models modified: 'product.product' and 'product.category' with adding a
> new field for each
> It takes 5 or 20 lines by model. Having 2 files for this could be a lot.
> I prefer one file named 'product.py'.
>
> And if the code grows too much, the file can be split in 2
>
> Maybe the limitation could be the file lines number ?
>
> What do you think ?
>
> Should odoo small modules takes java convention ? I don't think.
>
>
>
>
> David BEAL - Akretion
> Odoo Development / Integration
> +33 (0)6 67 22 86 89 - +33 (0)4 82 53 84 60
>
> 2014-10-17 21:40 GMT+02:00 Sandy Carter <[hidden email]>:
>
>> Hi,
>>
>> I would like propose adding the following to the Module section in
>> http://odoo-community.org/page/website.how-to
>>
>> Each XML and python script should be separated and named by model.
>>
>> example:
>>
>> _name = 'sale.order'  # goes in a file named sale_order.py and the class
>> name should be SaleOrder
>>
>> _inherit = 'sale.order.line'  # goes in a file named sale_order_line.py
>> and the class name should be SaleOrderLine
>>
>> <!-- Goes in a file named res_partner_data.xml -->
>> <!-- Or goes in a file named res_partner_demo.xml -->
>> <record name="example_partner" model="res.partner">...</record>
>>
>> <!-- Goes in a file named res_company_view.xml -->
>> <record id="res_company_form" model="ir.ui.view">
>>   <field name="model">res.company</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named purchase_order_workflow.xml -->
>> <record id="purchase_order_workflow" model="ir.ui.view">
>>   <field name="osv">purchase.order</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named payment_order_report.xml -->
>> <report id="payment_order_report"
>>         model="payment.order"
>>         ...
>>         />
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : [hidden email]
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Pedro Manuel Baeza Romero
Hi, I'm with Sandy that splitting each model in a class is a win strategy, but with a middle term: if you have models that comes from a one2many field, I prefer having these classes also in the same file as the main class. For example, I would put sale.order and sale.order.line in the same file, sale_order.py, but res.partner in another file called res_partner.py.

Regards.

2014-10-17 22:36 GMT+02:00 Sandy Carter <[hidden email]>:
If a module is picked up, it is nice for the dev to be able to see
directly without openening the files what models have been affected.

The product example might start with a single field, but there is no
guarentee that it won't grow with additions of on_change methods or
simple overwrites which end up growing the file in line numbers.

In that case would should we advocate splitting the product.py into
product_category.py? At which point do we make that transition, and how
do we make sure that the code is properly factored and won't regress?


Le 2014-10-17 16:23, David Beal a écrit :
> Hi Sandy,
>
> If we do like this with an example on a module:
> 2 models modified: 'product.product' and 'product.category' with adding a
> new field for each
> It takes 5 or 20 lines by model. Having 2 files for this could be a lot.
> I prefer one file named 'product.py'.
>
> And if the code grows too much, the file can be split in 2
>
> Maybe the limitation could be the file lines number ?
>
> What do you think ?
>
> Should odoo small modules takes java convention ? I don't think.
>
>
>
>
> David BEAL - Akretion
> Odoo Development / Integration
> <a href="tel:%2B33%20%280%296%2067%2022%2086%2089" value="+33667228689">+33 (0)6 67 22 86 89 - <a href="tel:%2B33%20%280%294%2082%2053%2084%2060" value="+33482538460">+33 (0)4 82 53 84 60
>
> 2014-10-17 21:40 GMT+02:00 Sandy Carter <[hidden email]>:
>
>> Hi,
>>
>> I would like propose adding the following to the Module section in
>> http://odoo-community.org/page/website.how-to
>>
>> Each XML and python script should be separated and named by model.
>>
>> example:
>>
>> _name = 'sale.order'  # goes in a file named sale_order.py and the class
>> name should be SaleOrder
>>
>> _inherit = 'sale.order.line'  # goes in a file named sale_order_line.py
>> and the class name should be SaleOrderLine
>>
>> <!-- Goes in a file named res_partner_data.xml -->
>> <!-- Or goes in a file named res_partner_demo.xml -->
>> <record name="example_partner" model="res.partner">...</record>
>>
>> <!-- Goes in a file named res_company_view.xml -->
>> <record id="res_company_form" model="ir.ui.view">
>>   <field name="model">res.company</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named purchase_order_workflow.xml -->
>> <record id="purchase_order_workflow" model="ir.ui.view">
>>   <field name="osv">purchase.order</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named payment_order_report.xml -->
>> <report id="payment_order_report"
>>         model="payment.order"
>>         ...
>>         />
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : [hidden email]
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Franco Tampieri-2
I'm agree with Pedro but I think that files must have a maximum number of line to simplify comprension and reading. For example the new core stock module is not easy to read because have to many models and to many lines in one file: splitting it in more files will improve reading and comprension

My 2 cents 

Regards 

Franco

Il sabato 18 ottobre 2014, Pedro Manuel Baeza Romero <[hidden email]> ha scritto:
Hi, I'm with Sandy that splitting each model in a class is a win strategy, but with a middle term: if you have models that comes from a one2many field, I prefer having these classes also in the same file as the main class. For example, I would put sale.order and sale.order.line in the same file, sale_order.py, but res.partner in another file called res_partner.py.

Regards.

2014-10-17 22:36 GMT+02:00 Sandy Carter <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sandy.carter@savoirfairelinux.com&#39;);" target="_blank">sandy.carter@...>:
If a module is picked up, it is nice for the dev to be able to see
directly without openening the files what models have been affected.

The product example might start with a single field, but there is no
guarentee that it won't grow with additions of on_change methods or
simple overwrites which end up growing the file in line numbers.

In that case would should we advocate splitting the product.py into
product_category.py? At which point do we make that transition, and how
do we make sure that the code is properly factored and won't regress?


Le 2014-10-17 16:23, David Beal a écrit :
> Hi Sandy,
>
> If we do like this with an example on a module:
> 2 models modified: 'product.product' and 'product.category' with adding a
> new field for each
> It takes 5 or 20 lines by model. Having 2 files for this could be a lot.
> I prefer one file named 'product.py'.
>
> And if the code grows too much, the file can be split in 2
>
> Maybe the limitation could be the file lines number ?
>
> What do you think ?
>
> Should odoo small modules takes java convention ? I don't think.
>
>
>
>
> David BEAL - Akretion
> Odoo Development / Integration
> <a href="tel:%2B33%20%280%296%2067%2022%2086%2089" value="+33667228689" target="_blank">+33 (0)6 67 22 86 89 - <a href="tel:%2B33%20%280%294%2082%2053%2084%2060" value="+33482538460" target="_blank">+33 (0)4 82 53 84 60
>
> 2014-10-17 21:40 GMT+02:00 Sandy Carter <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sandy.carter@savoirfairelinux.com&#39;);" target="_blank">sandy.carter@...>:
>
>> Hi,
>>
>> I would like propose adding the following to the Module section in
>> http://odoo-community.org/page/website.how-to
>>
>> Each XML and python script should be separated and named by model.
>>
>> example:
>>
>> _name = 'sale.order'  # goes in a file named sale_order.py and the class
>> name should be SaleOrder
>>
>> _inherit = 'sale.order.line'  # goes in a file named sale_order_line.py
>> and the class name should be SaleOrderLine
>>
>> <!-- Goes in a file named res_partner_data.xml -->
>> <!-- Or goes in a file named res_partner_demo.xml -->
>> <record name="example_partner" model="res.partner">...</record>
>>
>> <!-- Goes in a file named res_company_view.xml -->
>> <record id="res_company_form" model="ir.ui.view">
>>   <field name="model">res.company</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named purchase_order_workflow.xml -->
>> <record id="purchase_order_workflow" model="ir.ui.view">
>>   <field name="osv">purchase.order</field>
>>   ...
>> </record>
>>
>> <!-- Goes in a file named payment_order_report.xml -->
>> <report id="payment_order_report"
>>         model="payment.order"
>>         ...
>>         />
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;openerp-community@lists.launchpad.net&#39;);" target="_blank">openerp-community@...
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;openerp-community@lists.launchpad.net&#39;);" target="_blank">openerp-community@...
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Daniel Reis (SECURITAS SA)-3
In reply to this post by Pedro Manuel Baeza Romero

On 18-10-2014 09:12, Pedro Manuel Baeza Romero wrote:
> Hi, I'm with Sandy that splitting each model in a class is a win
> strategy, but with a middle term: if you have models that comes from a
> one2many field, I prefer having these classes also in the same file as
> the main class. For example, I would put sale.order and
> sale.order.line in the same file, /sale_order.py/, but res.partner in
> another file called /res_partner.py/.
+1 for Pedro. Most of the time "lines" are just a "part" of parent model
and it can make sense to keep them together.

DR

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Sylvain LE GAL
Hi,

I agree with Sandy's suggestion.

About the sale_order and sale_order_line files, I would prefer two files. It avoid to have an exception on the basic rule "one model, one file", that is maybe not perfect, but like all rules...

Note:
Once that is decided, we can imagine a script to check that rules, (such as checking pep8) and report result in Travis.

Regards.


Sylvain LE GAL
Service informatique
Groupement Régional Alimentaire de Proximité

3 Grande rue des feuillants 69001 Lyon
Bureau :
(+33) <a href="tel:09.72.32.33.17" value="+33972323317" target="_blank">09.72.32.33.17
Astreinte :
<a href="tel:%28%2B33%29%2006.81.85.61.43" value="+33681856143" target="_blank">(+33) 06.81.85.61.43

Site Web : www.grap.coop
Twitter :
@legalsylvain


2014-10-19 15:45 GMT+02:00 Daniel Reis <[hidden email]>:

On 18-10-2014 09:12, Pedro Manuel Baeza Romero wrote:
Hi, I'm with Sandy that splitting each model in a class is a win strategy, but with a middle term: if you have models that comes from a one2many field, I prefer having these classes also in the same file as the main class. For example, I would put sale.order and sale.order.line in the same file, /sale_order.py/, but res.partner in another file called /res_partner.py/.
+1 for Pedro. Most of the time "lines" are just a "part" of parent model and it can make sense to keep them together.

DR


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Lionel Sausin
In reply to this post by Sandy Carter (http://www.savoirfairelinux.com)
Hi,
Please let me object to this new rule, which I find wrong in several ways.
I'm very attached to separation of concerns, and I would much rather
have us use the files to group all the code that implements a feature.
Actually, I often prefer to split a class in several files if that makes
sense from a functional point of view.
This is also literally counter-productive, since a decent IDE will let
you easily skim the classes inside a file anyway, but won't help us
spread the classes in distinct files.
Finally, any rule we may add raises the barrier of entry for new
contributions, and as much as I agree that we should have very high
standards of quality and maintainability, I find this rule totally
useless to this aim.
Lionel.

Le 17/10/2014 21:40, Sandy Carter a écrit :
> I would like propose adding the following to the Module section in
> http://odoo-community.org/page/website.how-to
>
> Each XML and python script should be separated and named by model.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Graeme Gellatly
In reply to this post by Sylvain LE GAL
Hi,

While having a sale order line modification in the same file as sale order makes some sense, these can become big files and it's nice to see them split, but then in addon modules maybe not.  But for me this comes down to personal preference, not sure it needs to be a convention.  Sometimes it makes sense to go one way, sometimes the other and usually I think it is fairly obvious.  Often refactors are about moving functionality between models (e.g. call one write on parent, or create separate function in submodel) and I find it much easier when they are one file, but then sometimes two models are so closely related, e.g. product_template and product_product and so verbose that I find having them separated is easier.  With wizards, normally the code is reasonably short and does a specific thing, so I put all models in one file for that wizard.  But then again for the xml files I find myself in complete agreement.  If you just did for xml you would know anyway the models affected.  So maybe I'd like the rule for xml files, but for python files a bit more common sense.  While it might be nice for the person looking at the list of files for the first time, I'd rather we gave preference to the people writing and maintaining the code and let them choose.

I've taken support off the mail, I don't really need 2 copies of every mail.

On Mon, Oct 20, 2014 at 8:15 AM, Sylvain LE GAL <[hidden email]> wrote:
Hi,

I agree with Sandy's suggestion.

About the sale_order and sale_order_line files, I would prefer two files. It avoid to have an exception on the basic rule "one model, one file", that is maybe not perfect, but like all rules...

Note:
Once that is decided, we can imagine a script to check that rules, (such as checking pep8) and report result in Travis.

Regards.


Sylvain LE GAL
Service informatique
Groupement Régional Alimentaire de Proximité

3 Grande rue des feuillants 69001 Lyon
Bureau :
(+33) <a href="tel:09.72.32.33.17" value="+33972323317" target="_blank">09.72.32.33.17
Astreinte :
<a href="tel:%28%2B33%29%2006.81.85.61.43" value="+33681856143" target="_blank">(+33) 06.81.85.61.43

Site Web : www.grap.coop
Twitter :
@legalsylvain


2014-10-19 15:45 GMT+02:00 Daniel Reis <[hidden email]>:

On 18-10-2014 09:12, Pedro Manuel Baeza Romero wrote:
Hi, I'm with Sandy that splitting each model in a class is a win strategy, but with a middle term: if you have models that comes from a one2many field, I prefer having these classes also in the same file as the main class. For example, I would put sale.order and sale.order.line in the same file, /sale_order.py/, but res.partner in another file called /res_partner.py/.
+1 for Pedro. Most of the time "lines" are just a "part" of parent model and it can make sense to keep them together.

DR


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Guewen Baconnier @ Camptocamp
On 10/19/2014 10:46 PM, Graeme Gellatly wrote:

> Hi,
>
> While having a sale order line modification in the same file as sale
> order makes some sense, these can become big files and it's nice to see
> them split, but then in addon modules maybe not.  But for me this comes
> down to personal preference, not sure it needs to be a convention.
> Sometimes it makes sense to go one way, sometimes the other and usually
> I think it is fairly obvious.  Often refactors are about moving
> functionality between models (e.g. call one write on parent, or create
> separate function in submodel) and I find it much easier when they are
> one file, but then sometimes two models are so closely related, e.g.
> product_template and product_product and so verbose that I find having
> them separated is easier.  With wizards, normally the code is reasonably
> short and does a specific thing, so I put all models in one file for
> that wizard.  But then again for the xml files I find myself in complete
> agreement.  If you just did for xml you would know anyway the models
> affected.  So maybe I'd like the rule for xml files, but for python
> files a bit more common sense.  While it might be nice for the person
> looking at the list of files for the first time, I'd rather we gave
> preference to the people writing and maintaining the code and let them
> choose.
>

I totally agree with Graeme.

--
Guewen Baconnier
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 39
Office: +41 21 619 10 10
http://www.camptocamp.com/

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Leonardo Pistone - camptocamp
Hi all,

I understand the convenience of finding classes easily, and the
reasons behind this are sound. Still, I do not sopport such a rule on
splitting files.

Still, I think we can and should work to improve subjective quality
and clarity of code. Example: after the machine checked lint, I think
we can (and should) gradually move to comments like

- this method / this file is long, can you split it?
- I don't understand what this is for, can you comment or refactor?
- why do we need that? (comment or refactor)
- (and one day, gradually...) could you decouple this logic from the
database schema to a pure class?

TL;DR I oppose a rule on file length and such, but I favor subjective
criticism to get the code as clear as possible.

Thanks to all for the involvement!

On 10/19/2014 10:46 PM, Graeme Gellatly wrote:
But for me this comes
> down to personal preference, not sure it needs to be a convention.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Sandy Carter (http://www.savoirfairelinux.com)
Hi,

My issue with leaving it to subjective criticism is:

Firstly, if you're new and learning the ropes to contribution to OCA and
you do your homework, you're going to do two things to make sure your
module gets integrated. First you'll check existing modules and emulate
what they do and second you'll read the guidelines. Like I mentioned at
the beginning, there are many cases of X models in files named like
'product.py', and if you look at the guidelines[1], it is still bare in
many parts.

We see this today, a new dev will do her work, prepare her module using
these guidelines. When he finally does a pull request, we come down on
him with these subjective reviews, that we are used to, but to the dev,
these seem completely arbitrary. The result is often that the new dev
will redo her module multiple times with no more guidelines than the
review of a select few contributors who have had the time to review her
code. Another possible outcome, is that these PRs get stuck in limbo
where the dev might have moved on to another project.

A second problem with subjective criticism is when a disagreement is met
or a dev making a PR is unwilling to change his code and chooses to
argue every point.

Without the points in the review page, a subjective review has very
little weight, you can't just point at the page and say: "These are the
standards we do our review by, this is what everyone who contributes
agrees to for the sake of uniform coding style". Instead we find
ourselves saying: "This is better because it is", "This is what is done
in most modules", "This is not yet on the page".

These two situations happen quite often. I have multiple less
experienced Odoo developers come to me frustrated because their PRs are
being stalled for what seems to them to be arbitrary reasons. The first
thing they ask is usually "What does she mean by X? This seems
unreasonable." I often reply with "That kind of sucks but I agree with
his review". the second thing they ask is "Where can I find all these
guidelines so I can avoid being stalled on getting my code merged?" And
for that, I would love to be able to refer to the guidelines page[1]. At
the present, I can't really...

What the consensus I seem to get out of this is: Often it is better to
separate the models (especially in xml), but there are some acceptable
exceptions:

* Small changes to models
  * One to many relationships (single column add to related model)
  * At some point, a small change becomes to big and the file must be split.
* All changes are very closely related to a same feature
* Wizards
* Connectors (I'm adding this one)

No one seemed to object to naming the Class, .py file and xml files
according to the model (or largest model in the case of filenames).

Is this something we can agree on?

[1] http://odoo-community.org/page/website.how-to

Le 2014-10-20 05:39, Leonardo Pistone a écrit :

> Hi all,
>
> I understand the convenience of finding classes easily, and the
> reasons behind this are sound. Still, I do not sopport such a rule on
> splitting files.
>
> Still, I think we can and should work to improve subjective quality
> and clarity of code. Example: after the machine checked lint, I think
> we can (and should) gradually move to comments like
>
> - this method / this file is long, can you split it?
> - I don't understand what this is for, can you comment or refactor?
> - why do we need that? (comment or refactor)
> - (and one day, gradually...) could you decouple this logic from the
> database schema to a pure class?
>
> TL;DR I oppose a rule on file length and such, but I favor subjective
> criticism to get the code as clear as possible.
>
> Thanks to all for the involvement!
>
> On 10/19/2014 10:46 PM, Graeme Gellatly wrote:
> But for me this comes
>> down to personal preference, not sure it needs to be a convention.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : [hidden email]
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Pedro Manuel Baeza Romero
Sandy, for me it's OK this way.

Regards.

2014-10-20 16:52 GMT+02:00 Sandy Carter <[hidden email]>:
Hi,

My issue with leaving it to subjective criticism is:

Firstly, if you're new and learning the ropes to contribution to OCA and
you do your homework, you're going to do two things to make sure your
module gets integrated. First you'll check existing modules and emulate
what they do and second you'll read the guidelines. Like I mentioned at
the beginning, there are many cases of X models in files named like
'product.py', and if you look at the guidelines[1], it is still bare in
many parts.

We see this today, a new dev will do her work, prepare her module using
these guidelines. When he finally does a pull request, we come down on
him with these subjective reviews, that we are used to, but to the dev,
these seem completely arbitrary. The result is often that the new dev
will redo her module multiple times with no more guidelines than the
review of a select few contributors who have had the time to review her
code. Another possible outcome, is that these PRs get stuck in limbo
where the dev might have moved on to another project.

A second problem with subjective criticism is when a disagreement is met
or a dev making a PR is unwilling to change his code and chooses to
argue every point.

Without the points in the review page, a subjective review has very
little weight, you can't just point at the page and say: "These are the
standards we do our review by, this is what everyone who contributes
agrees to for the sake of uniform coding style". Instead we find
ourselves saying: "This is better because it is", "This is what is done
in most modules", "This is not yet on the page".

These two situations happen quite often. I have multiple less
experienced Odoo developers come to me frustrated because their PRs are
being stalled for what seems to them to be arbitrary reasons. The first
thing they ask is usually "What does she mean by X? This seems
unreasonable." I often reply with "That kind of sucks but I agree with
his review". the second thing they ask is "Where can I find all these
guidelines so I can avoid being stalled on getting my code merged?" And
for that, I would love to be able to refer to the guidelines page[1]. At
the present, I can't really...

What the consensus I seem to get out of this is: Often it is better to
separate the models (especially in xml), but there are some acceptable
exceptions:

* Small changes to models
  * One to many relationships (single column add to related model)
  * At some point, a small change becomes to big and the file must be split.
* All changes are very closely related to a same feature
* Wizards
* Connectors (I'm adding this one)

No one seemed to object to naming the Class, .py file and xml files
according to the model (or largest model in the case of filenames).

Is this something we can agree on?

[1] http://odoo-community.org/page/website.how-to

Le 2014-10-20 05:39, Leonardo Pistone a écrit :
> Hi all,
>
> I understand the convenience of finding classes easily, and the
> reasons behind this are sound. Still, I do not sopport such a rule on
> splitting files.
>
> Still, I think we can and should work to improve subjective quality
> and clarity of code. Example: after the machine checked lint, I think
> we can (and should) gradually move to comments like
>
> - this method / this file is long, can you split it?
> - I don't understand what this is for, can you comment or refactor?
> - why do we need that? (comment or refactor)
> - (and one day, gradually...) could you decouple this logic from the
> database schema to a pure class?
>
> TL;DR I oppose a rule on file length and such, but I favor subjective
> criticism to get the code as clear as possible.
>
> Thanks to all for the involvement!
>
> On 10/19/2014 10:46 PM, Graeme Gellatly wrote:
> But for me this comes
>> down to personal preference, not sure it needs to be a convention.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : [hidden email]
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Houssine BAKKALI
why not just to add an entry in the manifest to say which model has been inherited/modified as it AFAIU the main reason raised.

splitting the modification in files by model make sense for xml but for py file as far as they contain a bug number of lines of code we won't gain any benefit.

my 2 cents...

2014-10-20 16:57 GMT+02:00 Pedro Manuel Baeza Romero <[hidden email]>:
Sandy, for me it's OK this way.

Regards.

2014-10-20 16:52 GMT+02:00 Sandy Carter <[hidden email]>:
Hi,

My issue with leaving it to subjective criticism is:

Firstly, if you're new and learning the ropes to contribution to OCA and
you do your homework, you're going to do two things to make sure your
module gets integrated. First you'll check existing modules and emulate
what they do and second you'll read the guidelines. Like I mentioned at
the beginning, there are many cases of X models in files named like
'product.py', and if you look at the guidelines[1], it is still bare in
many parts.

We see this today, a new dev will do her work, prepare her module using
these guidelines. When he finally does a pull request, we come down on
him with these subjective reviews, that we are used to, but to the dev,
these seem completely arbitrary. The result is often that the new dev
will redo her module multiple times with no more guidelines than the
review of a select few contributors who have had the time to review her
code. Another possible outcome, is that these PRs get stuck in limbo
where the dev might have moved on to another project.

A second problem with subjective criticism is when a disagreement is met
or a dev making a PR is unwilling to change his code and chooses to
argue every point.

Without the points in the review page, a subjective review has very
little weight, you can't just point at the page and say: "These are the
standards we do our review by, this is what everyone who contributes
agrees to for the sake of uniform coding style". Instead we find
ourselves saying: "This is better because it is", "This is what is done
in most modules", "This is not yet on the page".

These two situations happen quite often. I have multiple less
experienced Odoo developers come to me frustrated because their PRs are
being stalled for what seems to them to be arbitrary reasons. The first
thing they ask is usually "What does she mean by X? This seems
unreasonable." I often reply with "That kind of sucks but I agree with
his review". the second thing they ask is "Where can I find all these
guidelines so I can avoid being stalled on getting my code merged?" And
for that, I would love to be able to refer to the guidelines page[1]. At
the present, I can't really...

What the consensus I seem to get out of this is: Often it is better to
separate the models (especially in xml), but there are some acceptable
exceptions:

* Small changes to models
  * One to many relationships (single column add to related model)
  * At some point, a small change becomes to big and the file must be split.
* All changes are very closely related to a same feature
* Wizards
* Connectors (I'm adding this one)

No one seemed to object to naming the Class, .py file and xml files
according to the model (or largest model in the case of filenames).

Is this something we can agree on?

[1] http://odoo-community.org/page/website.how-to

Le 2014-10-20 05:39, Leonardo Pistone a écrit :
> Hi all,
>
> I understand the convenience of finding classes easily, and the
> reasons behind this are sound. Still, I do not sopport such a rule on
> splitting files.
>
> Still, I think we can and should work to improve subjective quality
> and clarity of code. Example: after the machine checked lint, I think
> we can (and should) gradually move to comments like
>
> - this method / this file is long, can you split it?
> - I don't understand what this is for, can you comment or refactor?
> - why do we need that? (comment or refactor)
> - (and one day, gradually...) could you decouple this logic from the
> database schema to a pure class?
>
> TL;DR I oppose a rule on file length and such, but I favor subjective
> criticism to get the code as clear as possible.
>
> Thanks to all for the involvement!
>
> On 10/19/2014 10:46 PM, Graeme Gellatly wrote:
> But for me this comes
>> down to personal preference, not sure it needs to be a convention.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : [hidden email]
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Stefan Rijnhart (Therp)
In reply to this post by Sandy Carter (http://www.savoirfairelinux.com)
On 20-10-14 16:52, Sandy Carter wrote:

> What the consensus I seem to get out of this is: Often it is better to
> separate the models (especially in xml), but there are some acceptable
> exceptions:
>
> * Small changes to models
>   * One to many relationships (single column add to related model)
>   * At some point, a small change becomes to big and the file must be split.
> * All changes are very closely related to a same feature
> * Wizards
> * Connectors (I'm adding this one)
>
> No one seemed to object to naming the Class, .py file and xml files
> according to the model (or largest model in the case of filenames).
>
> Is this something we can agree on?

Thanks for writing such a clear motivation! I support your proposal, as
long as refactorings along these lines will not be demanded in reviews
of small bug fixing pull requests in legacy modules.



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Raphael Valyi
Hello, I share the same opinion as Stefan about this.
In any case we should not forget the big picture and loose our energy on details that could easily become void depending on the big picture, even if ideally enforcing such guidelines will be great for new stuff or refactoring.

Regards and thanks for the work.

On Tue, Oct 21, 2014 at 10:15 AM, Stefan <[hidden email]> wrote:
On 20-10-14 16:52, Sandy Carter wrote:
> What the consensus I seem to get out of this is: Often it is better to
> separate the models (especially in xml), but there are some acceptable
> exceptions:
>
> * Small changes to models
>   * One to many relationships (single column add to related model)
>   * At some point, a small change becomes to big and the file must be split.
> * All changes are very closely related to a same feature
> * Wizards
> * Connectors (I'm adding this one)
>
> No one seemed to object to naming the Class, .py file and xml files
> according to the model (or largest model in the case of filenames).
>
> Is this something we can agree on?

Thanks for writing such a clear motivation! I support your proposal, as
long as refactorings along these lines will not be demanded in reviews
of small bug fixing pull requests in legacy modules.



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Sylvain LE GAL
Stefen, Raphael +1

What about to have 2 sections in http://odoo-community.org/page/website.how-to

- "Mandatory" rules: pep8 ... that will block PR if not respected;
- "Nice to Have" rules with sandy's remarks (and others conventions), that will not block PR;

My 2 cents.

Sylvain LE GAL
Service informatique
Groupement Régional Alimentaire de Proximité

3 Grande rue des feuillants 69001 Lyon
Bureau :
(+33) 09.72.32.33.17
Astreinte :
(+33) 06.81.85.61.43

Site Web : www.grap.coop
Twitter :
@legalsylvain


2014-10-21 14:37 GMT+02:00 Raphael Valyi <[hidden email]>:
Hello, I share the same opinion as Stefan about this.
In any case we should not forget the big picture and loose our energy on details that could easily become void depending on the big picture, even if ideally enforcing such guidelines will be great for new stuff or refactoring.

Regards and thanks for the work.

On Tue, Oct 21, 2014 at 10:15 AM, Stefan <[hidden email]> wrote:
On 20-10-14 16:52, Sandy Carter wrote:
> What the consensus I seem to get out of this is: Often it is better to
> separate the models (especially in xml), but there are some acceptable
> exceptions:
>
> * Small changes to models
>   * One to many relationships (single column add to related model)
>   * At some point, a small change becomes to big and the file must be split.
> * All changes are very closely related to a same feature
> * Wizards
> * Connectors (I'm adding this one)
>
> No one seemed to object to naming the Class, .py file and xml files
> according to the model (or largest model in the case of filenames).
>
> Is this something we can agree on?

Thanks for writing such a clear motivation! I support your proposal, as
long as refactorings along these lines will not be demanded in reviews
of small bug fixing pull requests in legacy modules.



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

David BEAL
@sylvain

ok for me
makes sense to have 'mandatory' and 'nice to have' rules

and in 'nice to have' could we capture travis answers in PR comments like ?
"your file ... have more X00 lines, have you considered to split several files to improve readbility ..."
or
"seems there are no link between models in your file ..."

maybe with these kinds of tools https://pythonhosted.org/jig/

my 2 cents


David BEAL - Akretion
Odoo Development / Integration
+33 (0)6 67 22 86 89 - +33 (0)4 82 53 84 60

2014-10-21 15:12 GMT+02:00 Sylvain LE GAL <[hidden email]>:
Stefen, Raphael +1

What about to have 2 sections in http://odoo-community.org/page/website.how-to

- "Mandatory" rules: pep8 ... that will block PR if not respected;
- "Nice to Have" rules with sandy's remarks (and others conventions), that will not block PR;

My 2 cents.

Sylvain LE GAL
Service informatique
Groupement Régional Alimentaire de Proximité

3 Grande rue des feuillants 69001 Lyon
Bureau :
(+33) 09.72.32.33.17
Astreinte :
<a href="tel:%28%2B33%29%2006.81.85.61.43" value="+33681856143" target="_blank">(+33) 06.81.85.61.43

Site Web : www.grap.coop
Twitter :
@legalsylvain


2014-10-21 14:37 GMT+02:00 Raphael Valyi <[hidden email]>:
Hello, I share the same opinion as Stefan about this.
In any case we should not forget the big picture and loose our energy on details that could easily become void depending on the big picture, even if ideally enforcing such guidelines will be great for new stuff or refactoring.

Regards and thanks for the work.

On Tue, Oct 21, 2014 at 10:15 AM, Stefan <[hidden email]> wrote:
On 20-10-14 16:52, Sandy Carter wrote:
> What the consensus I seem to get out of this is: Often it is better to
> separate the models (especially in xml), but there are some acceptable
> exceptions:
>
> * Small changes to models
>   * One to many relationships (single column add to related model)
>   * At some point, a small change becomes to big and the file must be split.
> * All changes are very closely related to a same feature
> * Wizards
> * Connectors (I'm adding this one)
>
> No one seemed to object to naming the Class, .py file and xml files
> according to the model (or largest model in the case of filenames).
>
> Is this something we can agree on?

Thanks for writing such a clear motivation! I support your proposal, as
long as refactorings along these lines will not be demanded in reviews
of small bug fixing pull requests in legacy modules.



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Leonardo Pistone - camptocamp
In reply to this post by Sandy Carter (http://www.savoirfairelinux.com)
Hi Sandy,

Thanks a log for bringing up the problem of frustration by newcomers.
There are indeed things we can do to ease the barrier of entry.

I think we should wipe the document, and start entering the
conventions that are already accepted, that is those that we already
check with flake8 and pylint.

On the topic of one-file-per-class, I understand the reasons, but I
vote -1 because it seems too restricting to me, and I see many good
quality python projects not doing so. Still, I am not fighting on
that. I consider it a minor point.

Let me spend a few words about the part of the discussion I really
care about. I am really enthusiastic that we have infrastructure up
and running that checks lint because that does well a part of the job
and allows us to concentrate on the important part: doing code review
as a human activity, to find out if code is understandable, well
structured and so on.

Take for example any of the huge python files in the core, like
account.py. Imagine it going through our code review.

The first pass would be automatic: we would get rid of unused
variables, long lines and so on. We could ask to split the classes in
smaller files. That is great but it is just the start.

Then we would get to the real code review, where humans say things like:
- what are __compute(), res, res2, ids, ids2? What does that mean? Can
you refactor?
- why a class with 43 methods? maybe we need a service class, or a mixin?
- the docstring says that "context" is a context, and we know that.
Instead, describe what the method if it is not clear from the name.
- this duplicates code from class XY. can we make it more orthogonal?
- I just do not understand at all what this method is about. can you
clarify / refactor / document?

And so on. The same of course goes for tests: it is a great and
necessary start that the machine tells us the coverage, but then our
review will say, for example "this test does not reflect the use case
in the manifest, can you explain?".

Thanks to all and sorry for the long mail.
L

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Suggestion for OCA conventions

Sandy Carter (http://www.savoirfairelinux.com)
Le 2014-10-22 04:09, Leonardo Pistone a écrit :

> I think we should wipe the document, and start entering the
> conventions that are already accepted, that is those that we already
> check with flake8 and pylint.

+1

> On the topic of one-file-per-class, I understand the reasons, but I
> vote -1 because it seems too restricting to me, and I see many good
> quality python projects not doing so. Still, I am not fighting on
> that. I consider it a minor point.

I would just like to clarify that I am not asking for
one-file-per-class, but one-file-per-model.

Helper classes should be where it is most logical to put them.

What makes the case of Odoo different from some other python projects is
that in 90% of our cases we deal with ORM models and not purely Object
Oriented classes. Usual workflow consists of altering one or multiple
models. In my opinion, having them separate improves readability and
makes maintenance easier.

Some are suggesting we do the one-file-per-model as a "Nice to have".
Have no problem with that, but I'd rather call it a "Strong
recommendation". ;)

> Take for example any of the huge python files in the core, like
> account.py. Imagine it going through our code review.
>
> The first pass would be automatic: we would get rid of unused
> variables, long lines and so on. We could ask to split the classes in
> smaller files. That is great but it is just the start.
>
> Then we would get to the real code review, where humans say things like:
> - what are __compute(), res, res2, ids, ids2? What does that mean? Can
> you refactor?
> - why a class with 43 methods? maybe we need a service class, or a mixin?
> - the docstring says that "context" is a context, and we know that.
> Instead, describe what the method if it is not clear from the name.
> - this duplicates code from class XY. can we make it more orthogonal?
> - I just do not understand at all what this method is about. can you
> clarify / refactor / document?
>
> And so on. The same of course goes for tests: it is a great and
> necessary start that the machine tells us the coverage, but then our
> review will say, for example "this test does not reflect the use case
> in the manifest, can you explain?".
+1 to this, I think we could reformulate this to fit it into the
guidelines document to, at least, explain the process and what we
reviewers should look for.


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp

signature.asc (484 bytes) Download Attachment