[7.0] Wrong binary fields representation in o2m list views and unnecessary preloading

[Enrico Ganzaroli]

In list views, binary fields anchors are filled with "data:application/octet-stream;base64,<base64_encoded_file_contents>".

I think the proper representation should be a link to download the file as in form view.

This seems related to this bug (marked as fixed in version 6.1): https://bugs.launchpad.net/openerp-web/+bug/914267

-- edit stefan -- This also implies that the binary contents are preloaded every time that the view is loaded.

[Amit Bhavsar (Open ERP) (amb-openerp)]

Hello Enrico,

I have tested your Issue with latest (trunk/7.0) revision. and It's seems fine as per your expectation. That's why I have attached the screen capture for you reference. would you please check It and notify us if something is wrong in this part.

Thanks and waiting for your reply!

[Enrico Ganzaroli (enrico-gz)]

And you are perfectly right!

Sorry, I didn't tested the issue in normal list views.

In fact, I'm able to reproduce the problem only for the list view produced by a one2many field.

I have attached the screen capture for you reference.

Thanks.

[Amit Bhavsar (Open ERP) (amb-openerp)]

Hello Enrics

I have checked It again. and same result for one2many list. So I have attached the screen capture for your reference. please give look.

Sorry, But I am not able to understand sentiment.
would you please elaborate more your scenario and describe your expected behavior.

Thanks and waiting for your reply!

[Enrico Ganzaroli (enrico-gz)]

Hello Amit,
if you look at the HTML produced for the anchor, you'll see something like

<a href="http://debian-vm:40069/web/binary/saveas?model=identity.document&amp;field=file&amp;id=5&amp;session_id=cea8a7170da049b0a474c52fa0b0091d&amp;filename_field=file_name">Download "Doc 1MB Document.pdf"</a>

for the normal list view and something like

<a href="data:application/octet-stream;base64,JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAErVAhUKFQwtFAwMVQwNbVUMLcwVihKVQhXyFPQD0gtSk4tKClNzFEoygSqAskbACGIBuowNDVWSM5V0PfMNVRwyecKVAgEAPLeEyAKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjc3CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL1hPYmplY3QgPDwgL0ltMSA3IDAgUiA...........">Download "Doc 1MB Document.pdf"</a>

for the one2many list: in my case that was a base64 string more than 1MB in size!!

Thanks for you attention.

[Amit Bhavsar (Open ERP) (amb-openerp)]

Oooh Yeah Enrics,

It's placed at bottom. :)

we should Improved this things.

Thanks!

[Enrico Ganzaroli (enrico-gz)]

In the file "addons/web/static/src/js/data.js", function "read_ids" is called without the "options" parameter. This parameter contains exactly what is missing: {context: {'bin_size':true}, ...}.

The following patch seems to fix the problem:

addons/web/static/src/js/data.js, line 639:

- return this.read_ids(this.ids.slice(offset, end_pos), fields);
+ return this.read_ids(this.ids.slice(offset, end_pos), fields, options);

Hope this helps.

[Cedric Le Brouster(OpenFire) (cedric-lebrouster)]

Hello Enrico,

I tried your patch for a custom modules and I didn't notice any change.
I solved it with the attached patch.

If I understand well, the binary files are already downloaded at view loading.
So a test was made to insert the file in the html code to prevent asking multiple times the download of the same file.
The problem is file names are not applied, and from what I read there are no reliable ways to do this with data:application/octet-stream.
And the other problem you pointed out is that all this data in html page may slow down its loading

I just disabled the test that puts data in html file.
This solves the above problems, but I think it's strange to download whole binary files at view loadings, as all data you need are the file name and its size.

[Stefan Rijnhart (Opener) (stefan-opener)]

Thanks Enrico and Cedric! I found that I had to combine both your solutions and add a change to actually get the context to the server side to fix this issue. See the merge proposal.

[Leonardo Donelli (learts92)]

This is still present in upstream. Unbelieavable.