#88 - Catalogue/CPF field-type changing
-
By Chris Graham
- Added
- 18 views
| Identifier | #88 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Catalogue/CPF field-type changing |
| Status | Closed (rejected) |
| Handling member | Chris Graham |
| Addon | core |
| Description | The ability to edit the field types used in an existing catalogue.
There are three problems with this: * types for existing data may no longer be correct (e.g. a text field converted to an integer field may result in invalid data) * a lot of moving in/out of the translate table would need doing * and the above that would squash away internationalisations of strings in some cases (although we don't support it anymore, I don't want to break the internal support) I propose a resolution system be added to fix the first problem, extra code for the second problem (there's no choice - the code'd be needed), and the third problem merely documented as existing. The resolution system would be two phase: * the first would allow the definition of automated remaps (e.g. yes -> 1, no -> 0, Yes -> 1, No -> 1) * the second would provide edit boxes for all fields that could not automatically be fixed |
| Steps to reproduce | |
| Related to | |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
So documented a workaround instead, that works equally as easily as a new inbuilt UI resolver would:
"You cannot change field data types after you have created them (except between field types that have the same "storage" type) as this would affect the integrity of any data that may have already been entered into them. A workaround is to export to CSV, delete the field, create a new field with the same name and the new type, and reimport the CSV."
Essentially it means we switch creating our own resolution interface, to suggesting people do it themselves in Excel.