Fix for Web Client Copy Editor Fix

[Jason Boyer]

Eg 2.12.6, 3.0
Sadly, the formatting code for bug 1713064 has an infuriating side effect. If you select the entire field or multiple digits of the cents and try to replace them by typing the toFixed() function is called immediately on keypress which can cause confusion about where the next keypress will go (usually the end, which will be ignored because anything after the second decimal digit is dropped...). Since this isn't that important and client side formatting is no replacement for server side verification, the fancy formatting function from that branch should be removed before any releases containing it reach the wild. Such a branch is coming soon.

[Jason Boyer (jboyer)]

Cleanup on aisle 5: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1714390_acp_input_number

[Andrea Neiman (aneiman)]

Testing on MassLNC Sandbox

When I tested this, I no longer see the cursor jump around as before; however, any value I save displays in the copy editor as only a whole number without decimals.

Example, I changed the price on item CONC4200058 to be 12.99. If I save the item & reopen it, the price field reads 12. This does not occur in a test system without this patch.

[Jason Boyer (jboyer)]

Andrea, can you verify that the HTML for those fields includes the 'step="0.01"' attribute? We're using that code in production here and aren't seeing that. (i.e. I change a price to 4.95, save it, and on editing it again it's still 4.95.) If they're not there it may be an incomplete patch?

[Jason Boyer (jboyer)]

Something that has just occurred to me, if you enter 0 cents (12.00) that will display only as 12 on opening the editor again. 12.00 would be ideal, but not technically data loss.

[Kathy Lussier (klussier)]

I can confirm that the 'step="0.01"' attribute is there, assuming Andrea is testing on mlnc3

[Kathy Lussier (klussier)]

Also (in case it wasn't clear), I looked in the database and it definitely is storing the price and/or cost as 12.00 when 12.95 is entered.

[Andrea Neiman (aneiman)]

Thanks for confirming the database side, Kathy! And yes, I was testing on mlnc3.

Noting for further data, on the same item & test server I set the Acq Cost for 12.95 and the Deposit for 5.99 and both of those appear to also not be saving the decimal values. I do see the step="0.01" attribute for both of those fields.

The EOLI server running 3.0 beta doesn't have this patch, and all price valuesare saving correctly despite the field-entry wonkiness from the 1713064 patch.

[Bill Erickson (berick)]

Unclear if this needs repatching or if it's just reacting poorly with other code. Removing pullrequest until confirmed and we have positive test results.

[Chris Sharp (chrissharp123)]

This has been identified by PINES catalogers as a web staff client blocker. Marking accordingly.

[Kathy Lussier (klussier)]

I'm going to re-add the pullrequest tag now since I think the problem I identified earlier should be fixed by the other, conflicting branch on bug 1712646. Testing this one now.

[Kathy Lussier (klussier)]

This works for me. I've signed off on it and merged it to master, release 3.0 and release 2.12.

Thank you Jason!