UI problem - Mark Record for Overlay

Bug #621459 reported by James Fournie on 2010-08-20
44
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Evergreen
Low
Mike Rylander
3.0
Undecided
Unassigned
3.1
Undecided
Unassigned

Bug Description

When you "Mark Record for Overlay" in the Staff PAC, and then import a record via Z39.50 and overlay said record, the record remains marked for overlay despite having been overlaid already.

~James

James Fournie (jfournie) on 2010-08-31
Changed in evergreen:
importance: Undecided → Low
James Fournie (jfournie) on 2010-09-14
Changed in evergreen:
status: New → Triaged
Jason Stephenson (jstephenson) wrote :

No version information supplied.

We need information to know if this is still a problem in 2.1+ of Evergreen.

If not, we'll set to Won't Fix.

Changed in evergreen:
status: Triaged → Incomplete
Changed in evergreen:
status: Incomplete → Triaged
Chris Sharp (chrissharp123) wrote :

I do not see this happening on current master. Marking as Incomplete.

Changed in evergreen:
status: Triaged → Incomplete
Jane Sandberg (sandbej) wrote :

A quick note: this *does* happen in the Web staff client (checked in Webby and our local 2.12 system).

Andrea Neiman (aneiman) wrote :

Confirming that I see this behavior in the web staff client, but I'm wondering if it is an intentional change from XUL since the web client includes the "reset record marks" action?

Marking confirmed & tagging for web client, just in case.

Changed in evergreen:
status: Incomplete → Confirmed
tags: added: webstaffclient
Mike Rylander (mrylander) wrote :

As far as I can recall, it is intentional that the last record (or other object) marked as a target for an action is retained after a single action is performed, so that if multiple actions need to be performed the staff will not have to go back to the target and mark it again.

Kathy Lussier (klussier) wrote :

Is there a use case for overlaying a record twice? Or is this behavior intended to help in those situations where staff accidentally overlay with the wrong record and then need to perform another overlay? Maybe we should kick this question to the catalogers list.

Elaine Hardy (ehardy) wrote :

There would be no need to overlay the same record a second time, except for those occasional times when you forgot one to edit one field.

While incorrectly overlaying the wrong record does occur with the XUL client, having the marked record automatically clear after overly prevents this from occurring.

It is much more likely that you will leave a tab with the Z39.50 interface open while doing database cleanup, returning to the tab after you have marked a new record for overlay. As it stands now, not only is the last record marked for overlay in that tab, if you log off and log back in, that record is still marked for overlay. All of this creates the real hazard of overlaying the wrong record. At the very least, it creates extra steps to clear the marked record.

Elane

Remington Steed (rjs7) on 2018-01-19
tags: added: usability
Janet Schrader (jschrader) wrote :

In web client 3.0 using the 'mark for' menu, marking a record for overlay can be undone by then selecting 'reset mark' in that menu. If you 'mark local result as overlay target' this does not show in the 'mark for' menu. You can tell what record you are overlaying because both tile side-by-side but if you decide not to do the overlay this record will stay 'marked' and there doesn't seem to be a way to unmark it.
I could duplicate Elaine's experience. I refreshed the Z39.50 tab and it was still marked; I opened a new function in the tab and went back to Z39.50 and it was still marked. I logged out and back in and it was still marked.

Andrea Neiman (aneiman) on 2018-05-08
tags: added: cataloging
Sarah Childs (sarahc) wrote :

I agree that generally speaking you are not going to want to overlay the same record multiple times in one session (only if you have made a mistake), and having a record remain marked for overlay after it has already been overlaid is undesirable. It would be preferable if overlaying the record cancels the marking, since having a record remain marked is likely to cause mistakes.

Mike Rylander (mrylander) wrote :
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.2-beta
Bill Erickson (berick) on 2018-08-07
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Branch with a sign off for Mike's commit, plus an additional commit to clear the local merge target variable, so the Z39 UI shows "No record marked for overlay" as soon as the value is cleared.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp621459-z39-overlay-clear-target

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Elaine Hardy (ehardy) wrote :

How will this work with the fix https://bugs.launchpad.net/evergreen/+bug/1710401?

These two bugs seem very similar to me since if the mark for overlay is cleared as soon as the record is overlaid, the issue in 1710401 wouldn't arise.

Mike Rylander (mrylander) wrote :

Elaine,

They're orthogonal. The other bug is about changing the marked record whether the current Z interface has been used for merge or not.

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Mike Rylander (mrylander) wrote :

Thanks, Bill. Signed off your commit and picked into master, 3.1, and 3.0.

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers