Request - automagic .csv file for barcode swapper from container contents

[happiah-madson]

Help us understand your request (check below):

• search or data request (help with SQL or provide the specific fields you are trying to retrieve for your collection)
• add a new Github user to the Arctos Users team
• a new barcode series
• a new term for data entry or management
• a change or new report or label
• update to an Agent (split, merge, or other type of change)
• bulkload changes (to Agents, Identifiers, etc that are not already available as a bulkloading tool)
• new feature or otherwise a good idea to make Arctos even better
• quarantine taxon name and suggested replacement (please supply links)
• other

Describe what you're trying to do
In the last object tracking meeting (https://docs.google.com/document/d/1on0bbE7Z21YycA0CDeuyDmky96GW72ZcxpeMga29h2Y/edit?tab=t.0#heading=h.n39160yuawro), @Jegelewicz, @campmlc, and I wrote a updated, more generalized protocol for switching barcodes (https://docs.google.com/document/d/1k7bKUgGj8CudsUhVSbLwfuiv2sQL9-VAmz8b8ATOEiE/edit?tab=t.0#heading=h.nzafxxkwvug).

As the function of this work, we are requesting the following of @dustymc:
Please, would you make us an automated .csv file download for the barcode swapper tool from the Container Contents view? That way a user could search Container: Find (https://arctos.database.museum/findContainer.cfm) for a box that they are going to relabel, click on container contents (i.e., https://arctos.database.museum/info/container_contents.cfm?container_id=22957332), and then download the information needed for the barcode swapper tool. As there are many container levels present in the container contents view, a user would need to declare the level they want downloaded (i.e., 3, 4, etc.). We would like the downloaded .csv file to include BCx, LBLx, Tx, CIDx, and Institutional_acronym in this order so that it matches the view in container contents.

By extension, then, we think the barcode swapper tool should ask for BCx, LBLx, Tx, CIDx, and Institutional_acronym. Then you (@dustymc) can just use whichever fields you need for swapping magic.

Once a user has the autogenerated .csv file, they would just need to enter the replacement barcode, ideally greatly reducing the possibility of transcription/copy/paste/gremlin errors.

[dustymc]

This tool should only ever be used in outlier-ish situations, and has the potential to be absolutely catastrophic if even slightly misused, so I question the value (esp. vs. risk) of any development.

file to include BCx, LBLx, Tx, CIDx,

Very related to #8110 - I'd not be comfortable with this dangerous tool having cryptic headers, which suggests I probably shouldn't be comfortable with those cryptic headers existing at all. (They exist to crunch up the UI - tiny benefit vs huge cost??)

transcription/copy/paste/gremlin errors

I'm always happy to help pull data.

[happiah-madson]

which suggests I probably shouldn't be comfortable with those cryptic headers existing at all

!!!!!

I'm always happy to help pull data.

And I appreciate that! One of the concerns is that if we do pull data, we have to rearrange the columns to match the barcode swapper tool. That seems bad. Same order seems better.

[campmlc]

We don't need the cryptic headers expanded if we can get a "key" to the headers at the top of the page with the summary info.
And I agree with @happiah-madson that not having the columns in consistent order between the display/download and the tool is a problem. Any time we have to rearrange data to match a different tool we introduce error. We are asking for consistency that should be standard across all Arctos tools. But let's start here, please. This is needed across two collections, at least one for a major grant-funded project (MSB) that will involve barcode swaps for 4 freezers worth of cryovials..

[happiah-madson]

And while we are not as big as MSB, we do need to swap barcodes on probably err, 30,000 things?

[campmlc]

Because this isn't a one-off situation, we need modifications to this existing tool so that we do not have to submit a SQL download request every time.

[Jegelewicz]

This is NOT a one-off tool. It will be useful for all kinds of situations and it might as well be set up to help reduce the number of errors. I also don't think it is collection specific. There are at least two potential "heavy" users and I don't think that will be the end of it.

[campmlc]

This is only collection-specific if you include all genomics collections or anyone who uses object tracking. I also disagree with this label and with the assumption this is a one off tool. This is really a simple request that will drastically reduce the probability of error in an already complex process. Can we please make this happen? @mkoo

[campmlc]

Note we use this tool on a regular basis - if it is so dangerous, then that is an even better reason for the download to match the tool upload columns, and for there to be an autofilled download file as already exists for identifier bulkloads and edits, among others.

[happiah-madson]

Because some things for Genomic Collections are on hold until we get some DwC archive directioning, I'm going to use today's Genomic Resource Working Group meeting to address object tracking things (because overlap == high) and specifically this issue as it's causing a real hold up for my collection. @mkoo @dustymc @Jegelewicz @campmlc

[campmlc]

Be a few min late Mariel Campbell Senior Collection Manager Division of Genomic Resources Museum of Southwestern Biology University of New Mexico Albuquerque NM 87131 ***@***.***

…

________________________________ From: Hannah Appiah-Madson ***@***.***> Sent: Friday, January 10, 2025 8:30:16 AM To: ArctosDB/arctos ***@***.***> Cc: Mariel Campbell ***@***.***>; Mention ***@***.***> Subject: Re: [ArctosDB/arctos] Request - automagic .csv file for barcode swapper from container contents (Issue #8333) [EXTERNAL] Because some things for Genomic Collections are on hold until we get some DwC archive directioning, I'm going to use today's Genomic Resource Working Group meeting to address object tracking things (because overlap == high) and specifically this issue as it's causing a real hold up for my collection. @mkoo<https://github.com/mkoo> @dustymc<https://github.com/dustymc> @Jegelewicz<https://github.com/Jegelewicz> @campmlc<https://github.com/campmlc> — Reply to this email directly, view it on GitHub<#8333 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADQ7JBEBS5YWFABOGHZ2IXT2J7RQRAVCNFSM6AAAAABSOPHCLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBSHE3DKMRXHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dustymc]

causing a real hold up for my collection

This is surprising to me, and why we encourage requesting solutions to functional needs rather than specific pathways.

I don't think what's requested would be safe. That doesn't mean it can't happen - I've put a tremendous amount of work into not accidentally becoming the DickTater of Arctos over the years, we have an administrative arm with a Director now and I'll do what they tell me to, but if it comes to that I'll still expect this to cause problems which I wont be able to help fix. (I think anyone who's spent much time in the error logs would easily agree with that assessment, but I'm clearly biased in that regard.)

That leaves about ∞-1 options to address your need, whatever it is. Possibly we could explore some of those?

[happiah-madson]

Absolutely what I am hoping that we can discuss in 12 minutes!

[dustymc]

Concerns addressed in https://docs.google.com/document/d/1on0bbE7Z21YycA0CDeuyDmky96GW72ZcxpeMga29h2Y/edit?tab=t.0 with @mkoo @happiah-madson @campmlc @Jegelewicz there's a series of dev issues, recommend closing this BUT consider new issue(s) to standardize CSV headers across tools (per some side-comments above).

[happiah-madson]

Cannot love this update enough.

[happiah-madson]

BUT consider new issue(s) to standardize CSV headers across tools (per some side-comments above).

This is a next week problem, but I'll put it back on the top of my list

[Jegelewicz]

Suggested changes to container tool names here - https://docs.google.com/spreadsheets/d/11HMsrpyyGVmZ8qf-Lk_3YuQ2_eqInJfO3j3f3j5sRdI/edit?usp=sharing

[happiah-madson]

@dustymc what else is blocking this issue from moving forward?

[dustymc]

@happiah-madson a lack of clarity on my part is the current block. I thought there was a fully-fleshed out plan via the 3 chained dev issues above, but since that there are several issues and comments (including this) which seem covered by those but are still getting activity. I can't quite tell if those mean my plan isn't sufficient or something else is broken or they're just inquiries or ????????????? It would be exceptionally useful if any possibly-overlapping issues which are covered by things in dev could be closed, and anything not covered by dev issues could be distilled into actionable functional requests.

[happiah-madson]

Ah, fully missed the 3 dev issues above. ArctosDB/dev#148 does indeed address the item I was trying to get action on in this comment (#8333 (comment)).

My take is that it is ArctosDB/dev#146 that is holding up progress on ArctosDB/dev#148 so I will close this issue and move the conversation over there.