web client: copy templates created on XUL - Stat Cats that were unset

[Josh Stompro]

EG 3.3.4

We noticed when trying to move our cataloging staff to the web client that XUL copy templates that contain a value of -1 for a stat cat (to unset/clear that entry when the template is applied) are copied over to the new template format as a value of -1.

But when trying to apply such a copy template, it isn't possible to save changes because the -1 value gets sent as the actual value to save in the database, and causes a database error because that isn't a valid option.

I think that in the Xul client, the -1 was treated as a special value, that told the interface to unset that stat cat and clear it.

So for ease of migration, it would be nice if the conversion function cleared out those entries, so that copies with those templates applied will be savable. Or it would be nice if the function that applies the template would treat a -1 as an unset/clear operation.

The conversion work was done in bug #1691269.

My question to the catalogers list about this issue:
http://list.evergreen-ils.org/pipermail/evergreen-catalogers/2020-January/001465.html

Josh

[Josh Stompro (u-launchpad-stompro-org)]

Here is a branch that treats stat cat values of -1 just like null and blank lines. In my testing this allows the stat cats that were saved with an unset value in the XUL client to work correctly once converted to the webstaff client copy templates.

Branch at: lp1861732_copy_template_unset_statcat_values

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/stompro/lp1861732_copy_template_unset_statcat_values

Commit message:

LP#1861732 - Allow copy template stat cat unset value (-1)

Xul copy templates allowed the user to save an unset value for a stat_cat,
which was stored as -1 in the xul copy template. When those values are migrated
to the webstaff client copy templates, the -1 value is preserved. But that value
is passed directly to the database when saving a record, and -1 isn't a valid
value.

This change treats -1 the same as null or a blank line when applying the template, which
allows the template to unset a stat cat value like before in the XUL client.

Testing Notes:

1. Create some copy stat cats if they don't exist.
2. Clear out actor.usr_settings for the testing user, mainly the webstaff copy template key
  of 'webstaff.cat.copy.templates'.
3. In XUL client, create a copy template that includes setting a stat cat to the "<Remove Stat Cat>"
  value.
4. In the webstaff client, edit an item and try to apply the migrated copy template.

Before fix - you won't be able to save the copy after applying the template, it will
just silently fail. If you check the postgres logs you will see an error about trying
to set the stat cat value to -1.

After fix - You will be able to save the copy after applying the template, and if a value
for that stat cat was already set, it will be unset by the template.

Josh

[Elaine Hardy (ehardy)]

I am not sure this is testable without access to a XUL client Concerto database to create a template with a null statcat. I have a XUL client created template from PINES but I don't trust that it would be usable if I deleted everything PINES related. We had a lot of XUL templates fail in the webclient after they were edited. And they tend to fail if there are too many attributes set to null or too many set to default settings. I wouldn't trust any results from testing using a heavily edited template.

If someone has an item template they created to test something in a XUL client concerto database, that might work.

I also wonder if enough libraries have migrated to the web client to make this moot?

[Josh Stompro (u-launchpad-stompro-org)]

Elaine, I think you are correct, the XUL client is needed to create the test template. So this is more difficult to test, probably more trouble than it is worth. The boat has probably sailed on this one.

This is fix is very trivial.. if someone runs into it and finds this bug, they can apply it if they need it. I would agree that most sites probably just re-created their templates, or edited the templates to get rid of the the -1 values.

Josh

[Terran McCanna (tmccanna)]

I agree. I'll go ahead and mark this one "Won't Fix."