Open bronwyncombs opened 6 months ago
edit: I read the message from the CSIRO again, and seems like they are asking about the ID field specifically - all other fields can be unhidden
the ID field is not exposed in the schema config, so we can't use schema config for unhiding it. we could either extend the schema config, OR add a user pref for this (adding user pref is simple, but might not be the best long term)
Both Soraya @ NMBE and Robyn @ RBGE also request adding the ability to unhide ID fields in the schema and successfully map to them in the WorkBench. This is for the same reason of preventing unnecessary duplicate records during data import.
Requested via discourse post
Soraya:
Hi. Some users would like to use the Locality ID (the hidden value) instead of the Locality name when importing collection objects with the workbench, to make sure that, when the locality already exists in the database, no spurious new locality records are created because of a small, unintentional difference in any of the fields (e.g. a mistake in the name or an extra point). and entered a valid LocalityID in the field, but the validation gives this error:
Would it be possible to use these hidden IDs in the workbench?
Robyn:
Hi Soraya,
I’ve been making use of the GUID when mapping datasets, as we were having the same issue of localities and agents not matching. I had initially looked at using the ID for these fields, but switched to the GUID when I found it couldn’t be mapped.
This issue has been mentioned on Specify Community Forum. There might be relevant details there:
https://discourse.specifysoftware.org/t/using-the-unique-hidden-ids-in-workbench-import/1839/6
Is your feature request related to a problem? Please describe.
You can't add hidden fields to the query builder mapper even when the field is added to the forms. This means an extra step to click the "reveal hidden fields" box is necessary for the users despite the field being on the form.
From Zoe:
Reported By CSIRO