Copying in patron editor no longer produces confirmation message

Bug #1192189 reported by Kathy Lussier
54
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Medium
Unassigned

Bug Description

Evergreen version: 2.4 and recent version of master

In 2.3 and earlier, clicking on the patron barcode, phone number, name, etc. generated a popup confirmation letting the user know that the data has been copied to the clipboard.

This popup no longer appears in 2.4 or master.

Revision history for this message
Jason Etheridge (phasefx) wrote :

This happened in https://bugs.launchpad.net/evergreen/+bug/949322

I'm in favor of no clipboard alert, but would like to see the clipboard contents in the statusbar as an alternative.

Revision history for this message
Ben Shum (bshum) wrote :

Right, this commit specifically: http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e1a7501799119e0f305616af5bf97149d9bdf4c0

We've been reverting this in our local build branches since it was added because we didn't like the confirmation popup disappearing. During our testing, folks preferred keeping it.

So consider our vote +1 to bringing it back.

Revision history for this message
Kathy Lussier (klussier) wrote :

I would like to see feedback from end users on this one since they are the ones who are using these functions on a regular basis. On the one hand, I can see that the message could be an annoyance since it requires an additional click. On the other hand, I know it was disconcerting to me and some other users when I didn't get a message. It made me question whether clicking actually did anything.

In lieu of adding yet another library setting, I think it would be best to go with whatever works for the most people.

Revision history for this message
Jason Etheridge (phasefx) wrote :

This might make the lack of an alert more palatable:

collab/phasefx/clipboard_statusbar @ working/Evergreen.git
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/clipboard_statusbar

Revision history for this message
Jason Etheridge (phasefx) wrote :

Hrmm, that tweak doesn't work in all places. Does work in Holdings Maintenance, but not in Patron Summary. If anyone wants to run with it, feel free.

Revision history for this message
Jason Etheridge (phasefx) wrote :

More sub-interfaces would need to have access to xulG.set_statusbar

Revision history for this message
Gordana Vitez (gvitez) wrote :

+1 to keep the message from Niagara College staff. I know I was thrown for a loop and staff were happy to see it working again once we had the patch applied.

Revision history for this message
Jo-Anne Teeuwsen (jteeuwsen) wrote :

+1 to keep the message from Pelham Public Library staff. We did not realize how much we relied on that message until it was gone!

Revision history for this message
Kate Butler (kreb) wrote :

+1 to keep the message somewhere from Rodgers Memorial. Staff do not believe it's actually copied without the message, so they end up clicking four or five times just to be sure they got it.

Revision history for this message
Ben Shum (bshum) wrote :

I'm assigning this bug to myself to remind me to ask the broader community about how this behavior should be. So far, there's four votes in this thread towards reverting the commit and restoring the original functionality.

Changed in evergreen:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Ben Shum (bshum)
milestone: none → 2.next
Revision history for this message
Chris Owens (owensch) wrote :

I would second Kate's comment. My staff at Blanchester Public Library really misses the message since we recently upgraded.

Revision history for this message
Dan Wells (dbw2) wrote :

I am 100% in favor of pursuing Jason's statusbar-based solution. It's a much more elegant option.

Changed in evergreen:
milestone: 2.6.0-alpha1 → 2.6.0-beta1
Revision history for this message
Jason Boyer (jboyer) wrote :

I'm with Dan and Jason. I understand that staff may like to be informed, but popping up a box that requires interaction should be reserved for serious problems. A status bar notification still reassures the staff that wants to know, but stays out of the way of staff who know what just happened and don't want to be bothered by it.

Revision history for this message
Kathy Lussier (klussier) wrote :

I'm adding a link to a discussion we had on the general list regarding this question - http://markmail.org/message/ud3uufsprtqqbbly. There were some good approaches discussed in that thread.

Dan Wells (dbw2)
Changed in evergreen:
assignee: Ben Shum (bshum) → Dan Wells (dbw2)
Revision history for this message
Michele Morgan (mmorgan) wrote :

It's unclear to me how the proposed status bar notification appears in the client. A mockup or screen shot indicating the location of the status bar would help illustrate how this would show to users. My concern is that it would not be visible enough as a notification that the copy was successful.

Dan Wells (dbw2)
Changed in evergreen:
importance: High → Medium
Dan Wells (dbw2)
Changed in evergreen:
milestone: 2.6.0-beta1 → 2.6.0-rc1
Changed in evergreen:
milestone: 2.6.0-rc1 → 2.next
milestone: 2.next → none
Dan Wells (dbw2)
Changed in evergreen:
status: In Progress → Confirmed
assignee: Dan Wells (dbw2) → nobody
Changed in evergreen:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.