Webstaffclient: The copy editor no longer allows you to add a copy with a null price

[Jane Sandberg]

When I try to leave the price field blank when creating a new item, the item does not successfully create. This is 3.1.2 in the web client.

[Jane Sandberg (sandbergja)]

From our cataloger: "if you left the price blank [in the XUL client], it just went to "unset", in the [Web client] it makes the price 0.00"

[Beth Willis (willis-a)]

This is also true in Web client 3.0.9

I'm sure it is obvious, but when editing an item, if you change the price to null, the items does not save the edit(s).

[Jane Sandberg (sandbergja)]

Thanks for confirming, Beth. I believe that the behavior that our cataloger was seeing the saves-but-with-$0.00 behavior when applying item templates ported over from the XUL client.

[Jane Sandberg (sandbergja)]

Possibly related issue: https://bugs.launchpad.net/evergreen/+bug/1740527

[Jason Boyer (jboyer)]

This is because of a combination of things, beginning with the fact that the type attribute for these fields is number rather than text. Deposit and acq cost can cause the same issues, even though cost initially appears blank. (If you enter anything into the cost field and then empty it the save will fail for the same reason.) The real fix for this is to just stop using number and make all of these fields text with a validator to only allow entries that look like prices. Branch on the way. Something else that needs to be addressed sometime: there's obviously a part of the save process that assumes nothing can ever fail and blindly charges ahead with closing the window and losing your work.

[Jason Boyer (jboyer)]

To be more clear, the issue with nullable numeric values is that if we don't use something like str-to-float to convert the values between numeric and string values we get empty values on edit, and if we do use these directives we're not able to save an empty value because it's translated to the string "null" which causes the insert/update to fail. This branch just tells Angular that the nullable currency fields are just strings. The pattern directive requires that they be either empty, just numbers, or numbers + '.' + 2 more digits. (If there are i18n reasons to allow for more than 2 decimal places, the committer may want to change the patterns to accommodate.)

To test, pre-patch:
Create a new copy, and completely remove the price field (which you would do to use a default price), fill in any required fields and try to save. If you reload the holdings view you'll see that no item was created. Checking the DB logs will give you the following error: "invalid input syntax for type numeric: "null" at character ..." because the price field in the insert is literally price = 'null'.

post patch:
You will be able to save items with empty price (and cost or deposit amounts) fields without silent failures.

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

[Elaine Hardy (ehardy)]

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

[Galen Charlton (gmc)]

I tested, and while this solves the very specific problem of adding a new copy with empty prices (and costs and deposit amounts), it doesn't go far enough. Specifically, if you add a copy, touch the price field and then clear it in the editing session, or if you edit an existing copy and try to empty the price, saving the results will still fail silently as it tries set the price to the string "null".

Also, this patch will need master/rel_3_3 and rel_3_2/rel_3_1 versions nowadays.

[Jane Sandberg (sandbergja)]

Since the angular holdings editor allows an <Unset> price, I'm marking this as won't fix.