Odoo Addons (MOVED TO GITHUB)

Bug #1190313
Comment #8

Comment 8 for bug 1190313

Revision history for this message

Olivier Dony (Odoo) (odo-openerp) wrote on 2013-06-13: Re: [Bug 1190313] Re: [trunk,7.0,6.1] edi does not manage webkit reports

On 06/13/2013 12:35 PM, invitu wrote:
> actually, in 6.1, we cannot use both rml and webkit reports with edi...

Yes I understand the problem you describe, but to me this could be seen as a
limitation of the Webkit module, not a bug.

> To my opinion, the usage=default clause should select the first report (rml
> or webkit) - one should set only one report as default for a given
> object... the 6.1-patch would allow to have both rml and webkit reports
> working

I'm afraid I disagree, because the 'usage' field is deprecated and not meant to
be used for this. It would also be very complicated for users to find how to
change it and what are the possible values, plus we'd also need an extra
constraint etc. This is much too complicated.

We should simply be using the first report out of the available reports that
the user sees on the document. However this is not exactly how it works right
now, because the order and filtering of the reports is different in the user
interface (the UI display them ordered by ID rather than name, and filtered
according to the user groups).
This requires a more complicated patch including a lookup via ir.values, and is
only suitable for trunk, not in stable versions.. but it seems like the way to
go ultimately.

BTW the webkit reporting engine is added by a separate module, so any reference
to 'webkit' should only appear in the report_webkit module itself or any module
that depends on it, not in the EDI module directly.
So you could either make report_webkit depend on 'edi' (that's a change for
trunk!) or add a glue module 'edi_report_webkit' to adapt the EDI engine when
both are installed. Perhaps that's best discussed with Nicolas Bessi from
Camptocamp, the author of the webkit engine.

I would suggest only creating a merge proposal for trunk, and perhaps creating
a temporary community module (glue) for 6.1 to fix this behavior.

> in 7.0, do you mean that part of code should be removed ?

The EDI export code is not reachable via the UI in 7.0, but it should be reused
in the future when the EDI exports get integrated with the email notifications.
So your patch could still make sense in trunk to care for the future, but in
7.0 it's useless, and users have another way to choose the report that will be
attached to "Send by Email" messages.

On 06/13/2013 12:35 PM, invitu wrote:
> actually, in 6.1, we cannot use both rml and webkit reports with edi...

Yes I understand the problem you describe, but to me this could be seen as a 
limitation of the Webkit module, not a bug.

I'm afraid I disagree, because the 'usage' field is deprecated and not meant to 
be used for this. It would also be very complicated for users to find how to 
change it and what are the possible values, plus we'd also need an extra 
constraint etc. This is much too complicated.

We should simply be using the first report out of the available reports that 
the user sees on the document. However this is not exactly how it works right 
now, because the order and filtering of the reports is different in the user 
interface (the UI display them ordered by ID rather than name, and filtered 
according to the user groups).
This requires a more complicated patch including a lookup via ir.values, and is 
only suitable for trunk, not in stable versions.. but it seems like the way to 
go ultimately.

BTW the webkit reporting engine is added by a separate module, so any reference 
to 'webkit' should only appear in the report_webkit module itself or any module 
that depends on it, not in the EDI module directly.
So you could either make report_webkit depend on 'edi' (that's a change for 
trunk!) or add a glue module 'edi_report_webkit' to adapt the EDI engine when 
both are installed. Perhaps that's best discussed with Nicolas Bessi from 
Camptocamp, the author of the webkit engine.

I would suggest only creating a merge proposal for trunk, and perhaps creating 
a temporary community module (glue) for 6.1 to fix this behavior.

> in 7.0, do you mean that part of code should be removed ?

The EDI export code is not reachable via the UI in 7.0, but it should be reused 
in the future when the EDI exports get integrated with the email notifications. 
So your patch could still make sense in trunk to care for the future, but in 
7.0 it's useless, and users have another way to choose the report that will be 
attached to "Send by Email" messages.