wizard saving to an file not being downloaded correctly by the web client

Bug #591102 reported by SeanBoran
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Odoo Web Client
Fix Released
High
Sananaz (Open ERP)

Bug Description

I use pyExcelerator to save some data to an excel file in a wizard and send it to the client.
The idea is that the client should present a dialog to the user allowing the file to be downloaded.

Code snippet:
   file=StringIO.StringIO()
      out=mydoc.save(file)
      return {'data': base64.encodestring(file.getvalue()) , 'file_name': filename}
...
<?xml version="1.0"?>
<form string="Export">
    <image name="gtk-dialog-info" colspan="2"/>
    <group colspan="2" col="4">
        <separator string="Export to Excel" colspan="4"/>
        <field name="data" readonly="1" colspan="3" filename="file_name" />
        <label align="0.0" string="Save this document to a .XLS file and open it with\n Excel." colspan="4"/>
    </group>
</form>
..
    fields_finish={
        'data': {'string':'File', 'type':'binary', 'readonly': True,},
        'file_name':{'string':'File Name', 'type':'char'}
    }

In fact a dialog is present to the user which shows "File:", then the encoded file text (e.g. 0M8R4KGxGuEAAAAAAAA...), and way off to the right "SaveAs" and "Change".
This does not happen with the GTK GUI.

Version: I've tried with bzr from last week and 5.0.10 tarball, same result.
Os is ubuntu 8.04 with python 2.5.2

There is a tricky catch:
- I've tried this on 3 different servers, on one old Ubuntu 8..04 it works just fine (not encoded text shown, just the file download), on the other two (8.04 fresh install and 9.10) it exhibits the behaviour above.

There is a more complete description, also with rpc traces on:
http://www.openobject.com/forum/post57109.html#57109

Related branches

Revision history for this message
Borja López Soilán (NeoPolus) (borjals) wrote :

We have experienced this problem too when using the jasper_reports module. The wizard that generates the datasource template works all-right on the GTK client (returns the XML file), but on the web client it just shows up the data from the file on the page (causing havoc). That is, instead of a widget with download/upload buttons and such, the contents of the file are inserted on the HTML.

Revision history for this message
Borja López Soilán (NeoPolus) (borjals) wrote :

BTW we are using the 5.0.10 web client over Ubuntu 8.10.

Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :

Dear all, could you give the patch attached in bug #530446 a try and, provided it fixes your issue, report on both bug reports?

Revision history for this message
Christophe CHAUVET (christophe-chauvet) wrote :

Hi

I confirm, i hhave the same problem, the field binary display the base64 data instead of the size of the file (checked with the GTK Client)

test with 5.0.11

Regards,

Changed in openobject-client-web:
status: New → Confirmed
importance: Undecided → High
milestone: none → 5.0.12
Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :

Dear all.

Please apply the following patch to solve this problem.

To whoever is responsible of the OpenERP Web Client: I'm fully aware that this patch does not solve the underlying bug but rather provides a somewhat nicer workaround than the existing one.

Regards.

Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :
Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :
Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :
Revision history for this message
Borja López Soilán (NeoPolus) (borjals) wrote :

Good job Benoit, a workaround is always better that no solution :)

Revision history for this message
Niels Huylebroeck (red15) wrote :

Benoit, can you try changing the code and see what kind of exception is thrown in the original try: except statement ?

I think the code would be better if it would catch that specific exception maybe ?
And really am curious about output of the stack trace can you paste it if you have 2 minutes ?

Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :

็็Hi. Nothing fancy here.

In the context of a wizard, 'value' contains the base64()ed content of the file. Otherwise it contains the size in bytes of the binary field.

tools.get_size() does simple arithmetic to convert a size in bytes to a human readable size.

No wonder it fails with wizards and falls back to displaying "what it can".

Revision history for this message
asdferfasdfasp9f7as98df (benoit.m-deactivatedaccount) wrote :

BTW, I use len() on the base64()ed content of the file. In other words, the size displayed is about 140% larger than the size of the actual file.

Revision history for this message
SeanBoran (sean-boran) wrote :

@Benoit
#3: that patch is included in 5.0.11 an does not help

#6: this patch __does__ work (tested on 5.0.11). Good work.

(Sorry for the slow response, but I've not found a way of being notified when they are replies to LP bugs I've submitted, so I have to remember to poll)

Revision history for this message
Sananaz (Open ERP) (sma-tiny) wrote :

Hello Sean,

It has been fixed in stable by revision 2876 <email address hidden>.
When calling wizard, 'value' contains the base64() content of the file.
So we need to check its size. So no need to go with the try..except block.

Thank you for notifying.

Changed in openobject-client-web:
assignee: nobody → sma (Open ERP) (sma-tiny)
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.