UI problem - Mark Record for Overlay

[James Fournie]

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

[Jason Stephenson (jstephenson)]

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.

[Chris Sharp (chrissharp123)]

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

[Jane Sandberg (sandbergja)]

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

[Andrea Neiman (aneiman)]

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.

[Mike Rylander (mrylander)]

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)]

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)]

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

[Janet Schrader (jschrader)]

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.

[Sarah Childs (sarahc)]

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)]

A branch implementing this desire is available at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-246891-forget_overlay_target_after_z3950_merge

[Bill Erickson (berick)]

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

[Elaine Hardy (ehardy)]

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)]

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.

[Mike Rylander (mrylander)]

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