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

Bug #1789982 reported by Jane Sandberg on 2018-08-30
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned
3.1
Undecided
Unassigned
3.2
Undecided
Unassigned

Bug Description

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 (sandbej) wrote :

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) wrote :

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).

Changed in evergreen:
status: New → Confirmed
Jane Sandberg (sandbej) wrote :

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.

Jason Boyer (jboyer) wrote :

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) wrote :

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

Jason Boyer (jboyer) on 2018-10-19
tags: added: pullrequest
Elaine Hardy (ehardy) wrote :

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

tags: added: signedoff
Michele Morgan (mmorgan) on 2019-04-16
Changed in evergreen:
milestone: none → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers