Allow for permanently unhiding ID fields to query mapper list

[bronwyncombs]

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:

Hi,
I would like to 'unhide' collectingEventID, so it's available in the query builder for users (so they don't have to tick 'show hidden fields' to find it).
This is so they can easily identify and map to the relevant ID when using workbench to create Collection Objects that need to be linked to existing Collecting Events.
I have added the ID as a read-only field to the front-end form, but I can't see it listed in the schema configuration tool to untick 'Hide Field' - is there a way to unhide system-generated ID fields?
Thanks

Reported By
CSIRO

[maxpatiiuk]

Outdated

If you need field both on the form and in the query builder, then why is it a hidden field? It should be unhidden.
Or do they need it for security/permissions? In which case, extending the permissions system to allow setting field-level permissions would be the way - #2092 (and a FYI, back-end already has field-level permissions support, and now we just need a UI for this)

can you please clarify?

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)

[bronwyncombs]

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.

[specifysoftware]

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