Comment 1 for bug 844569

Please, don't report 4 different issues in the same bug, it's very unwieldy.

> opening an export in Excel ( I tried assets) provides numbers as characters makeing the export not very useful for further processing

The web client can't really do anything about that, short of reprocessing each and every field: the export_data API currently returns lists of strings, instead of lists of the correct representation for the field. If this is fixed, the Excel export will automatically behave as expected: the excel export just uses xlwt.Worksheet.write with (almost) no preparation, and xlwt handles its own conversions from native Python datatypes to sensible Excel representations.

> IMHO export to CSV MUST at least allow to set /overwrite decimal separator !!!

Things would be a bit more complex than that, this may require adding variability for the separator as well for instance. I also don't think this is supported by Python's CSV *API* (as far as I can tell, csv.Dialect provides option for changing the fields delimiter or the quoting character, but not the formatting of non-string types). But feel free to open a feature request for that.

> 2) IMHO Default Export Type should be "all data"

I'm pretty sure this conversation already happened with the old web client and the GTK client, and fp rejected it then. With the new import/export, we considered removing import_compatible altogether but fp rejected the proposal, considering that they fit different flows (export for import, and export for stats analysis) and that the default should remain import compatible (wording may change to make these roles clearer, but you get the point).

If you think you can marshall enough arguments to try and sway him, feel free to bring this up on e.g. the mailing lists or in private conversations with him (opening new bugs without sufficient arguments will likely yield the same answer as this one: that fp has decided to keep things as is)

> 3) export Type "Import compatible" only shows ID ??

Yes, in order to try and simplify the export system we've decided on the following changes to the export:
* external ids (xmlid, formerly id field) are always exported, they're added by default on the main object and selecting a relational field (not its subfields but the field itself) will export its external id instead of its name_get (or whatever it used to be). This results in removing the children of m2m and m2o fields in import_compatible
* database ids (formerly .id) have been renamed to ID, and can be exported explicitly if the user so desires.

I hope these answers are satisfactory, I can't help more than that with the main gist of the bug so I'll close it as wontfix (we can't fix it in the web client, and most of the description would be irrelevant to the server).

https://secure.simplistix.co.uk/svn/xlwt/trunk/xlwt/doc/xlwt.html#xlwt.Worksheet.write-method