Duplicate item status rows

[George Duimovich]

EG 1.6.1.4
OpenSRF: 1.6.1
PG: 8.4

Steps to reproduce:

1. Show Item Status by Barcode (F5)
2. Enter / paste in barcode [1]
3. Edit item attributes (just look, don't change anything), then click "Close" to close the copy editor

Result: new duplicate item row added to your item status list; repeat 2 & 3 and another same row added.

[1] BTW, if your barcode has a trailing space, system won't find item; ideally, trailing spaces (sometimes introduced as a result of copy/paste) shouldn't impact the search for a valid barcode.

[Ben Shum (bshum)]

Confirmed.

Re: [1] trailing spaces: We've had crazy situations where we have legacy barcodes with a whitespace in the barcode itself at the end, making it 13 digits and a whitespace when scanned. So sometimes there's legitimate existence for a trailing whitespace in a barcode scan. But that's an outlier situation I think.

[Michele Morgan (mmorgan)]

This is still an issue in 2.2 alpha3. Our users are finding the duplicate rows produced confusing. It would be best if the rows would not duplicate, but even a button to refresh or dedup the list would help.

The trailing spaces are also an issue. It's easy to pick up a trailing space when copying a barcode from somewhere and pasting it into item status, and misleading when that results in an item not found. Stripping out trailing spaces at least before submission would help a lot.

[Jason Etheridge (phasefx)]

There were two mindsets I would flip between when working with lists like this in the client.

1) It's a canonical list. One entry per thing
2) It's ticker tape, receipt paper, a log of what was scanned at the time it was scanner

So for Item Status, I was definitely in mindset #2. Editing an item would effectively "re-scan" it.

Thinking about it, I still prefer it, but will bow to consensus if folks think #1 is better. Or we can tweak the behavior just in the context of editing or almost editing items.

-- Jason

[Thomas Berezansky (tsbere)]

I see both arguments as being valid.

Maybe write code so that "trim" can be done in two ways, the current "just 20 entries" and a new "just 20 entries, but remove any existing rows that match what we just 'scanned' first"? With an extra checkbox somewhere, obviously.

[Jason Etheridge (phasefx)]

I think a simple "No Dupe" checkbox would fit one of the suggestions
given. Trim or not would be orthogonal.

[Michele Morgan (mmorgan)]

I would agree that a "No Duplicates" checkbox that is sticky would allow the user to choose whether they are of the "one entry" or "ticker tape" persuasion, regardless of whether they want their list trimmed.

[Jason Stephenson (jstephenson)]

Is anyone going to actually work on this so we have a chance of targeting it at a milestone?

[Sarah Childs (sarahc)]

Apparently this is still an issue in 2.5

I was working with a staff person where the items "rescanned" with every edit yesterday. From a user perspective (at least mine and hers), editing something (and especially just looking at the attributes) is not a rescan and should not make it appear again on the display. We just want the existing entries to refresh, we do not want them to duplicate.

We needed to open and close things several times, and they kept repopulating. It felt like our items were tribbles, they duplicated so many times. We ended up clearing the screen and rescanning so we could see what we were dealing with, which seemed like a waste of time.

I don't experience the rescan effect on my workstation, and I don't know why it happens for her and not me (Is there a setting now that I'm not aware of?), but neither of us liked it.

A "no duplicates" checkbox would be fine--but I'd poll users and see if someone actually wants it to duplicate entries after edits. As long as it refreshes, I can't think of a use case where duplication would be helpful.

And as a caveat for the no duplicates--If you actually do rescan something and it doesn't show up because it's been scanned previously, users would likely be confused.

[Jason Etheridge (phasefx)]

One potential use case for seeing duplicates is that you can also see the changes made, depending on the columns you have visible.

[Chris Sharp (chrissharp123)]

Marking "incomplete" since it's unclear at this point whether the people reporting it consider it desired behavior or not.

[Kathy Lussier (klussier)]

I just read through the LP report and actually feel like people were coming to consensus on phasefx's suggestion for a No Dupe check box. However, I also think that consensus makes this report more of a new feature than a wishlist. Chris, do you think it would be acceptable to change this to a Wishlist bug instead?

[Kathy Lussier (klussier)]

Sorry, in the above comment, I meant to say this report is more of a new feature than a bug.

[Chris Sharp (chrissharp123)]

I agree, Kathy. Changed accordingly.

[Jason Boyer (jboyer)]

What I think would address all of the concerns is if the "re-scan" only happened on an actual edit. As is if you open and cancel the editor you still get an additional row that will be identical. If the new row had at least one changed field I suspect there would be less confusion among staff. I would also prefer that to the existing row being edited.

[Sarah Childs (sarahc)]

@jboyer I disagree. Re-scan happening only on an edit would not address my concerns. I prefer the existing row to be refreshed. I do not consider an edit and a scan to be equivalent and I don't like having things re-scan when I edit them. Sounds like the checkbox is the way to go because it seems dev-type people like re-scans and librarian-type people do not.

Also, apparently it has the re-scan behavior when trimlist is checked and does not when it isn't, which seems very strange and non-intuitive to me.

[Elaine Hardy (ehardy)]

See https://bugs.launchpad.net/evergreen/+bug/1721109

[Terran McCanna (tmccanna)]

Marking this one Won't Fix due to the approach taken in the work Elaine mentioned above.