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

On Wed, May 9, 2018 at 3:57 PM, Bill Erickson <> 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:
> 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