[6.1] EDI exports do not support webkit reports in addition to RML ones

Hello,

RD team would you please check edi with webkit report.

Thanks

Hi,

This does not look like a bug to me, more like a wishlist. Note that the provided patches would cause a change in stable branches that could create an unpredictable behavior: depending on the names of the reports, the one attached to the EDI documents would be different. We would at least need to order that search() by 'report_type, name', so that it does not change the current behavior for users who have both Webkit and RML reports.

As for 7.0 the EDI export is not performed automatically anymore because the workflow goes through an explicit "Send by email" step, and the attached report is determined by the email.template that is used. This actually makes it user-configurable automatically, so no patch is needed for that part.

Thanks!

BTW, creating ocb-addons merge proposals but only providing patches for the official branches is a strange move. I end up reviewing your patches in bug comments.

hello
actually, in 6.1, we cannot use both rml and webkit reports with edi... 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

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

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.

@olivier thank you for sharing your insights! @invitu providing proposals for ocb projects only is indeed against the backports' policy.

@olivier, sorry I did not know I could do merge proposal on openobject projects, now I do

Hello,

That's true that report webkit is an additional addon but it also an official addons and we have already some trace of it in RNG of server.

That said, I agree with Olivier that it would be better to keep webkit report encapsulated when possible and it is probably a better solution to have a glue module that's does auto installation. But to accept this approach it means the new module becomes an official addon in trunk.

Now I see a problem in term of desing with the EDI, (but i'm not familiar with it so correct me if I'm wrong). It is a common point to have many reports on a model so beeing able to choose which report we want to use is a good think even if the usage fields is not really meaningful taking the first report in the list will be a real desing error, you do not want to send internal report to customer.

An other point is that with the OpenERP XML behavior you can replace any RML report by an webkit one or any other one. For me the filter on the report type is not revelant an can prevent any report to be sent. Also why EDI should only generate PDF.

I think a good idea for V 7.0 would be to add a hook function on EDI model like _get_report_id that has a default behavior and return a report id.

That way at least it will be easy to have a custom function to retrieve report on any edi model (by XML ID, by name etc), and it will be easy to add a glue module. I will also remove the pdf filter (but there is may be a good reason to hve this filter I missed).

Regards

Nicolas