Imported text fields with values consisting of digits gets treated as an actual number

[seav]

Steps to reproduce the error

1. Create a new project with the following questionnaire: numeric_text_questionnaire.xlsx
2. Import the following data file (select just the "Party" import type): numeric_test_import.xlsx
3. Go to the Parties tab and view the Individual party and the Corporation party

Actual behavior

The National Id Number, Mobile Number, and Tax ID fields, which are text fields, have decimal places (".0").

Expected behavior

There shouldn't any be decimal places.

Notes

• This is pretty weird, actually. If you look at the import XLSX file, the cells containing those values are treated as text. The import file is actually just an export file based from data entered via the UI.

[dpalomino]

Wow, it is weird yes. Because in the questionnaire these fields are also texts. Any idea why is this happening?

@SteadyCadence, have you seen something like that before when importing data?

[dpalomino]

I am assigning a high priority because I think this could complicate the import of data....

[SteadyCadence]

This issue sounds a lot like https://github.com/Cadasta/cadasta-platform/issues/1231

[SteadyCadence]

I havent had any issues with it, but I am will be using the API for big imports...

[SteadyCadence]

I think its more of an excel issue because when I convert the import file to csv those numbers are converted to integers. They are not wrapped in strings.

[oliverroick]

This issue is caused by a library we're using to read spreadsheets. It automatically converts any string that is a number to a float. This only affects imports, not the web site, not the API. If you provide something that isn't a number it is treated as text. So it doesn't complicate import of data, the information just isn't represented correctly.

Question: Is this really a high priority? This has been around for a while now and people didn't seem too bothered by it. When you define a field as text, you would expect an alpha-numeric input. The social security numbers and tax IDs I had in my life (in three countries) never were just numbers. It's likely that we never run into these problems in a real world scenario.

[SteadyCadence]

@dpalomino @oliverroick I don't think it is a high priority. With the partners I am working with, we can work around those issues.

[dpalomino]

Hi @oliverroick @SteadyCadence

Well, I think the main problem would be with phone numbers. We can certainly workaround that but, it complicates the import process (and likely prevent a regular partner to import phone numbers by their own). Not a blocking issue of course, but I think it'd be useful to solve. Re-prio to medium.