Webstaff Cataloging Cleanup Omnibus, May 2018

[Dan Wells]

Since the fixes have become interdependent, and exist in a single branch, let's bring the bugs under one roof to try and get them in. The bugs covered here include:

Bug #1715697 - Web Client: Show empty volumes Holdings view
Bug #1732201 - Web Client: Missing functionality to create empty volume
Bug #1737812 - Web Client: fool proof transferring vol/copy process
Bug #1738242 - Web Client: holdings view checkboxes issues

I am going to mark all of those as duplicates of this bug to unify the discussion here, as I could see no simple and convincing way to separate them.

[Dan Wells (dbw2)]

I believe all significant issues as discussed on the individual bugs have been addressed and the most recent branch is here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

working/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

[Jason Stephenson (jstephenson)]

After applying this branch, we are not able to add an empty volume. No matter what we do, the Save & Exit button is disabled/greyed out.

I've tried it from the Actions menu on the Holdings View and via clicking Add Volumes in the record view. It does not work for me in either case.

[Jason Stephenson (jstephenson)]

Further testing has turned up that the fix for bug 1738242 has been partially undone. If you uncheck show volume details, show copy details is also unchecked. However, if you later check show copy details, it is checked but nothing happens. IIRC, in Mike's original branch, if you checked show copy details with neither button checked, then show volume details would also be checked and you would see copy and volume details.

[Dan Wells (dbw2)]

Jason, thank you for testing this branch. I am sorry it did not work as expected for you.

The checkbox commit is unchanged from Mike's original fix and in my testing the behavior is identical. I would describe said behavior as "quirky but functional" :) Being quirky, it is a little hard to describe, but basically, it boils down to a few things:
1) If both boxes are checked, unchecking "Show volume detail" will uncheck "Show copy detail".
2) If "Show volume detail" did this unchecking, it will re-check "Show copy detail" if the user re-checks "Show volume detail"
3) [this is the quirky bit] Checking "Show copy detail" without "Show volume detail" checked never adds to the detail level, but it does change the underlying state of the box. If "Show copy detail" is unchecked, then you uncheck "Show volume detail", the box is now (in essence) "double-unchecked". An attempt the check the box will leave it unchecked, but will cause it to be checked if one now checks "Show volume detail". A second attempt to check the box will succeed in checking it, but again, the actual detail level is not affected, as there is no ability to "Show copy detail" without also showing volume detail.

My reading of the testing on the original bug was that this behavior was noted and deemed an acceptable level of improvement, as major errors were avoided, and desired display states were not hard to achieve despite interface imperfections.

My changes attempt only to address regressions, so some rough edges remain (a feature not exclusive to this branch!). If it helps for comparing behaviors, Mike's branch is still running here (as of 5/25):
https://dev-bugsquash.equinoxinitiative.org/eg/staff/

Finally, this comment is a little longish already, so I will address your other concern separately...

[Dan Wells (dbw2)]

Regarding the inability to add an empty volume, I am a bit stumped. Obviously it works here, and we've tested it very extensively. It is always possible that something in our environment didn't make it correctly into the branch.

I can note a few things which might be helpful to testers (and which all applies to the original branch and the fixes posted here). First, the ability to add an empty volume is not a capability of every instance of the volume/copy editor, but only one launched from "Add...Volumes" (in the action menu). You'll know you are in the right place when the "Save & Exit" button appears to the right of the call number fields. If you attempt to use "Add...Volumes and Copies", you get the combined editor, and it will not be savable without a copy. In an unfortunate interface quirk, the record level "Add Volumes" also launches the combined volume/copy editor, so it too requires a copy. This button's label and behavior is unchanged from master, but with the new abilities here, I agree some added clarity would be helpful. In my opinion, changing the label here is our best option. I'll push commit for that shortly.

Jason (or any other testers), can you confirm that "Add...Volumes" in the action menu doesn't function in the branch as posted? Thanks again!

[Mike Rylander (mrylander)]

Dan, thanks for putting some work into these fixes. I greatly appreciate it, and I'm sure catalogers around the world will as well.

The "quirky" part is meant to be that way. Because the display of volume and copy details are both structurally and visually hierarchical, there's no good way to show copy detail without volume detail. I also don't think it would be a good idea to try, because without the call number a barcode doesn't mean much, and it doesn't save space in the UI to allow that. So, the copy detail checkbox just tries its best to maintains the desired "show copy details" state for when copy details can, in fact, be displayed.

An improvement would be to make those checkboxes interdependent and have the copy detail checkbox disabled when the volume detail checkbox is not checked. That's something I've had in mind for when I get back to the cataloging bugs generally, which hopefully will be in the next couple weeks, but it's nontrivial in the current code because the checkboxes are embedded in the grid logic. It can be done, though, I think. I'd probably give the menu item a new eg-disable attribute that accepts a function (a la handler) and have the result of that Do The Right Thing via ng-disabled inside the grid template. If that's something you'd like to look at, please don't feel the need to wait for me to give it a go.

Thanks again!

[Jason Stephenson (jstephenson)]

Dan,

I am using the Add ... Volumes from the Action menu in the holdings view.

When I first open a record where my test library has no holdings, I get the following in the Javascript console:

Holdings fetch with: rid=3837995 org=119 copy=false vol=false empty=true
angular.js:14199 TypeError: Cannot read property 'join' of undefined
    at holdings.js:205
    at Object.q [as forEach] (angular.js:325)
    at holdings.js:203
    at angular.js:16696
    at m.$eval (angular.js:17994)
    at m.$digest (angular.js:17808)
    at angular.js:18033
    at f (angular.js:6045)
    at angular.js:6324
(anonymous) @ angular.js:14199
(anonymous) @ angular.js:10707
(anonymous) @ angular.js:16704
$eval @ angular.js:17994
$digest @ angular.js:17808
(anonymous) @ angular.js:18033
f @ angular.js:6045
(anonymous) @ angular.js:6324
setTimeout (async)
k.defer @ angular.js:6322
$evalAsync @ angular.js:18031
(anonymous) @ angular.js:16603
e @ angular.js:16712
$$resolve @ angular.js:16745
resolve @ angular.js:16728
(anonymous) @ angular.js:16681
oncomplete @ pcrud.js:213
OpenSRF.Stack.handle_message @ opensrf.js:689
OpenSRF.Stack.push @ opensrf.js:669
OpenSRF.websocketConnection.onmessage @ opensrf.js:364
socket.onmessage @ opensrf_ws.js:78
holdings.js:40 Canceling fetch for org 119
holdings.js:67 Holdings fetch with: rid=3837995 org=119 copy=true vol=true empty=true

The above repeats 2X.

I then click on Holdings View. The first time that I did so tonight, Show Empty Volumes, Show Empty Libraries, and Show Copy Details were checked. Show Empty Volumes was not checked. My library did not show up until I checked Show Volume Details.

After noticing that, I checked and unchecked the various boxes in different orders. It seemed to be unpredictable when my library with no holdings would show up. I believe it showed up once with just Show Empty Volumes and Show Empty libraries checked. However, at another time, I had to also check Show Volume Details (which automatically checked Show Copy Details) before it would show up. The Show Holdings at or below selection is at my branch, so nothing else would show up.

Note that while I was checking and unchecking the boxes, the console messages would repeat as the page reloaded.

I then checked the grid table entry for my branch, and chose Add ... Volumes from the Actions menu. This opened the Vol/Copy Editor in a new tab with only the volume information visible. Save & Exit was disabled and mousing over it gave me a cursor that indicated it would not work (i.e. a circle with a line through it on Chrome).

Maybe I do not know what I am doing, but nothing that I did to the volume entry would enable the Save & Exit. I even chose a prefix and suffix at one point to have all fields filled in.

It may be a problem local to this VM as I did load a bunch of branches this week. However, most of what I have loaded has made it into rel_3_0 for the 3.0.8 relase. Also, I am testing with rel_3_0, which may be significant. It could be that my code is junked up or that the changes are not working with 3.0 for some reason.

I should be able to look at this more later with a fresh build, and I can even go so far as to wipe out the installed code ...

[Dan Wells (dbw2)]

Mike, thanks for chiming in again. I agree with your current checkbox design choices for getting us to a workable interface, and also with your proposed future state. I think I can find time to get the disabling working as you describe. But the current ability to check a box and have it remain visually unchecked is a little, if not "quirky", perhaps a more positive word would be "unprecedented"? ;)

Jason, I appreciate all of your testing and the extra details. We're running this code in production, and we're on a rel_3_0 base, so I don't think that's the main issue. One thing I'm wondering from your testing description, we haven't done much testing here from totally empty states, so maybe something can be uncovered in that regard. I, too, I will try to get this branch on a totally fresh VM early next week to see if I've somehow left something out, or if it is interacting with some recent code we don't have on our test environment.

[Jason Boyer (jboyer)]

I think I know why Jason and I are both having issues with adding empty volumes. Jason, do you have any required item stat cats on the server you're testing with? We require one here and I can't get that button to enable for anything. Stepping through the debugger shows that it's (eventually) tripping up on the "if ($scope.forms.myForm && $scope.forms.myForm.$invalid)" test in staff/cat/volcopy/app.js because myForm.$invalid is true. Digging around in the DOM shows that the auto-generated form looks like this: <form novalidate="" class="css-form ng-pristine ng-valid-step ng-invalid ng-invalid-required" name="forms.myForm">

Note the ng-invalid-required class. Digging *way* down into the hidden item form, the select for our required stat cat is in there with a matching set of ng-invalid and ng-invalid-required classes.

So, as far as fixing this, is it easier to somehow completely dump the item form rather than hiding it when only adding items, or add another if (only_add_vols) branch in check_saveable to ignore the form proper and only check the call number label(s)?

[Jason Stephenson (jstephenson)]

Jason, yes, we do have required stat cats. We have two, in fact. Your explanation makes sense. I haven't taken time to use the debugger on this form, but I might just to see if I can corroborate your findings.

[Janet Schrader (jschrader)]

The required stat cats preventing creating a volume makes sense because if you try to edit multiple items but some have different stat cats that field displays in red in CWMARS indicating it's not filled in. So if you can't edit two items with different stat cats then not being able to create a volume without creating an item makes sense if the system is looking for that required field.

[Kathy Lussier (klussier)]

Janet,
The fix for that batch editing issue was merged into the release 3.0 branch last week. However, I don't know if it's on the system Jason's been using for testing. bug 1738893

[Janet Schrader (jschrader)]

Thanks, Kathy. I just checked in our 3.0 web client and it's there. It's a
little disconcerting because if there's more than one value for an item
field it shows as blank or <none> or <multiple>. If there's more than one
status or location it's blank because <none> is not a choice there. If
there's more than one circ modifier it's <none> as that's a choice there.
The stat cats show as <multiple> even though that's not a choice and <none>
is. However I think ,multiple> makes more sense for all of the fields. At
least that way a user would see there is more than one value, blank or
none makes it look like there are no values at all. Could that be a
Lauchpad bug?

​Janet

On Mon, May 28, 2018 at 7:31 PM, Kathy Lussier <email address hidden> wrote:

> Janet,
> The fix for that batch editing issue was merged into the release 3.0
> branch last week. However, I don't know if it's on the system Jason's been
> using for testing. bug 1738893
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1732201).
> https://bugs.launchpad.net/bugs/1773417
>
> Title:
> Webstaff Cataloging Cleanup Omnibus, May 2018
>
> Status in Evergreen:
> New
> Status in Evergreen 3.0 series:
> New
> Status in Evergreen 3.1 series:
> New
>
> Bug description:
> Since the fixes have become interdependent, and exist in a single
> branch, let's bring the bugs under one roof to try and get them in.
> The bugs covered here include:
>
> Bug #1715697 - Web Client: Show empty volumes Holdings view
> Bug #1732201 - Web Client: Missing functionality to create empty volume
> Bug #1737812 - Web Client: fool proof transferring vol/copy process
> Bug #1738242 - Web Client: holdings view checkboxes issues
>
> I am going to mark all of those as duplicates of this bug to unify the
> discussion here, as I could see no simple and convincing way to
> separate them.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1773417/+subscriptions
>

[Jason Boyer (jboyer)]

Not sure why I didn't think to just verify this yesterday but making all stat cats not-required does allow me to create an empty volume with these patches loaded, so they're the issue at hand here.

[Dan Wells (dbw2)]

Gave this ten good pokes today, and the more I poke it, the more bugs scurry out of the cracks. Here are a few mid-point observations:

1) We could really use some unit tests for this :) Squashing one bug only to fear you've produced one (or ten) more can be a drag. I've yet to write any Angular unit tests, but maybe I'll try my hand at one here before it is through.
2) I think I've fixed the major bugs noted here, plus a few more, and haven't noticed any worse ones being produced. So, progress!
3) I don't think it is realistic to expect this to be bulletproof before getting it in. In particular, there are number of actions which are not entire sensible, but not disabled (e.g. trying to add just a 'copy' where no call number exists). These tend to do something reasonable, but sometimes slightly different than the "right" option (in this case, "Add Volumes and Copies"). I think those tweaks can be hammered out over time, as there are a number of ways to move on those.

I am going to spend some more time tomorrow with my own testing before subjecting anyone else, but I hope to produce a branch by midday.

[Jason Boyer (jboyer)]

I was concerned about needing a code change to enable the save button when taking the same tack as the multiple item editor change does is just as good (or better). This branch is a one-line change to allow empty volume creation with required stat cats.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1773417_holdings_view_patch_patch

working/user/jboyer/lp1773417_holdings_view_patch_patch

[Dan Wells (dbw2)]

Testing seems positive here, so a new commit has been pushed to the existing branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

working/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

Jason, thank you for posting your fix a few hours ago. I actually went in a direction that you had suggested earlier in modifying check_saveable() instead. At first blush that feels a little cleaner to me, as it means copy editor doesn't know (and doesn't need to know) as much about the outer context, so better encapsulation. But maybe something will end up nudging things back in this other direction, so it is good to have on hand.

The change to check_saveable() also fits in better with the overall theme of this latest commit, which is to further isolate volume editing from copy editing where appropriate and necessary. To steal from the commit message:

The crux of this patch is to rethink how we handle the volume-only editing interface. Previously, we were attempting to distinguish between when the volume was the only thing *showing* and when it was actually the only thing *existing*.

We have now removed that distinction, so the volume-only interface only cares about the volume regardless of the possible presence of a copy. This simplifies the interface logic, and reduces or eliminates the chance of the hidden copy editor interfering with the volume adding/editing functions.

The pieces for moving in this direction were already in place with the previous commits, so this ends up being another rather small, iterative change.

[Jason Boyer (jboyer)]

Good points Dan, I went looking for how the multiple stat cat entry issue was corrected when editing multiple items, and while that does make more sense to do in the template since the display changes, these changes are better made in the controller. I'll check this out asap!

[Elaine Hardy (ehardy)]

Did testing of Bug #1715697 - Web Client: Show empty volumes Holdings view today on the PINES test server.

From actions menu:

Under “Add”:
Volumes: Vol editor opens with selected branches
   Adds as expected (with template issue noted below)
Copies: Vol/copy editor opens with just work station library selected. Must add other branches one at a time.
Vols/Copies: Vol editor opens with selected branches
   Edit call number, add barcodes
   Apply copy template –fails (only some attributes apply. We are having issues with templates so most likely not related to this fix, just noting as part of testing process).
   Manually edit attributes.
   Save & exit – vols/copies save as expected

Add copies button
Adds vols/copies as expected. (with exception of template issue noted above)

The only place I see a bug is adding copies under the action menu. However, adding copies without adding vols first would not be my workflow. I think it is more likely to be an error -- accidentally choosing copies rather than volumes or vols/copies. I would prefer to see an error message directing me to create/add volumes first here .

Having this functionality back is an enormous help for PINES catalogers. Thank you all for working on this.

[Elaine Hardy (ehardy)]

Did forget one other bug in my excitement. I did mention this with the earlier testing and am still seeing -- When you have the view for the entire system or consortium, those libraries with holdings are grouped first followed by those libraries with no volumes attached. And in consortia view, the systems are not in alpha order.

It is preferable to have all libraries in alpha order, whether they have holdings or not. This is UI issue and doesn't impact the functionality, from what I have seen in testing.

[Elaine Hardy (ehardy)]

Tested Bug #1732201 - Web Client: Missing functionality to create empty volume

Functions as expected -- can create empty vols and transfer items to that vol. Can edit and delete transferred item.

Glad to have this functionality back as well. It is a big help when processing pre-cats.

[Elaine Hardy (ehardy)]

Bug #1737812 - Web Client: fool proof transferring vol/copy process

This functions as expected -- I am able to transfer individual vols to a library and successfully transfer multiple vols on multiple libraries to the correct libraries on the target record.

I am also able to transfer items to vols on the same and different records.

This does greatly reduce the previous complexity of tranferring items and vols in the web client. And thanks for removing transfer from the Mark for menu (I will admit that I did like being able to mark the record and then transfer vols that went along with the complexity.

[Elaine Hardy (ehardy)]

Bug #1738242 - Web Client: holdings view checkboxes issues

This functions as I expect:

If I have all checked, Empty libraries, libraries with empty volumes, volume detail, and copy detail all display.

If I uncheck just Show empty libraries, then libraries with empty volumes, volume detail, and copy detail display

If I uncheck Just Show empty volumes, then Empty libraries, volume detail, and copy detail display
Checking volume detail and copy detail displays those details of all libraries and volumes with holdings and does not display empty vols or libraries.

Unchecking copy details just displays the vols with the # of copies attached (including 0 if you check show empty volumes and no value if you have show empty libraries checked)

Unchecking volume details and copy details displays counts of volumes and counts of items for each library ((including 0 if you check show empty volumes and no value if you have show empty libraries checked)

Checking copy details while having volume details displays the same as having both unchecked. I think this is logical, given the volume and copy levels in Evergreen.

[Anna Goben (agoben)]

I added a new bug that's related to this group (#1775036). Kathy L. suggested that I include my comments here as well in case it can be included in this fix:

I think as a result of the fix for this bug #1737812/(#1773417), we've lost a valuable and useful bit of functionality. I regularly perform batch holding moves when there's been an issue with a bad merge. One of the best parts of the new transfer options was the ability to pick a record and transfer several libraries' holdings at once. Now I'm back to having to do it a library branch at a time, which is a HUGE time waster for me if I have 30-40 things to move. I know it's rare use for local single site libraries, but it's a tremendous help for centralized cataloging work either on a consortium or multi-branch system level. Can we please have that option back!?!?

Evergreen version 3.1

[Janet Schrader (jschrader)]

+++1
Yes, I agree with Anna to restore this option. I was just trying to figure out where the transfer to marked record went as I also found this extremely useful when moving multiple items belonging to multiple libraries to a different record.
This was also the only way to transfer an item available to libraries when there still isn't the ability to transfer to an empty library. I always thought transferring items was a very infrequent function but have had two questions on it today and no answer except to use the xul client. I guess you don't know what you've got 'til it's gone.

[Elaine Hardy (ehardy)]

++1 I would also love to have the ability to mark the record as a transfer destination, as I noted in testing comments.

From my testing, you can choose multiple libraries in holdings view as target destinations on one bib record and then choose those vols to be transferred and have them successfully transfer to the correct library. However, having the ability to mark the record without having to mark each individual library would not only save time, it would also remove the possibility of error if you did not choose libraries on either record correctly. I have not tested to see what would happen if you made errors in library or volume selections.

[Dan Wells (dbw2)]

Based on recent feedback, I am going to take a stab at restoring the record transfer destination. Since I seem to have not un-assigned myself last week, please imagine that I am re-assigning myself to this bug now.

Thanks for testing, everyone!

[Dan Wells (dbw2)]

Finally found some significant tuits for this yesterday and today, and am making good progress. Biggest question is where to stop as I find more areas to smooth out. I think I'm close, so I expect to post something today after local testing.

[Dan Wells (dbw2)]

Ok, latest changes are up, 3 new commits:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

working/user/dbwells/holdings-view-omnibus-signoff-rebase-patch

Commit #1 is just a revert of removing the record-level menu option. I could have rolled this into #2, but thought this would be easier this way to squash that diversion away eventually.

Commit #2 is the bulk of the changes. This commit attempts to achieve the goals of both simplification and feature completeness/flexibility. In brief, it continues along the path Mike had started, that is, limit the number of marking and transfer options, then have the code decide the right action to take given the circumstances.

There are now just two "marking" actions, one at the record level, one at the holdings level. The holdings level mark will automatically mark the destination as specifically as possible from the selected row, which means either to the library or call number (vol) level.

We are also now down to two transfer options: transfer the selected item, or transfer the selected volume. Either option will use as much of the given context as possible, then fill in any blanks with reasonable defaults and actions.

For any studying the actual code, as part of the change, a number of functions and variables are also renamed. This is all done for clarification, and in most cases is due to the variable or function now being used more generally (i.e. it is used in both the item and vol context, so it is confusing to be named 'volume_transfer_target', etc.). This commit also clears up a fair bit of now redundant and unused code.

Finally, I added a third commit to fix bugginess in transferring from item status which came up in testing, even though it exists in current master and is really a separate issue. (It just makes some sense to strike while the iron is hot.) Item status transfer really needs to be revamped similar to what we're doing above, as it has both usability and code-duplication issues, but if we let this branch leak too much into other cataloging bugs, we might be here quite a while longer :)

Actually, one more thing I should note. Many existing cataloging functions don't give great feedback to the user, and these are no exception (in master and in this branch). I spent an hour or two attacking that, but ultimately decided to hold that back to again try to limit scope creep of this branch. But if/when this gets in, I've got some of that improvement stashed away and ready to go!

Dan

[Dan Wells (dbw2)]

I am moving myself down a notch in the assignee category to give room to testers, but since I have much of this code in my mind right now, I am happy to stay on and keep chipping away at any new regressions. Thanks!

[Mike Rylander (mrylander)]

I've squashed, rebased, signed off, and amended commits to the above branch, now available at:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1773417-omnibus-holdings-rebase-squash

[Mike Rylander (mrylander)]

Note, this (and two other branches as of this writing) are loaded on https://dev-bugsquash.equinoxinitiative.org/eg/staff/ for testing. See the Evergreen general mailing list for the credentials!

[[e-mail] (tji)]

An extra line shows up when there is no copy in the selected holdings scope and the Show Copy Detail checkbox is deselected. See the screenshot. No such a line when there is, at least, a copy in the selected holdings scope.

[Beth Willis (willis-a)]

 Sorry, could someone share the server credentials?

Thank you.
Beth

On Fri, Jun 29, 2018 at 12:40 PM <email address hidden> <
<email address hidden>> wrote:

> An extra line shows up when there is no copy in the selected holdings
> scope and the Show Copy Detail checkbox is deselected. See the
> screenshot. No such a line when there is, at least, a copy in the
> selected holdings scope.
>
>
> ** Attachment added: "emptyLine.PNG"
>
> https://bugs.launchpad.net/evergreen/+bug/1773417/+attachment/5157859/+files/emptyLine.PNG
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1715697).
> https://bugs.launchpad.net/bugs/1773417
>
> Title:
> Webstaff Cataloging Cleanup Omnibus, May 2018
>
> Status in Evergreen:
> New
> Status in Evergreen 3.0 series:
> New
> Status in Evergreen 3.1 series:
> New
>
> Bug description:
> Since the fixes have become interdependent, and exist in a single
> branch, let's bring the bugs under one roof to try and get them in.
> The bugs covered here include:
>
> Bug #1715697 - Web Client: Show empty volumes Holdings view
> Bug #1732201 - Web Client: Missing functionality to create empty volume
> Bug #1737812 - Web Client: fool proof transferring vol/copy process
> Bug #1738242 - Web Client: holdings view checkboxes issues
>
> I am going to mark all of those as duplicates of this bug to unify the
> discussion here, as I could see no simple and convincing way to
> separate them.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1773417/+subscriptions
>

--
Beth Willis
Digital & Catalog Librarian
NOBLE, Inc.
26 Cherry Hill Drive
Danvers, MA 01923

[[e-mail] (tji)]

Test server credential can be found in this thread:

https://georgialibraries.markmail.org/search/?q=https%3A%2F%2Fdev-bugsquash.equinoxinitiative.org%2Feg%2Fstaff%2F#query:https%3A%2F%2Fdev-bugsquash.equinoxinitiative.org%2Feg%2Fstaff%2F+page:1+mid:h7lrkqdfyw7knn7w+state:results

[[e-mail] (tji)]

Test result on the checkboxes:

1. Show Copy Details acts as a sub option of Show Vol Details, which makes senses. Ideally Show Copy Details is disabled when Show Vol Details is not selected.

2. It works well when Show Volume Details is selected.

3. Issues when Show Volume Details is not selected:

  a. When Show Empty Vol is also not selected, i.e. only Show Empty Lib is selected, scoping to a range that does not have a vol does not work.
  b. When Show Empty Vol is selected, scoping to a range that has neither vol nor empty vol does not work

-----------------------------

Wording for Show Empty Vol and Show Empty Library

When they are selected, libraries with holdings and volumes with copies are displayed, too. When these checkboxes deselected, only the empty libraries and empty volumes disappear. So the function of these checkboxes is to include empty vol/library.

Suggest changing them to Include Empty Volume and Include Empty Library.

[Mike Rylander (mrylander)]

I've pushed a commit to my squashed-rebased branch to address an issue when a call number is supplied without a copy. We should use the call number owning lib as the default copy owner, rather than the workstation library.

[[e-mail] (tji)]

Highlight a library/vol, click Add Copies (top bar, not Actions), the default circ library is the selected library. But if clicking Actions -> Add -> Copies, the default circ library is the workstation library.

[Mike Rylander (mrylander)]

tji, I am not seeing that behavior on the dev-bugsquash test server where the patch is applied. Note: if you have been testing on that server today, you may need to shift-reload, or open the Dev Tools and disable the cache and reload, in order to get the new code.

[[e-mail] (tji)]

Transferring holdings work well, though I encountered one weird incident (two copies (of different libraries) seem missing after attempting to transfer both at the same time). I could not make it happen again.

[Elaine Hardy (ehardy)]

I'm getting a login failure for the credentials in that email string

[[e-mail] (tji)]

The server is working for me. I just tested the default circ library.

I cleared browser caches and tried shift reload. I am still seeing the difference of Add Copies on the top menu bar and the one on the Actions List.

Tina

[Kathy Lussier (klussier)]

Elaine,

Did you include the ending exclamation point in the password? I omitted it on my first attempt.

[Andrea Neiman (aneiman)]

It is working for me as well -- JFYI the 0 in the pw is a zero, not the letter O

[Elaine Hardy (ehardy)]

I've tried both chrome and firefox Cleared caches and reloaded with shift reload and still get the login failure. I am using zero. Working at home on my laptop. Will try desktop tomorrow.

[Elaine Hardy (ehardy)]

aaarrggghh. I omitted it on every single attempt. I knew I was doing
something wrong.

J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128 Office
404.548.4241 Cell
404.235.7201 FAX

On Mon, Jul 9, 2018 at 3:22 PM, Kathy Lussier <email address hidden> wrote:

> Elaine,
>
> Did you include the ending exclamation point in the password? I omitted
> it on my first attempt.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: <email address hidden>
> https://bugs.launchpad.net/bugs/1773417
>
> Title:
> Webstaff Cataloging Cleanup Omnibus, May 2018
>
> Status in Evergreen:
> New
> Status in Evergreen 3.0 series:
> New
> Status in Evergreen 3.1 series:
> New
>
> Bug description:
> Since the fixes have become interdependent, and exist in a single
> branch, let's bring the bugs under one roof to try and get them in.
> The bugs covered here include:
>
> Bug #1715697 - Web Client: Show empty volumes Holdings view
> Bug #1732201 - Web Client: Missing functionality to create empty volume
> Bug #1737812 - Web Client: fool proof transferring vol/copy process
> Bug #1738242 - Web Client: holdings view checkboxes issues
>
> I am going to mark all of those as duplicates of this bug to unify the
> discussion here, as I could see no simple and convincing way to
> separate them.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1773417/+subscriptions
>

[[e-mail] (tji)]

Further testing shows mixed results. It may be related a branch that does not have vol at all. I have consistent result with the following:

bib id 48, SL1 has no vol, highlight it, Add Copies on the top menu bar created a copy with circ lib of SL1; Actions > Add > Copies created a copy with circ lib of BR1 (my login branch). Actions > Add > Vol and Copies created a copy with circ lib of SL1.

If highlighting a branch with a vol, say BR4, the circ lib is BR4 for all the above 3 actions.

Tina

[[e-mail] (tji)]

Forgot to mention, when adding copies for both SL1 and BR4 at the same time, the circ libs listed were BR1 and BR4 if using Actions > Add > Copies.

[Elaine Hardy (ehardy)]

Testing https://bugs.launchpad.net/evergreen/+bug/1737812 -- Mark Holdings transfer in Mark for menu

I was able to mark the record for transfer using this option and successfully transfer a volume to the bib record.

However -- after you mark the record, there is no note in the dropdown menu that a specific record is marked. It would be helpful for the TCN (or Record ID) to be added as for the overlay so that you can tell that a record has been marked for transfer and which one.

Love having this functionality back. Thanks!

[Elaine Hardy (ehardy)]

Tji,

I am not seeing the empty line when show copy details is unchecked (I am testing on the PINES server).

[Elaine Hardy (ehardy)]

Tji and Mike,

I am seeing the behavior Tji describes (testing on the PINES servers):

Highlight a library/vol, click Add Copies (top bar, not Actions), the default circ library is the selected library. But if clicking Actions -> Add -> Copies, the default circ library is the workstation library.

However, this only occurs if there is no existing volume and I try to just add copies. If I click on a vol with copies and choose action menu -- add -- copies, the correct library is the owning library.

If I click on a library with no vols and then actions menu -- add -- volumes and copies, the correct library is the owning library.

[Dan Wells (dbw2)]

I think the existing work on this branch is a big step forward. I've pushed this in as it stands so that smaller lingering issues can exist as normal bugs again, and to start that off, I've moved the most recent discussion over to a new bug, bug #1782359.

Thank you to Mike for the code, and to all the many testers and feedback givers who helped push this along!

[Dan Wells (dbw2)]

This is a bit of an oddity for backporting, as it mixes a bunch of bug fixes together with re-implementations of features to resolve serious workflow deficiencies. I've decided to backport for 3.1, but leaving 3.0 as an open question for the release maintainer, for now.

[Jason Stephenson (jstephenson)]

Assigning the bug to myself for 3.0 backport. I want to make sure that the transfer functions still work as that is where the conflict resided in the code.

[Jason Stephenson (jstephenson)]

I backported the branch to 3.0 and pushed to the community repository per yesterday's discussion during the developers' meeting.

Thanks, everyone!