Bug 489937 - Default save to .csv truncates data to what is shown on-screen
Default save to .csv truncates data to what is shown on-screen
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Caolan McNamara
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-03-12 11:48 EDT by Manuel Morales
Modified: 2009-06-08 11:28 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-08 11:28:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 3687 None None None Never
OpenOffice.org 4925 None None None Never
OpenOffice.org 68636 None None None Never

  None (edit)
Description Manuel Morales 2009-03-12 11:48:17 EDT
Description of problem: 
When saving a file to .csv in oocalc, the default behavior is to "Save cell content as shown". The effect is to truncate numeric values to their displayed values. This seriously limits the utility of oocalc for scientific/statistical applications where .csv files are a standard for data exchange.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Type 1.11111 in a cell
2. Save as test.csv
3. Re-open file -> number is converted to 1.11
Actual results:
To maintain data integrity, it is necessary (always) to select File->Save As, then check the "Edit filter settings" option, and finally deselect the "Save cell content as shown" option.

Expected results:
Have the "Save cell content as shown option" unselected as the default, or allow it to be a user-selectable default.

Additional info:
I have set the severity of this bug to high because the practical consequence of the current default behavior is data loss/corruption.
Comment 1 Caolan McNamara 2009-03-12 12:29:04 EDT
Someone gets screwed either way, either you get what you see on screen, which is what you don't want in this case, or you don't get what you see on screen, which screws someone else


Maybe the best thing is to simply make the chosen setting persistent, so once set they stay stuck
Comment 2 Manuel Morales 2009-03-12 17:20:40 EDT
Making the change persistent is fine. However, I still think the default should be changed. The example given in the spec describes the following justification for having the current default (i.e., Save cell content as shown):

"a currency value, $910.00 is saved as simply 910 (more serious; [because] it has become a simple number/integer."

Nevertheless, this change doesn't affect the *value*, just the formatting and the original format can be restored. In contrast, truncating 1.23456789 to 1.23 permanently corrupts the data. It can not be restored once the program has been closed.
Comment 3 Matěj Cepl 2009-05-12 15:29:24 EDT
There is nothing to triage here, developers are apparently working on the bug already.
Comment 4 Caolan McNamara 2009-05-12 17:44:22 EDT
Its debatable whether is really is a "bug" as it works by design. Though a better design is called for. I'm in two minds as whether to close it as upstream, or direct effort towards helping the upstream effort through to 3.2
Comment 5 Caolan McNamara 2009-06-08 11:28:07 EDT
got to be honest here, not going to get the time to do it myself, so punting to the upstream issue which is targeted for 3.2

Note You need to log in before you can comment on or make changes to this bug.