Feature Request - container history in parts and loans

[dustymc]

Is your feature request related to a problem? Please describe.

• https://github.com/ArctosDB/arctos/issues/5815 is now saving better container history.
• it's been requested to see that (or presumably some of it) in guid page parts and review loans
• How? What's necessary, where to put it, how to format it, ????? Describe what you're trying to accomplish

Provide container history where it's needed in a useful way

Describe the solution you'd like

@DerekSikes and anyone else interested, tell me what you want to see, and where.

Describe alternatives you've considered

n/a

Additional context

Example of "full-view" history:

Priority

unknown

[msbparasites]

instead of all or nothing (or having to go into options to change what you see and don't see) is there a way to have an "expand" option? So if I have 3 vials and 2 slides, and I want to know where are the slides are, I can only click/expand for the slide and it will show tree?

[campmlc]

I would like to request some edits on this form. We need to adjust the width and position of the columns so that the stack column is wider and more visible. Currently on my laptop, this is what I see, which means I can barely see the stack column, which is the critical info along with last_date and barcode. 1) "Positions hold container type" can be made a narrower column width.
2) The stack column should be moved to the left of last update tool, W-H-L, R-C orientation, and positions_hold_container type columns. 3) Container remarks should be moved just to the right of the stack column. 4) In general, any column that can be made narrower to reduce white space and allow for expansion of the stack column should be made narrower.

[dustymc]

narrower

How? And most anything other than somehow using fewer characters is probably incompatible with sorting (which may be inappropriate here anyway??).

should be moved

Just give me an ordered list, please.

allow for expansion of the stack column

We can try, but if you want it forced to some dimension then we're probably just going to have to force it to some dimension.

(And I'm not sure if this is in answer to the original issue or something else???)

[campmlc]

It looks like the width is determined by the width of the column header, so this can be fixed if wide column headers can wrap in the same way that W_H_L and R-C-Orientation wrap. The settings should be adjusted so that column width for fields is no wider than the maximum width of the longest entry in a given column. The stack column needs to be made wider, and columns with a lot of empty space made narrower. This hopefully will reduce the width of the entire table so it can be viewed without having to scroll to the right - similar to what we had with the previous history form. Change font if necessary to make this happen.

Other edits needed: 1) Add current barcode and label to header along with the container ID, eg Current and history data for container ID 20238590 Label DGR17624 Barcode DGR17624 2) Fix chanages in header. 3) Fix column headers so that they remain visible when we scroll down - this is a universal request for all UI in Arctos, and absolutely necessary.

Change to order of columns, left to right: 1) change_date - and please put this in same format as last_date 2) last_date - same format as change_date 3) username - make column narrower 4) Stack - this is the critical info we need to see. Make column wider. 5) parent_container_id - this is really isn't useful to most users in this context, especially since in this case it is referencing the CID of a position. We can leave it here if column width can be narrowed to allow everything else we need to fit in the display. We really need to know which parent container is being referenced in the stack here. And CID is also not visible in Edit Container - so I dont really know why we need it. Alternately, add it to the other forms. 5) container_type- make column narrower 6) label 7) barcode 8) last_update_tool 9) W-H_L 10) R-C_orientation - can we change this to just "positions"? 11) positions_hold_container_type 12) institution acronym 13) description 14) container_remarks 15) print_fg -is this really necessary? what is it, what does it do, why is it here?

If we need to reduce the width of the table further, we can move parent_container ID to the right of last_update tool, into position 9.

Finally, can we have the ability to download as csv?

@DerekSikes @msbparasites @Nicole-Ridgwell-NMMNHS @AJLinn

[campmlc]

And re: sorting - I see no need for that here, especially if we can download as csv.

[DerekSikes]

Minimally I need last scan date (or whatever name that field has now - that is triggered to the current date when a barcode is moved/scanned into a parent). If we could get that added asap and then work out the rest of the above list later, that would be great.

[AJLinn]

Sorry I never responded when you tagged me @campmlc - I rarely use this tool so any changes you make here seem fine for me...

[dustymc]

I don't know how to reconcile this with https://github.com/ArctosDB/arctos/issues/5815 (and the several meetings leading up to it). There is no "field," there's a full history, available from any container or screenshot example above. None of it indicates 'when a barcode is moved/scanned' - I could potentially find that if you mean something like "old.parent != new.parent" but I don't think that's what's being requested. Please be specific, I do not adequately understand what's being requested.

[DerekSikes]

When a child barcode is scanned into a parent barcode a date is recorded. I want to see that date in the loan review for the barcodes that are on the loaned parts. So for example. Three specimens are loaned out in Nov 2023 and come back in January 2024 and get scanned back into the collection on Jan 15, 2024. I can then check the loan review items and see 2024-01-15 for all three specimens and look at the loan date (Nov 2023) and know those specimens are all accounted for and back in the collection.

[dustymc]

Still lost - https://github.com/ArctosDB/arctos/issues/5815 made me think you need something more than 'select max(date) from container_history....' - now that's not the case, you just want the latest??

[mkoo]

From what I see in #5815 and here, the "max(date) from container_history" is not technically what is requested but can serve as a functional proxy MOST of the time. The date could be misleading for what a curator wants to see becuase a broad database update could also be that date. Can this "last date of action" be filtered to only any "user that's not Arctosdb"??

If so, then I think adding that to the table would work.

[DerekSikes]

Ok, just to make sure I understand this - I like that we can see a list of last scan dates in the loan item review but I am looking at this loan https://arctos.database.museum/loanItemReview.cfm?transaction_id=21138973 and most don't have last scan dates which I find hard to believe. So I looked at one of them: https://arctos.database.museum/guid/UAM:Ento:167995

which is on this pin: https://arctos.database.museum/findContainer.cfm?barcode=UAM100285777 and its history has last_date of {ts '2022-05-20 00:08:23'} but this is not visible in the loan review items list

I experimented with another specimen like this & scanned it into a unit tray & saw that its history updated with a new last scan date & this was visible in the loan.

It sounds like I can simply assume that if a part lacks a last scan date then it was scanned sometime before 9 Nov 2023?

Which doesn't seem like a great solution - is there a better one for all those already-object-tracked specimens that lack these dates in the loan review items list?

[DerekSikes]

@dustymc - please see my question above

[dustymc]

@DerekSikes thanks for the nudge, please re-open and set the milestone if there's more to discuss.

I implemented according to https://github.com/ArctosDB/arctos/issues/6028#issuecomment-1793101702

The code is https://github.com/ArctosDB/PG_DDL/blob/master/function/getLastContainerScanDate.sql

I'm totally open to anything else the data can support.

[DerekSikes]

Just wondering what your thoughts are on how to deal with the many object-tracked specimens that have NULL for this field right now?

My ideas: 1) remember that NULL = "probably object tracked before Nov 2023" 2) re-object-track everything to update this field

[dustymc]

thoughts

I don't think I have any useful ones because I don't think I quite grasp what you're trying to do.

I like to imagine that if I were running a collection I'd scan things into loans (actual BEEP-BEEP - two barcodes - when the barcoded object goes into the barcoded loan-box), and then I'd scan things back onto shelves (two more BEEPs) when they come back in, and by doing so I'd never have to worry much about getting anything on the right shelf or needing to infer some state from some data that doesn't really have that information. Everything I'd need to know about how to find an object would always be front-and-center, no guessing required. I suspect this would ultimately be a LOT less work for a lot better data, but I also expect that it would not initially be perceived as such. I think maybe you're trying to find some shortcut to this, but I'm not sure there is one. Lemme know where I got lost....