Copy Template Missing Values When Applied

[John Yorio]

Evergreen 3.0.6

Here is the behavior I'm seeing:

After creating a copy template, I apply it to a copy and when I do so, some fields do not show the value I had set on the template.

It does not appear to be consistent with respect to which fields don't appear - I have seen it happen with Circulation Modifier, Shelving Location, Holdable, Reference? and Opac Visible?

When this issue occurs, using the Console window in Chrome, I see the following error :

angular.js:14199 TypeError: Cannot read property 'filter' of undefined
at app.js:1149
at Object.q [as forEach] (angular.js:325)
at m.$scope.statcatUpdate (app.js:1118)
at app.js:1198
at Object.q [as forEach] (angular.js:339)
at app.js:1190
at Object.q [as forEach] (angular.js:339)
at m.$scope.applyTemplate (app.js:1184)
at fn (eval at compile (angular.js:15126), <anonymous>:4:355)
at b (angular.js:16213)

Steps to reproduce:

Unfortunately, I can't tell you what steps to take to easily reproduce the issue. It happens with some templates and not others, but I have been unable to discern a pattern that you can follow to make it happen.

There were two things I observed that might be helpful and so I'll put them here just in case:

1) The only time I could consistently get it to *not* happen was when I had no statistical categories for copies set up (not just on the template, but none on the Statistical Categories Editor screen), so it seems possible that you must have copy stat cats set up to reproduce this. However, you don't need to assign them any value in the copy template editor to have the issue occur.

2) While creating and testing various templates, templates would work fine in the session I created them, but if I closed the browser and came back in, the issue would occur with those same templates.

[Andrea Neiman (aneiman)]

Confirmed on 3.0.7 in the sense that I see the same erratic behavior, but I can't really add any useful details beyond what John has noted.

[Elaine Hardy (ehardy)]

John,

Thanks for reporting -- I have been trying to gather enough information on why it happens in order to report but it seems random.

PINES libraries have the same problem with copy templates. It happens for us whether or not stat cats are part of the template. They will work and apply as desired sometimes only once and other times for days. Then they stop applying correctly. Some of our libraries using the web client never have any issues with their templates and others have had to go back to the XUL client. Those with problems have deleted their templates and reentered in the web client but the templates work for a few times and then stop.

[[e-mail] (tji)]

We received reports on similar issues. Besides, there are reports on that values are not applied for one template, but after applying another template first, then applying it again, it works.

I also noticed some differences in two very similar templates. I wonder why sometimes those fields with null value are included in the templates. It seems happening intermittently. I can't see a pattern from my test and a few sets of templates submitted by our sites. I tried to create templates via both the admin menu and editing a real copy. No difference observed.

{"admin3":{"statcats":{"303":10615},"location":10034,"circulate":"t","circ_modifier":"1-day-loan"},

"copy1":{"statcat_filter":null,"location":10035,"opac_visible":"t","statcats":{"265":null,"303":10615},"circ_modifier":"1-day-loan"},

[Jeff Davis (jdavis-sitka)]

I suspect that bug 1773249 is related.

[Jeff Davis (jdavis-sitka)]

... Or maybe not. At least one other site has had reports of the copy template dropdown being empty, correlated with the NOT CONNECTED errors on retrieving templates from the other bug, but that site has not been getting reports of the issue in this bug.

[Jeff Davis (jdavis-sitka)]

One problem with copy templates is that they don't fully apply when the template has null statcat values but a non-null statcat filter value. I've pushed a fix for that:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1772062-copy-templates-null-stat-cats

I don't think this is the only cause of copy template problems, though.

[Jeff Davis (jdavis-sitka)]

Since the null statcat bugfix is only a partial fix for copy template woes, it has been broken out into bug 1788680. Other issues with copy templates still need to be addressed.

[Meg Stroup (mstroup)]

At this time, I am unable to reproduce the original bug. Given the bug's sporadic appearance, I may have simply had a run of luck.

I used multiple different templates, tried it with and without stat cats, and exited/re-entered the browser. [bug squashing week]

[Scott Thomas (scott-thomas-9)]

These intermittent and inconsistent template issues are a big inconvenience for us at 3.1.5. Here is a screen cast of one of them: https://kmetzm-parklandlibrary.tinytake.com/sf/Mjk2ODQxOF84OTA1OTQy
In this instance the template is not applied at all. We have also seen instances of it being applied, then not saving.

[Meg Stroup (mstroup)]

SCLENDS is also experiencing this problem on 3.1.5 and, as others have said, it's a significant cataloging issue.

We have not observed any pattern regarding the error: it's sporadic. However, most of our county systems have reported that this bug affects them.

At this library, we tested making new templates to see if a native web client template would function more consistently. We tried this on the workstation of a cataloger who has never used templates before (meaning she had no historical templates attached to her workstation, so there was no collision of template names). We created 3 templates, and all 3 malfunctioned (empty values) on the day they were created and have continued to do so.

[Elaine Hardy (ehardy)]

We have had a number of templates brought into the web client fail that have the phrase HACK:KLUDGE:NULL. A new template in the web client would eventually get overwritten by the old one from the XUL client. deleting the XUL client one and then recreating in the web client has been successful for those templates exhibiting that issue.

We have also noticed that if a template is set up with the shelving location that belongs to another branch, when it is applied, the shelving location does not appear to populate, but, if the save & exit button is activated, then you can save the item(s) successfully. Since we have a script (or some magical thing) that immediately runs and checks shelving location ownership against the circ library, that is corrected on save (provided that the shelving locations are named the same -- Reference to Reference).

Meg, is it the shelving location that doesn't populate? And did you check to see if the copies can save and do so successfully? Sometimes the save & exit button is active but clicking on it does nothing.

[Meg Stroup (mstroup)]

Elaine,
It's hit-and-miss on what doesn't populate. Shelving location is a popular one, but we also see status, and circulate as type.

There's been at least one report of a cataloger trying to fill in an empty field (that should have been populated), but they were unable to get to a drop-down.

It does appear (as far as we can tell) that the copies do save correctly, even if, as you say, the template didn't appear to be correct. The catalogers are nervous about this, though, because they're afraid that it really will fail to save correctly on save & exit.

[I apologize if this sounds tongue-twisted; I've been talking about templates all morning.)

[Elaine Hardy (ehardy)]

Meg,

Templates in the XUL client are much more forgiving than those in the web client.

One thing I have noticed is that, if a template is created with a default set to the default value (status as In Process, for example), then the value in the editor will not necessarily display but will apply. Defaults aren't as obvious in the web client. My findings:

    Circulate?: Yes/True
    Status: In process
    Circulation library (if single volume added; from owning library)
    Reference?: No/False
    OPAC Visible?: Yes/True
    Holdable?: Yes/True
    Quality: Good (PINES has not implemented)
    Copy status: in process
    Circulation Library (Populates from workstation library, will need to change if Templates is for specific branch. If used for adding multiple volumes for different branches/libraries leave the value in editor <unset> so that the Circ library will populate from owning library for each branch/library)
    Fine level: normal
    Duration: normal

If you are using the default values, it isn't necessary to include them in a template. I don't think it breaks the template, they may just not display 100% of the time.

An aside --- if you use circ modifiers, you don't need to use circ as Type. That attribute is for use in conjunction with using MARC fixed field Type for circ rules and is for when you want the item to circ differently. For example, if a book and accompanying CD are cataloged as Type: a (language material) and you bundle them together and want them to circ as a kit -- Circ as type would be set to kit. I don't see where using them with circ modifiers would cause issues with a template applying, however.

We have observed that when a template fails, for whatever reason, it will not apply many of the settings. Or will apply them incorrectly. In those cases, you can't successfully save & exit, even if the tab closes, items won't be created. And once the template fails, it never works again.

I don't recall whether I have had problems with the dropdown menu with a failed template. It does sound familiar but I don't do enough live cataloging to recall. I mainly do testing and database cleanup.

Since we have also observed that a successfully applied template will not always display some of the attributes, it is unnerving to go ahead and save. I have my columns in Holdings View set up so that I can see most attributes but since there is not room enough in the grid to really see them it can take time to verify they are correct.

[Meg Stroup (mstroup)]

Elaine,

I agree about the XUL templates being more forgiving.

The major concern here remains fields not visibly populating. When the fields for a template aren't displaying, catalogers are manually adding whatever missing/not-visible data, which slows down workflow.

I am also not seeing a lot of these issues firsthand: I coordinate cataloging for this consortium and do not do much live cataloging. I also noticed that circulate as type isn't a necessary value and is likely unique to that library system.

Thank you very much for your response. I'm going to share it with the cataloging listserv and see what feedback I get.

[Andrea Neiman (aneiman)]

Removing pullrequest since the patch provided only addresses null stat cats, which was broken out in bug 1788680 with its own pullrequest.

[Evergreen Bug Maintenance (bugmaster)]

Removing milestones for lack of a pull request for this bug.

[Andrea Neiman (aneiman)]

SCLENDS has signed a contract with Equinox to address this bug.

[Jason Stephenson (jstephenson)]

We received the following bug report on our internal ticket system this morning. This bug looks like the closest candidate, so I am adding it here:

"I recently added a new template to my list and now all my other templates are not active. They show up in the list but the identification information is not specific to the template. I click apply and nothing changes except when choosing the new template that i added."

[Elaine Hardy (ehardy)]

Jason,

I have had this happen. It usually corrects if I clear the cache, log out, close the browser, then log in again. Sometimes, I have to reboot to get it to correct.

[Linnae Cintron (freedom452001)]

This is still a problem for me. At the conference I was told to re create my templates but even when I did that as of yesterday they did not always work in the Web Client. In XUL this is not an issue. I've tried clearing my cache and rebooting. Not sure what all else to do.

[Linnae Cintron (freedom452001)]

I find that for example I can use my template for Adult Fiction which does work, apply that when I am adding an item, then click the template for example, Large Print Fiction, and then the correct attributes will for Large Print Fiction will then appear.

So basically I have to apply 2 templates in order to get the information I want to display.

[Elaine Hardy (ehardy)]

Linnae,

If you would like, email me your templates and I will see if I can spot anything that might be causing an issue -- <email address hidden>

Elaine

[Linnae Cintron (freedom452001)]

Ok thanks, Elaine.

[Dan Wells (dbw2)]

Personally, I think this bug is resolved by the changes on bug #1788680. The initially reported console errors are exactly what that change fixes. If anyone tries the code committed for #1788680, please be sure to clear cache, a hard refresh is not enough.

I propose this bug be marked as a duplicate, and if anybody has clear description of some other errant template application issues, those should be opened as separate bugs.

[Dan Wells (dbw2)]

Since no objections were raised, I am going to go ahead and mark this as a duplicate. Please undo if needed!