Bug #6756
CSV import: levelOfDetail values that do not conform to current taxonomy cause import failure
| Status: | Verified | Start date: | 05/27/2014 | |
|---|---|---|---|---|
| Priority: | Medium | Due date: | ||
| Assignee: | Dan Gillean | % Done: | 0% | |
| Category: | CSV import | |||
| Target version: | Release 2.2.0 | |||
| Google Code Legacy ID: | Tested version: | 2.1, 2.2 | ||
| Sponsored: | No | Requires documentation: |
Description
To reproduce:
1. Import a CSV file with a value in levelOfDetail which is not currently in Description Details Levels taxonomy. Import will fail.
2. Update the taxonomy to include this term.
2a. First attempt to import same CSV resulted in 500 server error (perhaps term was still being indexed?)
2b. Second attempt to import same CSV was successful.
Related issues
History
#1 Updated by Dan Gillean almost 8 years ago
- Category changed from Import/Export to CSV import
#2 Updated by Sarah Romkey almost 8 years ago
- Category changed from CSV import to Import/Export
I deleted my fake data from 2x for testing purposes.
#3 Updated by Sarah Romkey almost 8 years ago
- Category changed from Import/Export to CSV import
#4 Updated by Jesús García Crespo over 7 years ago
- Target version changed from Release 2.1.0 to Release 2.2.0
#5 Updated by Mike Gale over 7 years ago
- Status changed from New to Code Review
- Assignee changed from Mike Gale to Mike Cantelon
Please see here: https://github.com/artefactual/atom/commit/da1b8bdc88a308af684e42f866a5b6f7c0c03b5d
I accidentally based that branch off a different topic branch so I didn't make a PR. If this code is OK I can cherry pick it.
Thanks Mike!
#6 Updated by Dan Gillean over 7 years ago
- Requires documentation set to Yes
There is a warning in the documentation that needs to be removed here: https://accesstomemory.org/en/docs/2.1/user-manual/import-export/csv-import/#other-data-entry-notes
#7 Updated by Mike Cantelon over 7 years ago
Mike Gale wrote:
Please see here: https://github.com/artefactual/atom/commit/da1b8bdc88a308af684e42f866a5b6f7c0c03b5d
I accidentally based that branch off a different topic branch so I didn't make a PR. If this code is OK I can cherry pick it.Thanks Mike!
This looks good to me!
#8 Updated by Mike Cantelon over 7 years ago
- Status changed from Code Review to Feedback
- Assignee changed from Mike Cantelon to Mike Gale
#9 Updated by Mike Gale over 7 years ago
- Status changed from Feedback to QA/Review
- Assignee changed from Mike Gale to Dan Gillean
#10 Updated by Mike Gale over 7 years ago
merged into qa/2.2.x
#11 Updated by Dan Gillean about 7 years ago
- Status changed from QA/Review to Feedback
- Assignee changed from Dan Gillean to Mike Gale
- Tested version 2.1, 2.2 added
Works - mostly. New terms will be created when not present. However, this is case sensitive - so "full" will create a new term, instead of linking to the existing term, "Full". Since I tested #6758 with Final and final and had no issue, I think we should be consistent in how we implement these fixes and try to do the same here, so that case will not matter - e.g. FULL, Full, full, FuLL, etc should all map to the existing term, "Full" when imported. If no match is found, the ability to create new terms (rather than crash the import) should continue to function.
#12 Updated by Mike Gale about 7 years ago
- Status changed from Feedback to QA/Review
- Assignee changed from Mike Gale to Dan Gillean
levelOfDetail should now be case insensitive (e.g. 'FULL' -> links to 'Full'). I also did this while I was in there for physicalObjectType (BOX -> Box). I couldn't find any other cases at a glance where case insensitivity would be desired but we weren't doing that.
#13 Updated by Dan Gillean about 7 years ago
- Status changed from QA/Review to Verified
worked with a new term, and with many different casings of an existing term.
#14 Updated by Dan Gillean about 7 years ago
- Requires documentation deleted (
Yes)
Warning in docs removed.