Angular Holdings Maintenance does not successfully retrieve AngularJS item templates

[Galen Charlton]

The new Angular Holdings Maintenance / Item Attributes Editor does not correctly fetch item templates that were created in the AngularJS volume copy editor.

In particular, what it tries to do is:

- fetch cat.copy.templates from local storage
- save the templates as a new server-side user setting, also keyed as cat.copy.templates

However, this fails because "cat.copy.templates" is not currently defined as a user setting type.

It should be noted that the AngularJS editor does this:

- upon opening the interface, checks to see if local copy templates have be downloaded
- if not, fetches them, checking the webstaff.cat.copy.templates and staff_client.copy_editor.templates user settings
- If webstaff.cat.copy.templates ones are found, those are cached in local storage under the key cat.copy.templates
- if staff_client.copy_editor.templates templates are found, those come from XUL, so the AngularJS editor first converts them to the webstaff.cat.copy.templates form.

Consequently, there are some possibilities to consider:

- If no cat.copy.templates user settings are present, but there are webstaff.cat.copy.templates ones, have the DB upgrade change the key, as there's no difference in format. However, doing this would also mean double-checking whether anybody that was quick to upgrade to 3.8.0 might have both.
- Have Angular check both keys from user settings, then handle the conversion, explicitly ignoring anything in local storage keyed with cat.copy.templates.
- Consider bringing the XUL item template conversion routine over into Angular; it's not beyond the realm of possibility that somebody might jump from the XUL volume copy editor to the Angular one.

Evergreen 3.8.0

[Elaine Hardy (ehardy)]

During testing on PINES servers, Holdings editor is not loading from Holdings view. Console message, if this helps is:

main.8224bc24f26fd2140d2a.js:1 ERROR Error: Uncaught (in promise): No user or workstation setting type exists for: "cat.copy.templates".
Create a ws/user setting type or use setLocalItem() to store the value locally.
    at T (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at T (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at polyfills.9b26e9b6c6d2049cc2b1.js:1
    at l.invokeTask (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at Object.onInvokeTask (main.8224bc24f26fd2140d2a.js:1)
    at l.invokeTask (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at i.runTask (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at m (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at u.invokeTask [as invoke] (polyfills.9b26e9b6c6d2049cc2b1.js:1)
    at p (polyfills.9b26e9b6c6d2049cc2b1.js:1)

[Elaine Hardy (ehardy)]

To see if this would be a viable workaround. I deleted cat.copy.templates in work station -- stored user preferences. Holdings editor did load. However when I imported my saved AngularJS templates exported from 3.6.1, cat.copy.templates was created in stored preferences and the holdings editor didn't load. So importing the angular-js templates doesn't create the webstaff.cat.copy.templates setting either.

[Elaine Hardy (ehardy)]

I tried deleting cat.copy.templates -- the holdings editor loads.

I then created a new template, then tried to access the editor from holdings view. It didn't load and there is a cat.copy.templates file again in work station stored preferences.

Should this be a separate, related bug report?

[Lindsay Stratton (lstratton)]

FWIW, I submitted a bug report for the duplicate cat templates settings locations: https://bugs.launchpad.net/evergreen/+bug/1948709

This also poses a problem in earlier versions (I found this in 3.6), where staff access Evergreen through VDI environments, so "in browser prefs" are very problematic alone, and dueling settings storage cause a number of retrieval issues.

[Terran McCanna (tmccanna)]

I'm bumping this to "Critical" because it is a big obstacle to our plans to upgrade to 3.8 in January.

[Bill Erickson (berick)]

Looking at the first 2 of Galen's suggestions for now. Branch on the way.

[Terran McCanna (tmccanna)]

Thank you to both Bill and Galen!!!

[Bill Erickson (berick)]

Let me know if this sounds sane:

* If a site has the AngJS "webstaff.cat.copy.templates" setting and does not have the new "cat.copy.templates" Angular setting, rename the setting type and setting entries to "cat.copy.templates".

* Modify AngJS editor to use "cat.copy.templates" instead of "webstaff.cat.copy.templates" so it will still have access to the templates if needed under the new setting name.

* If a site already has both the Angular and AngJS settings, don't do anything. My concern with auto-magic migration in the UI is that users may not want the old data from AngJS if they have started using the Angular editor. Or they may. It's not obvious.

I'm assuming the case where sites have already manually created the "cat.copy.templates" will be rare. We could add an upgrade note saying to remove the manually created "cat.copy.templates" setting type and entries IF you want the SQL upgrade to recreate it with all of the old templates copied over.

[Elaine Hardy (ehardy)]

I don't know enough about Angular to comment beyond saying that as long as the existing templates form 3.6 (for PINES) convert and are usable in 3.8, please.

[Elaine Hardy (ehardy)]

from 3.6, not form....

[Bill Erickson (berick)]

It just sunk in for me that "webstaff.cat.copy.templates" is a user setting and "cat.copy.templates" is a workstation setting. Reassessing...

[Bill Erickson (berick)]

OK, right, it doesn't really matter if it's a user or workstation setting. We just have to pick one.

Since AngJS "webstaff.cat.copy.templates" is a user setting, we can rename it as proposed above and everything should just work.

[Bill Erickson (berick)]

Working branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1951162-angular-copy-template-settings

From the commit:

Rename the user setting "webstaff.cat.copy.templates" to "cat.copy.templates" and migrate any existing values. This operation is not performed for any databases where a "cat.copy.templates" user or workstation setting type already exists.

Teach the Angular copy editor to avoid looking up templates in local storage, since only XUL templates are stored there, which are not compatible.

---

This does not include my previously mentioned upgrade notes. Hoping to make sure this provides a good general solution first.

[Elaine Hardy (ehardy)]

Chris applied the fix to our test server with 3.8

I was able to successfully open the holdings editor and apply existing templates created in 3.6 (yeah!!)

However, I was not able to successfully create a template in Local Admin -- holdings template editor.

I created the template and it showed in the list in the holdings template editor. But, when I went to the holdings editor, the new template was not listed. (using Chrome) I cleared the cache and still no template. Logged off and back on and the new template is no longer listed in admin holdings template editor nor is it in the templates in holdings editor.

[Elaine Hardy (ehardy)]

I am also not sure that all the existing templates are transferring. I reimported a file and not all are listed in the holdings editor that are listed in the admin holdings template editor. Doing more testing for more info

[Elaine Hardy (ehardy)]

Attached are screen shots of the lists of templates in holdings editor and the template editor after I imported a file of templates into 3.8.

The list in the template editor has the all the templates in the file. The template editor doesn't always. And when I log out and back in, the templates listed in the template editor is the shorter one

I can attach the file if you would like to see it.

[Elaine Hardy (ehardy)]

I was referring to the file of templates if you need to see those

[Bill Erickson (berick)]

Thanks for testing, Elaine

Not quite sure what's going on. I was able to create a template in Local Admin -> Holdings Template Editor and have it appear in the new Angular editor. (Note, it wasn't working for me either until I remembered I also had to rebuild / reinstall the AngJS parts).

Also beware the Holdings Template Editor is essentially deprecated, since the expectation is templates will be created / saved directly in the Angular holdings editor once you start using the new holdings editor. I would expect them to (mostly?) work together for now, but that likely won't be guaranteed over time. Plus, it will eventually be removed, since it's AngJS. Unknown if an Angular version will be created.

TODO: Indicate that information in release notes, etc.

[Elaine Hardy (ehardy)]

Please do not do away with the holdings editor. Catalogers requested and still need a way to edit, create, import and export holdings templates outside of an individual record. We had to do that before -- pull up a record and the holdings editor in order to maintain templates. Catalogers need to maintain templates when they aren't performing cataloging functions and it is inefficient and time consuming to always have to go through the holdings editor. Removing the holdings template editor will be a step back for us.

I will ask Chris about rebuilding/reinstalling Angular JS

[Elaine Hardy (ehardy)]

Chris rebuilt Angular JS and I was able to create a template successfully in 3.8.

We have started testing for 3.8 with our libraries so I should have more feedback in the coming week. But this does appear to be working.

[Bill Erickson (berick)]

Thanks again for the input and testing, Elaine.

Before I open an LP on the Template Editor, I'm curious about the work flow. In particular, if there was a menu option / bookmark that took you directly to the attribute editor for an item -- it doesn't matter which item, since you don't have to save changes to the item -- would it be materially different than having a separate Template Editor?

For example:

https://HOSTNAME/eg2/staff/cat/volcopy/attrs/item/1

I get that modifying an item without really saving changes to the item itself just to affect a template seems odd, but you have all the tools you need in the attr editor to manage the templates. So I guess it's a question of priority. Is the one-interface approach where you pretend to edit an item just too weird?

[Elaine Hardy (ehardy)]

I get a server not found error for https://HOSTNAME/eg2/staff/cat/volcopy/attrs/item/1

Maintaining and managing item/holdings templates is independent of applying those templates to an item and should have a way to access the templates separate from an item. It isn't that it is weird to have to do it in the holdings editor -- it isn't efficient and takes more time.

Now, if I want to create, edit, delete, import, or export templates my workflow is:

1. Open holdings template editor at Admin -- local admin -- Holdings template editor.
2 a. Create template: Name the template, choose options, Save.
2 b. Edit a template: choose template from drop down list. Click apply. Make changes. Save
2 c. Delete template: Choose template from drop down list. CLick delete
2 d. Import templates: Click import, choose file from list.
2 e. Export templates: Click on export, Chose save location, name file, save.

If there is no separate editor:

1. Search for a bib record with my library's holdings
2. Go to holdings view (MARC view is my default since one should review the bib record before you add holdings, edit, etc.)
3. Choose an item and select edit item from Actions menu to open holdings editor to the item attributes tab. (if you have the unified call number/holdings option checked you can also choose add item)
4. See steps 2 a. through 2 e above.

The latter is what we had to do initially in Evergreen until the separate template editor was created. Having that template editor is beneficial to cataloging workflow. So much so that I wish we had a separate template editor for spine label printing

[Jennifer Pringle (jpringle-u)]

I second keeping the holdings template editor directly accessible. As Elaine says there are a lot more steps to access it if you have to go through an item.

I also love the idea of a way to directly access the spine label templates instead of having to always go through an item.

[Christine Morgan (cmorgan-z)]

A very strong +1 to keeping the holdings template editor directly accessible. It is simply not logical to have to pull up an item to create a template.

[Lindsay Stratton (lstratton)]

Another +1 to separate Holdings Editor and Holdings Template Editor.

*Lindsay Stratton*
*Systems Librarian*
Westchester Library System
570 Taxter Rd., 4th Floor
Elmsford, NY 10523
<email address hidden>

On Tue, Dec 7, 2021 at 4:45 PM Christine Morgan <email address hidden>
wrote:

> A very strong +1 to keeping the holdings template editor directly
> accessible. It is simply not logical to have to pull up an item to
> create a template.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1951162
>
> Title:
> Angular Holdings Maintenance does not successfully retrieve AngularJS
> item templates
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> The new Angular Holdings Maintenance / Item Attributes Editor does not
> correctly fetch item templates that were created in the AngularJS
> volume copy editor.
>
> In particular, what it tries to do is:
>
> - fetch cat.copy.templates from local storage
> - save the templates as a new server-side user setting, also keyed as
> cat.copy.templates
>
> However, this fails because "cat.copy.templates" is not currently
> defined as a user setting type.
>
> It should be noted that the AngularJS editor does this:
>
> - upon opening the interface, checks to see if local copy templates have
> be downloaded
> - if not, fetches them, checking the webstaff.cat.copy.templates and
> staff_client.copy_editor.templates user settings
> - If webstaff.cat.copy.templates ones are found, those are cached in
> local storage under the key cat.copy.templates
> - if staff_client.copy_editor.templates templates are found, those come
> from XUL, so the AngularJS editor first converts them to the
> webstaff.cat.copy.templates form.
>
> Consequently, there are some possibilities to consider:
>
> - If no cat.copy.templates user settings are present, but there are
> webstaff.cat.copy.templates ones, have the DB upgrade change the key, as
> there's no difference in format. However, doing this would also mean
> double-checking whether anybody that was quick to upgrade to 3.8.0 might
> have both.
> - Have Angular check both keys from user settings, then handle the
> conversion, explicitly ignoring anything in local storage keyed with
> cat.copy.templates.
> - Consider bringing the XUL item template conversion routine over into
> Angular; it's not beyond the realm of possibility that somebody might jump
> from the XUL volume copy editor to the Angular one.
>
> Evergreen 3.8.0
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1951162/+subscriptions
>
>

[Terran McCanna (tmccanna)]

PINES has confirmed the fix works in our 3.8 test environment.

I have tested this code and consent to signing off on it with my name, Terran McCanna and my email address, <email address hidden>.

(Bill will open a new ticket with the remaining issues from the comments.)

[Bill Erickson (berick)]

Opened bug #1957115 to address the standalone copy template editor.

The patch for this bug specifically is still ready to be pulled. See comment 14 for successful test -- pending sign off.

[Mike Rylander (mrylander)]

I've merged Bill's latest, with Terran's signoff, to rel_3_8 and master for 3.9. Thanks, Bill, Terran, and all!