Holdings and Item Attributes Editors (VolCopy) Angular Port

Bug #1888723 reported by Bill Erickson
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

Evergreen 3.5 / Wishlist

Bug for tracking the Angular port of the Holdings Maintenance / Item Attribute Editor interfaces.

Work in progress was demoed at the Evergreen Cataloging Working Group meeting July 14th. Meeting notes and demo links here: http://list.evergreen-ils.org/pipermail/evergreen-catalogers/2020-July/001595.html

Items discussed at the meeting and subsequent email discussions have been addressed in the code in progress.

In progress branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lpxxx-angular-volcopy

Rebased and cleaned branch en route.

Revision history for this message
Bill Erickson (berick) wrote :

Cleaned up branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy

At present, the new UI is only accessible from the Angular Staff Catalog. Can be added to the existing catalog / holdings view, bucket UI, etc. as needed.

tags: added: cataloging pullrequest
Changed in evergreen:
status: In Progress → New
assignee: Bill Erickson (berick) → nobody
Revision history for this message
Bill Erickson (berick) wrote :

Oh and two commits from bug #1878079 are included in the branch so that navigating from the angular staff catalog to the item editor can handle various scenarios more appropriately.

Revision history for this message
Bill Erickson (berick) wrote :
Revision history for this message
Bill Erickson (berick) wrote :

Rebased post-Ang catalog and Ang 10 updates. Includes some i18n repairs to avoid nested i18n declarations.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-2

Revision history for this message
Elaine Hardy (ehardy) wrote :

I was able to add an item with duplicate barcode -- no warning and the item saved.

On test server http://angular-acq-test.evergreencatalog.com/ barcode test081802 on records tcn49 and tcn98.

Item status on displays item from TCN98, the first I added.

This is a critical bug.

Revision history for this message
Elaine Hardy (ehardy) wrote :

Columns missing in angular holdings maintenance:

Parts
Circ as Marc
Alerts

Revision history for this message
Elaine Hardy (ehardy) wrote :

Correction to duplicate barcode problem. TCN98 was second time I used the test081802 barcode.

Revision history for this message
Elaine Hardy (ehardy) wrote :

Monograph parts missing ability to merge and delete part labels

Revision history for this message
Elaine Hardy (ehardy) wrote :

Bill, let me know if you want what I am adding separated into different bug reports. I am putting them here since you are tracking angularization of holdings view/maintenance here.

Revision history for this message
Elaine Hardy (ehardy) wrote :

When holdings are updated or edited in holdings maintenance, holdings view does not redisplay with additions or edits. User has to manually redisplay page.

Currently, holdings view redisplays on save & exit, with edits and addition to holdings.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks, Elaine.

Can you clarify your work flow for creating a dupe barcode? I consistently get a warning message and the save buttons are disabled when I try to create a dupe. Screen shot attached.

Revision history for this message
Bill Erickson (berick) wrote :

Monograph parts has Merge and Delete actions in the actions-for-selected-rows menu dropdown in the monograph parts grid. Does that help?

Please open a separate bug for any columns missing from the Holdings Maintenance grid.

Holdings view should be updated after edits -- I'll take a look at that.

Revision history for this message
Elaine Hardy (ehardy) wrote :

Bill,

I tried several ways to recreate the issue and then I discovered that the barcodes aren't duplicates -- there is a space at the end of barcode attached to #98.

I checked our test server and attempted to add a duplicate barcode with a space at the end. The current staff client ignores initial or ending spaces and considers the barcode a duplicate. So #test081802
#test081802#
#test081802#

are all considered dups of test081802

Different bug, then

Revision history for this message
Elaine Hardy (ehardy) wrote :

Sorry I missed the merge and delete actions! I had intended on checking all the various places they might be and got distracted.

I will move the attributes missing from the column picker to another bug.

Thanks!

Revision history for this message
Elaine Hardy (ehardy) wrote :

The second #test081802# above should be test081802#

Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

New branch pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v3

1. Trims leading/trailing spaces from item barcodes in the holdings editor. Leaves interstitial spaces alone.

2. Adds support for broadcasting holdings changes so other tabs (e.g. catalog holdings view) can refresh their data.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Andrea Neiman (aneiman)
Changed in evergreen:
assignee: nobody → Andrea Neiman (aneiman)
Revision history for this message
Andrea Neiman (aneiman) wrote :

Testing on latest branch. Overall looks good. Some feedback:

1) Broadcast changes is neat - when it works. Occasions when it doesn't work include adding a new item to an existing call number and editing a call number to match another existing call number; in both cases a manual refresh updated the grid as expected. Mark Item Damaged did not update the grid automatically but Mark Item Missing did.

2) Edit item alerts - the current Alert Type box is not populated in this modal if you have an existing alert. The alert note is populated.

3) The checkbox label at the top of the grid says "show copies" - it should probably be "show items" to match the preferred lingo.

4) Certain actions that don't make sense are still active - i.e. if you try to edit items from an empty volume, you are taken to the item editor but the save will silently fail without a barcode (which is now on another tab). This mimics existing behavior though, so it might be intentional - it's just harder to notice now that the call number field is on another tab.

Otherwise, adding, editing, deleting, etc. works as I would expect in this grid & the editor. Noting that I DID NOT test any transfer functions.

Changed in evergreen:
assignee: Andrea Neiman (aneiman) → nobody
Revision history for this message
Andrea Neiman (aneiman) wrote :

noting for Friday brain in my 4th comment above - "existing behavior" meaning the AngularJS version of this interface (as it exists in 3.5), in case that wasn't clear.

Revision history for this message
Jane Sandberg (sandbergja) wrote :

I think this is looking really good. Thanks, Bill. My main concern: the Holdings tab/Angjs holdings detail area seems to get more and more confusing as time goes on.

I made a mock-up of this tab (attached is a GIF of it), in which I tried to make things a little less confusing. I'd like to propose that we:
* Hide the batch actions by default. Staff could click on a button to open them, and we could have a workstation setting to remember their preference. The benefit here is that it would dramatically reduce the number of inputs shown on the screen for catalogers at smaller libraries who don't ever work in batch, while making it easy for batch users to re-enable the batch actions row.

* Instead of the "Call Numbers" and "Items" number inputs and the "Add call number" button, re-use the plus and minus buttons for adding and removing rows from the staff catalog search form. Clicking on the "Owning Library" plus sign should open up an <eg-org-select> to allow users to choose the correct library. There should also be an "Add Batch" button to add a number of call numbers or items at once. The benefit here would be that we could have a consistent UI between screens.

* Remove the duplicate "Generate barcodes" button and "Use checkdigit" checkbox.

This screen is so complex because it supports countless workflows. Would any of these three proposals break any workflows?

Note: I forgot to include the Item # column in my mockup; this was not intentional.

Thoughts?

Revision history for this message
Andrea Neiman (aneiman) wrote :

Belatedly realizing that a good chunk of my feedback is related more to the Holdings grid than the new editor

/facepalm

Apologies for the noise and I'll allocate those items to more appropriate LPs

Revision history for this message
Bill Erickson (berick) wrote :

Thanks, Jane. These changes seem sane to me. Anyone else have thoughts on Jane's UI proposals?

Revision history for this message
Elaine Hardy (ehardy) wrote :

At first I thought Jan's mockup was a little too sparse; but the more I compared it to the current versions, the more I liked it.

Since we don't use the generate barcode, I have no opinion about removing it here.

I am on the fence about the use check digit check box. If a library has a branch that doesn't use standard barcode format and others that do, would they need to be able to check and uncheck while adding barcodes?

Revision history for this message
Mary Llewellyn (mllewell) wrote :

I think the use check digit check box should be visible with the print label check box, as it is/was in XUL.

Revision history for this message
Chrisy Schroth (cschroth) wrote :

Logged in to look at the changes, and compare Jane's proposals vs. the current at her request on the Cataloging WG list. My 2 cents for what it's worth :).

As long as the hide batch actions can be opened and the preference remembered, I don't really see a problem with hiding it by default. Sometimes I find it easier to just type my call number into that empty box and apply it over even a single call number when I am editing, rather than making sure I am wiping out the whole order level call number. Related to this, it would be wonderful if the batch could pull the call number from the 092 of the bib record again, so that you could apply it to your item(s). I don't remember when we lost that ability, maybe when we moved from XUL to web? Some of our staff used that feature ALL the time and were very unhappy when it was lost.

For our system here, Acquisitions almost always adds the items for us, and Catalogers are just editing call numbers to replace order level call numbers with the real ones. I asked our Acq supervisor if they use any of this, but she said that all happens in the Acq side, and they rarely have to add anything in the holdings, unless they are adding in the rest of the set of something like World Book. For the few times that I do this task, I would personally find the familiar numbers easier since I do it so rarely. It wasn't intuitive to me just looking at the screen in the GIF that you could still click in that larger area in between the + and - and input a number to add, rather than clicking the + 5 times until I watched to the end and saw it done. Changing it wouldn't break our workflow though, since we don't really have one that uses it.

If the batch is hidden by default, are there still "duplicate" generate barcodes and use checkdigit boxes? I am only seeing the 2 of them, and if one is hidden by default, do you still need the other? We don't currently have either of these on the screen, although they are both checked in my current "Defaults" tab, I don't remember their purpose. I don't see either of those in the new "Preferences" tab.

Other things I noticed:
Didn't we talk in the meeting about being able to hide the item # as well as the prefix or suffix if you don't use those fields? I seem to remember some discussion somewhere about being able to hide anything you didn't use that was taking up space on your screen to make what you did use fit better.

I noticed that there are still menu choices for edit call numbers, edit call numbers and items, and edit items, but they all give you both options on the 2 separate tabs. The only difference I noticed is that edit items opens it to the item attributes instead of the holdings.

When you are editing the holdings, can you still change the owning library? It is SO much quicker to change it there than transferring the item and/or call number to a different location when the item is remaining on the same bib record. We JUST got that communicated to everyone last week, it would be a shame to lose it again.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks for the feedback, everyone!

Some responses for Chrisy:

I. The batch editor does pull the call number from the bib record. It's not selected by default, but it's in the drop-down.

II. It is possible to hide the Item Number field via preferences.

III. The edit option selected affects both which tab is focused by default and which, if any, items are loaded for editing. 'Edit Call Numbers' only ever loads the call number itself and no items for editing -- though in this new interface, you can still add items from the 'Edit Call Number' action.

I think we could, however, coalesce the 'Add Call Numbers' and 'Add Call Numbers and Items' into a single action, since they do the exactly same thing in the new interface.

IV. You can change the owning library in the Item Attributes tab. It can be done for all call numbers at once or a subset. You can also configure owning library changes to automatically propagate to the item circulating library via Preferences.

Revision history for this message
Bill Erickson (berick) wrote :

Here's a new branch with Jane's suggestions.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v4

Some other tweaks/questions:

* I moved both Use Checkdigit and Generate Barcodes to the bottom row of actions, since they are tightly linked.

* I added the ability to hide the 'Parts' column.

* One commit addresses Andrea's comments about holdings not getting properly refreshed after update in certain scenarios.

* Misc. bug fixes included

* I did not add the minus button just to the right of the Owning Lib shortname, since I was not sure of it's intentions: remove that specific call number, similar to the minus to the right of the Suffix column -- or remove all visible call numbers for that org unit. Wondering if we need the minus option at all here.

Revision history for this message
Mike Rylander (mrylander) wrote :

This looks really good!

Unfortunately, when I click Save on the Item Attributes tab, it ... doesn't. It does reload the screen, but the values are unchanged. No errors in the console, nor in the logs. I don't actually see a save hitting the server in the osrfsys.log file.

Revision history for this message
Elaine Hardy (ehardy) wrote :

Mike,

Welcome to our world....

While it may be a bug within angular, it is not unusual to have save/exit silently fail. There are any number of reasons why this can happen from a holding template failing to having an empty input well for a call number or an item, to a duplicate barcode entered. Since the holdings editor closes, you have to start all over and hope you don't make the same mistake again.

Revision history for this message
Bill Erickson (berick) wrote :

Hey, thanks Mike. What fields did you modify? It's saving consistently for me. Maybe certain types of edits are problematic.

Revision history for this message
Mike Rylander (mrylander) wrote :

Hi Bill,

I tried some simple ones like Copy Number, and also tried a stat cat (separate edits). This was all from the Edit Items option on the (also very pretty) Holdings View on the record, selecting all the items on the concerto Harry Potter record to edit as the admin user.

I was watching the dev console and the logs and neither gave any indication that a copy update call of any sort was going to or hitting the server, but there were no errors in either.

Revision history for this message
Mike Rylander (mrylander) wrote :

And an update!

Now, after some more testing (and logging out and back in) it's working fine for me. Could have been some Ang caching, or other weirdness, but it's working now.

There's one thing I can't get it to do -- remove statcat values from copies. Galen reports the same, and the dev console says this:

Attempt to apply stat cat value which does not exist.
                This is likely the result of a stale copy template.
                stat_cat=1 entry=undefined

Looks like that action (using the Clear button) may need a special case?

Thanks, Bill!

Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Galen Charlton (gmc) wrote :

Another thing I noticed: changing the owning library from the attributes tab doesn't seem the work. Saving one or more items with such a change will create additional acns, but the items themselves don't get moved as appropriate.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks Mike and Galen. Here's a rebased branch which fixes the two issues noted:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v5

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Revision history for this message
Mary Llewellyn (mllewell) wrote :

Question: can we no longer add a part within the holdings/attribute editor? If not, why not?

And apparently we're going back to having to click Apply to each changed field. That's too bad. Clearly this design was to mimic the V/C editor in XUL. I like the V/C editor in 3.1 and regret seeing the old design return.

Revision history for this message
Mary Llewellyn (mllewell) wrote :

I can't find the box for Use checkdigit. I would hope to see it near the "Print Labels?" box.

Revision history for this message
Bill Erickson (berick) wrote :

Hi Mary,

Regarding parts, it's not intentionally omitted. That's functionality I was unaware of. I'll look at that.

Can you please clarify "having to click Apply to each changed field"? Are you referring to the Apply/Cancel/Clear options in the item attributes tab?

Revision history for this message
Elaine Hardy (ehardy) wrote :

In holdings view, there needs to be a column for every attribute so that we can check it without having to go into the holdings editor to see the value. This includes loan duration and fine level, which were in XUL. I would like to see stat cats as well but that wasn't something we had before.

Revision history for this message
Bill Erickson (berick) wrote :

Mary, for 'Print Labels', it's coupled with 'Hide Generate Barcodes' preference. I assumed they were tightly linked, but I can decouple those so they are each controlled by their own preference.

Thanks Elaine, would you mind opening a new LP for fields missing from the Holdings view in the staff catalog?

Revision history for this message
Elaine Hardy (ehardy) wrote :

I missed these 2 when I opened https://bugs.launchpad.net/evergreen/+bug/1892077, Should I open yet another bug report or add to 1892077?

Revision history for this message
Bill Erickson (berick) wrote :

Preferably yes, Elaine, since it relates to a separate interface and the other LP is already marked committed.

Here's a rebased branch that adds on-demand copy parts back to the interface. It also decouples the preferences for displaying the autogenerate button and the use-checkdigit checkbox.

It also includes a fix to a regression in the combobox that sneaked in with bug #1850547.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v6

Revision history for this message
Chrisy Schroth (cschroth) wrote :

Bill, thanks for your responses in comment #25. Regarding reply item I. The batch editor only pulls the $a of the 092. It needs to pull both the $a and the $b of the call number into the drop down. As I said, I no longer remember when this ability was lost.

I agree with Mary, I would just like to choose what I want from a drop down and have it select it (and turn the box green) without having to click apply for each field I am changing. I do use a lot of templates, so that will cut down on the number of times I have to click apply, but generally it is a lot of extra clicking. I also hope that with the change in interface, the templates will migrate, but I don't hold out much hope, as I think I pretty much had to recreate them all when we migrated from XUL to the web version.

Otherwise things seem to be working as I expected. Once I figured out that there were multiple items with the same barcode in this system, I was able to change owning and circulating locations for a single item, add a part, change a barcode, change a call number, add a call number and item, hide fields in the preferences, etc.

I didn't notice it at first, but I really do like the check box for Unified Holdings and Item Attributes Display. I think that will be helpful to our staff.

Revision history for this message
Bill Erickson (berick) wrote :

Hi Chrisy,

The batch call number options come from the default classification scheme, specified either in the Preferences tab of the copy editor or via the "cat.default_classification_scheme" org unit setting. The value there is mapped to one of the values in the database table asset.call_number_class, which can be configured at web staff URL:

/eg2/staff/admin/server/asset/call_number_class

Note the "Call Number Fields" column defines which MARC fields and subfields are used to extract MARC call numbers.

--

Regarding the return of the 'Apply' button, there are cases where it's helpful, specifically when editing batches, and cases where it's necessary, when editing subsets of batches of items. Arguably it's not necessary when editing a single item. I will note however that the UI is very keyboard-friendly. You can eliminate a lot of clicking with just Tab and Enter keys, both to initiate editing a field, and to Apply the result.

One potential middle-ground option is to display the field inputs by default when editing a single item, instead of displaying summary counts. That removes one of the actions -- initiating edit mode -- from each field edit. Applying the value would be as simple at Tab->Enter. It's not exactly the same, but closer.

--

I can't comment on the XUL copy templates, but the the AngJS copy templates will migrate. The ones I've tested so far work as expected.

Thanks for all of the input and feedback, everyone!

Revision history for this message
Galen Charlton (gmc) wrote :

I'm not a fan of the 'Apply' button in the case of editing single items and suggest some experimentation to see if the multi-item and subset-of-multi-item could do without it, but in any event, if it does get retained in whole or in part, I think there's a related UI issue to deal with.

Specifically, if a change has been made to a field but not applied, currently the volume/copy editor will let you hit the save button and silently discard any unapplied changes to a fields. Either dirty-but-unapplied fields should stop the form from submitting, or they should be automatically applied when the form is submitted.

Revision history for this message
Elaine Hardy (ehardy) wrote :

If the form is stopped from submitting, please have an error message indicating item(s) couldn't be saved and give users the opportunity to correct the errors and re-save. The editor fails silently now and having another silent fail would not be helpful.

I am also not a fan of the "Apply" button, from the standpoint of time. With the work I personally do, it isn't an issue one way or the other; but, I can see where someone actively cataloging would not want to have to take time to apply each attribute they edit.

Changed in evergreen:
milestone: 3.6-beta → 3.next
Revision history for this message
Mary Llewellyn (mllewell) wrote :

I'm not seeing a button for creating an item note (public or otherwise).

Also, the fields in Add item tag both say "Select item type." I would expect the second box to say something like "Enter tag label" as it does in the traditional volume/copy editor.
See attached.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks for the feedback, everyone. Looking at these now.

Regarding the Apply, how does everyone feel about the XUL-style display where it shows the value counts by default instead of the form input for changing the value? In other words, the way you have to "activate" the field to change its value?

Another purpose of the Apply button is to indicate when the edit action for a field is complete, allowing the display to return to the value counts/summary view. (It could be based on watching the onchange of the input, but I worry that would lead to a lot of unintended field edit deactivations). If we lose the Apply, we have to reconsider how/where the summary counts are displayed.

I'll note one of the decisions leading to the current implementation was our staff wanted the summary counts to be visible on page load instead of hidden in drop downs. We could go back to that, but I suspect others may like the return of the up-front summaries -- correct me if I'm wrong!

We could display the summaries AND the form inputs. Would that be too busy?

Revision history for this message
Bill Erickson (berick) wrote :

New rebased branch pushed with support for Item Notes, Item Tag placeholder text repair, plus an entry point in the staff catalog holdings tab for managing item notes. Other changes pending feedback.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v7

Bill Erickson (berick)
Changed in evergreen:
milestone: 3.next → 3.7-beta
Revision history for this message
Bill Erickson (berick) wrote :

Rebased branch pushed with an additional commit that adds support for an unsaved-changes warning/confirmation.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v8

Revision history for this message
Bill Erickson (berick) wrote :

Just a note we are using this branch in production now and it's going well. Since my last LP comment I have pushed 5 more commits (same v8 branch) to address bugs and better detect pending changes for navigation-away warnings.

Revision history for this message
Blake GH (bmagic) wrote :

Beill,

Loading this patch for feedback fest - I found that

src/app/staff/catalog/record/holdings.component.html

Still had calls to the old function
openItemNotes($event, 'create')"

with two arguments. It looks like you've usurped that old function name with a newly created function (with the same name) - and there was still a leftover "old" function call, with two arguments.

Bombed in ng build --prod

ERROR in src/app/staff/catalog/record/holdings.component.html:122:40 - error TS2554: Expected 1 arguments, but got 2.

122 (onClick)="openItemNotes($event, 'create')">
                                           ~~~~~~~~

  src/app/staff/catalog/record/holdings.component.ts:87:16
    87 templateUrl: 'holdings.component.html',
                      ~~~~~~~~~~~~~~~~~~~~~~~~~
    Error occurs in the template of component HoldingsMaintenanceComponent.

I fixed the code temporarily during feedback fest so that it would compile (removed the second argument 'create')

Revision history for this message
Blake GH (bmagic) wrote :

Sorry!

Beill/Bill

Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Revision history for this message
Michele Morgan (mmorgan) wrote :

Hi Bill,

Looking over this code, I notice that the stored copy templates is now a workstation setting (cat.copy.templates). Currently in the web client, the copy templates are a user setting (webstaff.cat.copy.templates).

Is this an intentional change from user setting to workstation setting? Having the copy templates linked to the user is by far preferable to our library staff members.

Revision history for this message
Bill Erickson (berick) wrote :

Thanks Michele, good catch on that one.

It looks like I misread the AngJS code. I saw references to hatch.setItem('cat.copy.templates') and getItem(...) and thought the templates were being stored in the browser storage, so I dutifully migrated them to workstation settings without realizing they were also stored in a user setting.

I can tweak the code to reference the existing user setting and remove the new workstation setting.

tags: removed: pullrequest
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

I have pushed a commit back to user/berick/lp1888723-angular-volcopy-v9 to address Michele's comments about the user setting.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: added: pullrequest
Revision history for this message
Jennifer Weston (jweston) wrote :

Unanimous approval by attendees of February Cataloging Working meeting for the functionality that Bill has in production in his library currently (and that was demonstrated for the group). The expansion feature for each attribute was loved by all.

One additional request: to have the libraries appear in alpha order

Thanks, Bill!

Revision history for this message
Bill Erickson (berick) wrote :

Patch pushed to user/berick/lp1888723-angular-volcopy-v9 to address sorting of org units when adding new call number orgs.

Revision history for this message
Michele Morgan (mmorgan) wrote :

Hi Bill,

Testing the latest branch, and seeing errors related to templates. There are remaining references to "cat.copy.templates" in volcopy.service.ts. Should all those occurrences be replaced with "webstaff.cat.copy.templates"?

Revision history for this message
Christine Morgan (cmorgan-z) wrote :

Hi Bill,

1. I tested adding a template on our test server and on https://bugsquash2.mobiusconsortium.org/eg/staff/. In both cases, after I created a template, when I went back to try and add holdings or edit holdings, the Holdings Editor would not load. Michele replaced "cat.copy.templates" with "webstaff.cat.copy.templates" (comment #58) on our test server and that problem seems to have been fixed.

2. There is an option in the current "Holdings Detail Default" (image attached) that allows you to include call number attributes in templates. I do not see the equivalent option in the "Preferences" tab in the Angular editor. This option also affects whether or not you see the call number attributes when creating/managing templates in Administration => Local Administration => Holdings Template Editor where our libraries do most of their template management. So it appears that it is not currently possible to have call number attributes in templates.

Revision history for this message
Erica Rohlfs (erohlfs) wrote :

Please excuse me if this issue is already known and buried in the discussions. Just noting that I filed a separate bug, https://bugs.launchpad.net/evergreen/+bug/1915555

However, testing with this patch shows the behavior as resolved (the item record tab saves and exits as expected with Bill's development work in this ticket)

Revision history for this message
Michele Morgan (mmorgan) wrote :

The current branch for this has a conflict when applied to current master since bug 1913219 was committed. The fix for 1913219 was meant to address the behavior that Erica describes above. I will mark 1915555 a duplicate of 1913219.

Bill, can you rebase your branch?

Revision history for this message
Bill Erickson (berick) wrote :

Can do, thanks Michele.

Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Revision history for this message
Bill Erickson (berick) wrote :

Rebased branch which adds support for disabling special copy statuses in the attribute editor. This is done with another commit that adds support for disabling entries in a combobox.

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v11

Revision history for this message
Jane Sandberg (sandbergja) wrote :

It looks great to me, Bill! Thanks for all your work on this. I signed off on it here: user/sandbergja/lp1888723-angular-volcopy-signoff

I also threw on another commit to change the term "Cost" to "Acquisitions Cost" (as it is in the AngularJS client) to distinguish it from the Price field.

tags: added: signedoff
Revision history for this message
Galen Charlton (gmc) wrote :

Taking this for final committer review.

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
status: New → Confirmed
Revision history for this message
Galen Charlton (gmc) wrote :

Some observations:

- If you edit an item and switch between the Holdings and Item Attributes tabs a round or two, the unsaved changes dialog appears even if you haven't made any changes. This looks like a side-effect of the change to avoid defaulting CN labels when editing a CN whose label is empty; ngOnInit should be invoking emitSaveChange() only when necessary in that case (which I guess means only if any of the labels are blank, although a further improvement might be to emit a different dialog that states that there's a data validation issue rather than unsaved changes).
- If the user hits the cancel button on the unsaved changes dialog, currently the changes-pending flag is cleared and the user can navigate away. Just double-checking that we want that behavior.
- Open the editor in add item mode, then click Generate Barcode: nothing happens. The Generate Barcode action seems to only start working if you add one more item in the holdings tab first.
- The item alerts, notes, and tags dialogs do not display existing values attached to the item. Is this intentional? Otherwise, that's a regression from the AngularJS volcopy editor.
- The currently contains references to both webstaff.cat.copy.templates and cat.copy.templates. Is one or the other intended?
- As a point of clarification, how are item templates supposed to be created? Create a new item, save it as a template, but don't save the item?

I think this is close, but the

Revision history for this message
Galen Charlton (gmc) wrote :

To finish my thought, I think this is close, but the potential regression regarding editing existing item alerts, notes, and tags seems to me to be a temporary blocker.

Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
tags: removed: signedoff
Revision history for this message
Elaine Hardy (ehardy) wrote :

- If the user hits the cancel button on the unsaved changes dialog, currently the changes-pending flag is cleared and the user can navigate away. Just double-checking that we want that behavior.

-----In 3.6.1, the options are "leave" or "cancel" when a user attempts to navigate from the holdings editor without saving. In this context, "cancel" should retain the edits and the holdings editor tab.

- The item alerts, notes, and tags dialogs do not display existing values attached to the item. Is this intentional? Otherwise, that's a regression from the AngularJS volcopy editor.

----- I was actually about to report this as a bug. Existing alerts, notes, and tags should display it the holdings editor, otherwise, they cannot be edited or removed. Note that existing alerts do appear from Action menu - Edit Item Alerts. I was about to start the research to report this. (https://bugs.launchpad.net/evergreen/+bug/1843087 may be related)

- As a point of clarification, how are item templates supposed to be created? Create a new item, save it as a template, but don't save the item?

-----Item/Holdings templates should either be created from the holdings editor, template tab or from Admin-local admin -- Holdings template editor. You no longer have to create an item to create or edit a template.

Revision history for this message
Michele Morgan (mmorgan) wrote :

Just noting that I'm also still seeing the behavior Galen describes in Comment 43: If a user changes multiple fields in the item, but only clicks Apply only one of those fields, the item will be saved with only the single Applied edit, and no warning about the loss of the other edits that were not Applied.

If there's still room for discussion re: the requirement to click Apply for every field change, I think it's worth exploring eliminating the extra Apply click where possible. Approaches (some previously mentioned) could be:

- Remove the field by field Apply requirement when editing a single item.
- Add an 'Apply All' button which would Apply all pending changes.
- Change the 'Save' button to 'Apply and Save', which would Apply all pending changes and Save the item.

Also, for reference, I'm attaching a file of the discussion of the Apply button, compiled from comments in this bug.

Revision history for this message
Elaine Hardy (ehardy) wrote :

I vote for removing the field by field apply requirement. It adds unnecessary time to editing.

My second option is to change the save and save and exit buttons to apply and save ti apply all changes and save or save and exit.

Revision history for this message
Beth Willis (willis-a) wrote :

I agree with Elaine.

Revision history for this message
Ted Peterson (devted) wrote :

git merge working/user/berick/lp1888723-angular-volcopy-v11

There were several merge conflicts with master so I didn't add this to our bug squash instance:

CONFLICT (content): Merge conflict in Open-ILS/src/eg2/src/app/staff/share/holdings/holdings.service.ts
- can fix by adding the new getMagicCopyStatuses() function.

CONFLICT (content): Merge conflict in Open-ILS/src/eg2/src/app/staff/catalog/record/copies.component.ts
-can *probably* fix by removing the this.openHoldingsEditor() function?
OR DID ANOTHER RECENT PATCH ADD THAT SO WE SHOULDN'T REMOVE IT?

CONFLICT (content): Merge conflict in Open-ILS/src/eg2/src/app/staff/cat/routing.module.ts
- can fix by adding the new volcopy() function.
Insert "}, {" after removing "=======" of course.

tags: added: needsrepatch
Revision history for this message
Michele Morgan (mmorgan) wrote :

Making a note that the UPDATE_VOLUME permissions issue described in bug 1920996 should be tested in this new interface.

Changed in evergreen:
milestone: 3.7-beta → 3.8-beta
Bill Erickson (berick)
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Revision history for this message
Bill Erickson (berick) wrote :

Here's a rebased branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1888723-angular-volcopy-v12

1. The 'Save' and 'Save & Exit' buttons now read 'Apply All & Save' and 'Apply All, Save & Exit'. It's no longer necessary to click Apply to apply each change.

2. When editing a single item, the Alerts, Tags, and Notes dialogs allow the user to modify existing data on the copy.

3. Removes ref to nonexistent workstation setting 'webstaff.cat.copy.templates'

4. 'Add Holdings' from the traditional catalog sends the user to the traditional holdings editor for internal consistency.

Galen, your question about creating templates, that's correct, the expectation is you edit a copy, apply the desired changes, add a template name, then save the template. Whether you also save the copy won't affect the template creation.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
tags: removed: needsrepatch
Revision history for this message
Ruth Frasur Davis (redavis) wrote :

When trying to add a holding for DB ID 27 (A companion to Mozart's piano concertos), I'm unable to go from the holdings tab to the item attributes tab without saving. When attempting to save, the save hangs up.

Using br1bbrown@BR1-rfrasur.

Revision history for this message
Mary Llewellyn (mllewell) wrote :

I combined the holding and item attribute tabs using the setting from the preferences tab, but when I tried saving my item, the Holdings Editor save just scrolled. When I tried to open an existing item, I got the same holdings editor scrolling display. I'm unable to do any item creation or editing at all from this point, even after logging out and signing back in.

tags: added: needsrepatch
Revision history for this message
Bill Erickson (berick) wrote :
tags: removed: needsrepatch
Revision history for this message
Ruth Frasur Davis (redavis) wrote :

When I go from one tab to another in the holdings editor, and there are parts for a record, an additional listing for the parts labels are added to the drop down. If I refresh, the second entry goes away.

Tested on DB ID 53 with admin@BR1-rfrasur.

Revision history for this message
Ruth Frasur Davis (redavis) wrote :

Other than that (and that could just be a weird browser idiosyncrasy), and noting that this a pretty huge ticket, I've tested this code (and really like how it's working), and consent to signing off on it using my name, Ruth Frasur, and email <email address hidden>.

Galen Charlton (gmc)
tags: added: signedoff
Revision history for this message
Galen Charlton (gmc) wrote :

As all of the feedback appears to have been addressed (except for Ruth's #81, for which I'll open a separate bug) I've merged this to master, along with a follow-up to eg-item-location-select to make contextOrgId be mutable for the sake of the new distribution formulas interface. That may also be useful as a follow-up to the volcopy editor, e.g., to make changes to the owning library (or circ library?) update the list of valid shelving locations.

My thanks to Bill and to all who have given feedback on this.

Changed in evergreen:
status: Confirmed → Fix Committed
Revision history for this message
Galen Charlton (gmc) wrote :

I've opened bug 1940010 for the parts selector issue.

Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.