© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
There is a side effect/tradeoff to not having the parts selection available from the "replace barcodes" screen.
When one is working on items for multiple libraries, and happen to be using a workstation registered to a library that has item statistical categories that are required (for that library), the "edit call numbers and items" screen will force you to choose a value for those statistical categories, even for items belonging to other libraries. The "save" buttons are disabled, until those statcat values are chosen. So you can't edit items for other orgs with that interface unless you:
a. Are willing to have items all over the consortium with statistical categories and values that don't belong to them
OR
b. Logout, re-register the workstation as the other library, log back in, retrieve the record again, then make the edit. Rinse and repeat multiple times for all of the items underneath a given bib record.
OR
c. Change the statistical categories, so they are no longer required.
When working on assigning parts for existing titles/items, we're usually working with one title, and fixing all of the items underneath it. And we're doing it for an entire list of titles.
Option "a" is definitely not a desired result, but option "b" is an impossibly convoluted and time consuming workflow. And "c" defeats the point of having them required in the first place. (We require them for reasons. In fact, only one library in the consortium doesn't require them.)
Enter the "Replace barcode" interface.
That interface has nothing to do with any assignment of statistical categories, so in the XUL client it didn't care one whit if you used it to assign parts to items without messing with (and messing up) statcats, or any other item attributes, for any library that you had permission to set them for.
Whereas in the web client, that option is now gone. While we can change the part in "edit call numbers and items", we can't save it unless we also assign a (bad/wrong) statcat entry. Usually in addition to the (good/correct) ones it already has.
I supposed this could be considered an issue with how "required statcats" are currently enforced (by referencing the org of the editing workstation rather than the ownership of the item being edited), just as much as (or more than) it is with the "replace barcodes" interface in the web client. But either way, we are still using the XUL client for this function, as getting it done cleanly and in a timely manner in the web client is nigh impossible.