Hi Diane,
     Could this be the bug? https://bugs.launchpad.net/evergreen/+bug/1746536

Scott

From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Diane 
Disbro
Sent: Monday, May 14, 2018 8:11 PM
To: Evergreen Discussion Group <open-ils-general@list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] 3.2 Preparing for XUL client removal / browser 
client blockers

Good evening -

I know there is a bug report for not being able to edit the attributes of more 
than one item at a time in Webby but I can't find it. XUL allows that function. 
It is used by circ staff to change shelving locations and circulating 
library.We positively must have that function. I talked to several people at 
the conference about this bug and everyone told me that it isn't slated for 
squashing in any upcoming upgrade.

I know that we can use copy buckets to change attributes of more than one item 
at a time but that makes a simple task more complicated.

If I need to submit another bug report about this, let me know.

Thank you.

Diane Disbro
Branch Manager/Circulation Coordinator
Union Branch
Scenic Regional Library
308 Hawthorne Drive
Union, MO     63084
(636) 583-3224
ddis...@scenicregional.org<mailto:ddis...@scenicregional.org>

On Wed, May 9, 2018 at 3:57 PM, Bill Erickson 
<beric...@gmail.com<mailto:beric...@gmail.com>> wrote:
Hi All,

We had a discussion at the Evergreen conference hackfest about our plans for 
removing the XUL staff client from Evergreen, effective with the release of 
version 3.2.  I wanted to recap some of that here and open the door to any 
questions or concerns about the process.

The key point of discussion centered around ensuring the browser client is up 
to the task of replacing the XUL client for all users when the XUL client goes 
away.  (A number of cataloging bugs in particular stood out during the 
discussion).

Of special interest will be input from sites that are already using the browser 
client in production, but still have some staff using the XUL client, or any 
sites that delayed migration.  We need details on why they are unable to make 
the switch to the browser client.

To track these, I propose we once again make use of the Launchpad 
"webstaffblocker" tag to indicate which bugs we consider blockers for migrating 
away from the XUL client.  These bugs should of course also be marked as High 
priority.

We have a few such bugs already:

https://bugs.launchpad.net/evergreen/+bugs?field.tag=webstaffblocker

If you are aware of any bugs that should be added to this list, please 
add/update the bugs in Launchpad.  Of course, we can't plan when we'll find 
bugs, but getting the ones we know about solidified sooner than later helps 
ensure we can address them during the 3.2 development cycle.

When determining whether a bug should be a blocker, a good rule of thumb is 
that the bug describes a feature or work flow that's regularly performed by 
staff in the XUL client that either has no analog in the browser client or 
requires an untenable number of extra steps in the browser client to accomplish.

Please feel free to add anything I missed from the discussion or reply with 
questions, etc.

Thanks,

-b







Reply via email to