Download view produces wrong filename extension using Firefox

[l-emele]

I just filtered something in the table https://openenergy-platform.org/dataedit/view/scenario/ksz2050_r2_ks95_primary_and_final_energy_consumption and then tried the "download view". I got an CSV file with the filename Partial_scenario_ksz2050_r2_ks95_primary_and_final_energy_consumption.csv.txt. As it is a valid CSV file, it the filename extension should be imho only .csv and not .csv.txt.

[jh-RLI]

Hi @l-emele, can you please provide a screenshot of your filter settings. I was not able to reproduce your error.

[l-emele]

It is independent of the filter settings. However, here is an example:

But maybe, my browser (Firefox 91.7.0esr (64-Bit)) adds this additional extension while downloading?

When clicking on the "Download CSV" button, Firefox seems to see this file as valid CSV and shows to open in MS Excel which is my system's default for CSV files.

When clicking on the "Download View" button, Firefox does not recognise this as valid CSV but as text file instead and therefore shows to open in the default text editor. Maybe it adds therefore an additional .txt file extension.

Does the OEP deliver for both downloads the same MIME type?

Also I noticed that the structure of the downloaded CSV files differ slightly. In the file from the "Download CSV" button, the entries in the id column are in quotations marks (showing here only the header and the first tow data rows):

"id","variable","energy_carrier","unit","year","value"
"1","Primary energy consumption","Nuclear","PJ","2020","728.3828459388"
"2","Primary energy consumption","Nuclear","PJ","2030","0.0"

In the partial download via "Download view", the are no quotation marks in this columns:

"id","variable","energy_carrier","unit","year","value"
1,"Primary energy consumption","Nuclear","PJ",2020,"728.3828459388"
2,"Primary energy consumption","Nuclear","PJ",2030,"0.0"

[jh-RLI]

Thanks for this detailed comment. I think your guess is correct, and the ".txt" is appended by Firefox. With Chrome the problem does not exist (at least on my end).

The second point is also a good catch :) . I will create another issue for this.

[l-emele]

Solved with PR #949, so I close this issue.