cloning into the bulkloader moves other ID #1 into other ID #2

[DerekSikes]

No description provided.

[dustymc]

Need more info - URL, screenshots, pathway to reproduce - I'm not sure what you're talking about.

[DerekSikes]

I don't have much more than this and I'm not 100% sure on all the details. I found in the bulkloader a bunch of records that had been cloned into the BL by one of my techs. These records all had empty Other ID #1 and other ID type fields and the data I expected to be in those fields was in the Other ID #2 and Other ID type 2 fields. Perhaps related to this problem, but specifics are still vague, I found in the bulkloader a small subset of records (4 out of hundreds) that had identical values in both fields (which prevented them from loading). In my lab we only use Other ID #1 for these recent projects so something went wrong. I can't totally eliminate human error because I haven't tried to replicate this but I highly doubt it's my lab techs typing in the wrong field (esp with those cloned records - to do that one would have to clone into the BL then go and edit each record in the BL to empty other ID #1 and move the data into Other ID #2 so that seems highly unlikely.

[dustymc]

Do you know HOW - which tool/button/form - they were cloned?

[DerekSikes]

There are two buttons to clone, one makes an immediate and full copy in Arctos and the other makes a clone (or specified # of clones) in the bulkloader that are not full copies. The latter button was used.

[dustymc]

AH - from the OtherID tab of a specimen record, correct?

[dustymc]

If that is the correct form, ID_1 is reserved for the GUID of the source record when a reference type is chosen. If there's nothing in ID1, the user did not select anything in the "relationship (id_references in bulkloader) to this record" field.

ID_5 is reserved for the user's selected "my other ID type."

2,3,4 are other random IDs from the "seed" record, and if that's not sufficient the rest will appear in LOADED as "too many IDs: #ids#"

[DerekSikes]

AH - from the OtherID tab of a specimen record, correct? - YES

And from what you wrote I think I understand this to be another case of clone-failure. Users expect clones to be copies - this violates that expectation worse than the various other ways this method fails (eg not copying multiple sci_name IDs, loan history, etc). We expect these Other ID #s to be copied so they occur in the same field they started in. Can you think of a fix that follows best practice of having the action do what users expect it will? A copy should be a copy not a mutant.

[dustymc]

I don't think I'm following, although I am getting the idea that we need better terminology. "Seed a new record from this one"?

"Option One" can handle all that stuff - the specimen bulkloader simply does not have the structure to handle loans and such.

There is no "same field" - otherIDs are normalized in Arctos and denormalized in the bulkloader, and I can have no idea where some existing ID came from.

Can you explain what you're trying to accomplish?

[DerekSikes]

I'm trying to make a new record in the bulkloader that is just like the old record in Arctos from which it was cloned. In this case I expect the data in the other ID #1 field to be retained in the other ID #1 field.

[dustymc]

There is no #1 field in Arctos; the structure you are referring to does not and can not exist.

[DerekSikes]

So what is this field? It looks like there is a field called other ID #1 - what are users supposed to think? Please clarify.

[dustymc]

There is no #1 in "Arctos Proper" - all IDs are the same "rank" or "order" in the structured data (and there can be many of them).

The bulkloader (unstructured) has a finite number of IDs (and one of them is tied to special handling).

Together, that means that "cloning" may miss stuff - there's not room in the bulkloader for what might be in "real data."

"Cloning" (optionally) creates a new ID, and I need a predictable place to put it from the limited options in the bulkloader. It makes sense to me that the thing being created should be most visible, but I suppose I could move it to #s 2 3 or 4 too.