It's harder to get to the Monograph Parts menu from the web client's holdings editor

[Jane Sandberg]

In the XUL client, you could get to the parts dropdown by choosing "Replace barcode" or going into the copy editor. In the Web client, it's not included in "Replace barcode", "Edit items", or "Edit call numbers" (in Item Status and Holdings View). The only option that includes the parts dropdown is "Edit call numbers and items".

As of 3.3.

[Chrisy Schroth (cschroth)]

I found that this is the case as well, however in the XUL client, when you used "Replace barcode" to actually replace barcodes, if you didn't re-choose the part for every item/barcode, the parts were removed from the items. This really messed things up when the patron had placed a part hold while the item was on order, but Acquisitions had (unknowingly) removed the parts when they received the items.

In this version, (as of last night 3.2.5), using "Replace Barcodes" changes the barcode without changing/removing the part, which, as you pointed out, is not available on this screen.

Also, Acquisitions told me that on their side "Update Barcode" also has the dropdown option to add/change parts, in addition to the "Edit call numbers and items" option. Even though they have that option, they no longer have to re-choose the part when they update the on order barcodes to the full ones.

[Jeremiah Miller (jeremym-t)]

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.

[Elaine Hardy (ehardy)]

PINES libraries don't have required stat cats so do not have this issue. I much prefer having the interface to assign parts away from the replace barcode interface. This makes it more clearly a cataloging function. I would prefer a solution that keeps that distinction but doesn't negatively impact required stat cats.

[Jeremiah Miller (jeremym-t)]

We're completely fine if the interface for this is kept separate from replacing barcodes. The only relation between the two activities is that they are together in the XUL client, and it works. While they aren't in the web client, and it doesn't work.

The real issue is a combination of how required statcats are enforced, with how some things in the interfaces are tied to workstation registration. The XUL client provides a way around it, the web client doesn't.

Until there is an alternative to doing a workstation registration changing dance, we have to use the XUL client for this.

Separate interface for managing parts? That'd work.

An equivalent to "operator change", but for "workstation", to change what org it thinks you're at? That'd work too (even better). Or something else to make centralized cataloging & item management easier, without being hamstrung by whatever org your workstation is registered with.