Locality ID pull/sync does not map to correct field

[sharpphyl]

Describe the bug During single record entry, entering a locality ID to pull/sync brings up the selection pane with the ID in the Locality Name field instead of the Locality ID field.

To Reproduce Steps to reproduce the behavior: Go to single record entry and enter locality_id in the locality_id field and press pull/sync Selection pane appears with the Locality ID in the locality_name field

Screenshots

*Desktop (please complete the following information):**

PC/Chrome

[dustymc]

I'm bringing this back over for discussion. The behavior described is accurate, but there are reasons.

The pick just assumes that locality_name is what's been passed in, which seems reasonable when considering that locality_id can disappear while the pass is happening. There's no anticipation of using an ephemeral ID in the code, there's a stable ID available for use, and I'm not terribly anxious to change any of that. I'm sure locality_id is allowed because someone demanded it, and I suppose that's OK as long as everyone understands what it is and does, but I really don't want to mis-lead anyone who doesn't fully understand the stability associated with locality_id (there is none), and Arctos has a constant stream of new users.

How can we clarify this situation without setting a dangerous trap?

[acdoll]

I think it might have been me that demanded it :). The locality_id is convenient way of linking a new collecting events with an existing locality. I know we can name the localities, but it's often a sort of one-off occurrence that doesn't seem worth assigning a name. This generally comes up with some of the less-than-specific specific_locality like an island or a municipality. Your concerns over peoples' understanding of the ephemeral nature of these ID's is valid; I think I'm the only one here that clearly understood that. But I am also the only one who has noticed these locality_id's values change - that doesn't seem to happen all that often, does it? Personally, I like the simple convenience of using the locality_id for searching/pulling and am willing to, only occasionally, preform a simple locality search if that number has changed for the locality I'm looking for. Phyllis has suggested just naming these with the locality_id when they come across the need. That seems like a practical solution; do you see any issue with that?

[dustymc]

doesn't seem to happen all that often

Depends on the context. Some old unique (often mis-spelled...) or precisely georeferenced locality probably isn't ever going to change, someone loading thousands of identical records will result in thousands of changes, backlogs can make that all weird, etc., etc. Wildly variable.

naming these with the locality_id

That will prevent any subsequent mergers/automation/cleanup - which may be just what you want. (I often wonder if a simpler, flatter locality model wouldn't make everyone happier.) Rock on, but be aware of what you're getting into (I think you are).

There's also a mechanism to name and un-name localities as temp_{locality_id} in bulk, and Arctos will send you reminders when those continue to exist. https://github.com/ArctosDB/arctos/issues/8104#issuecomment-2346934452 is close to the procedure (eg possibly you'd want to periodically un-name in bulk). Maybe a 'generate temp name' option around here....

... would be useful if you want to go that way.

[campmlc]

I'm interested in the idea of "generate temp name". We also need names for Collecting Events to match parasites with hosts, for example. We currently download the host collecting event ID to create a parasite bulkload file with the same shared collecting event, but my understanding is that this is not stable over time, so if it takes awhile to do the parasite bulkload they could diverge, correct? are locality and CE IDs reused? Would temp names be more stable?

[campmlc]

I'm assuming using Pull in data entry to link localities and events for data entry purposes is subject to the same issues?

[dustymc]

interested in the idea of "generate temp name"

It's been there for years, goferit.

not stable over time

Correct - and that time can be measured in milliseconds (or never happen, depending on lots of things).

could diverge

I'm not sure what "diverge" means here, but to be clear: Names do not prevent editing, including in things like deleting the record or removing the name. This all takes some planning, names just let you ignore the administrative stuff and hopefully make everything easy.

are locality and CE IDs reused

No (but pretend they are to be safe!).

Would temp names be more stable?

names that start with temp_ are as stable as you want them to be, they'll just send you 'please clean' notifications. They work exactly like any other names, except for the aforementioned notifications and some magic in generating them.

same issues

Data entry is the subject of this issue.

Do note that the 'pull' part does nothing; it's just for humans, providing a name or ID with or without accompanying data (which is ignored when the ID is given) results in exactly the same behavior.

I think this is all documented, but please let me know if that could be better and I'll try to find time to work on it.