web client: default billing type price does not populate when there is already a value in the amount field

[Kathy Lussier]

In the web client, when you bill a patron, if you select a billing type with a default price, the number will not populate the Amount field it already had a value.

To replicate:

1. Create two billing types, each with a default price.
2. Go to a patron's bills tab and click to create a bill.
3. Select one of the new billing types. The Amount field will populate with the default price as expected.
4. Select the other billing type. The amount field does not change to the new default price.

My expectation is that the Amount field would populate with the default price whether or not there is a pre-existing value in that field.

[Lindsay Stratton (lstratton)]

Also if a billing type does not have a default amount associated, selecting it will not clear a previously selected/entered amount.

[Michele Morgan (mmorgan)]

Marking confirmed. In the xul client, the Amount field updates to the default_price for the selected billing type each time one is selected. If a billing type with NULL default_price is selected, the Amount box clears. The web client should behave similarly.

[Mike Risher (mrisher)]

Here's a branch with a fix:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrisher/lp1776757-billing-type-price

Updating the billing type now correctly updates the billing price. If there is no new default billing price then the field is cleared.

[Mike Risher (mrisher)]

The branch has been modified so that for the billing dollar amount shows 2 digits after the decimal. (e.g. "2.50" instead of "2.5")

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/mrisher/lp1776757-billing-type-price

[Terran McCanna (tmccanna)]

Works like a charm! My sign off is at:

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

[Galen Charlton (gmc)]

Upon reviewing the patch, I note that changing the type of the input (per comment #4) removes a bit of form validation: specifically, non-numeric values for the amount would be permitted to be submitted. Of course, the billing will fail to be saved, but it is a bit of extra untidiness.

I think more form validation would be better than forcing the display of two decimal places, so I've taken the liberty of pushing this with a follow-up that keeps the input as a number. This is now in master, rel_3_5, and rel_3_4. Thanks, Mike and Terran.

It would be possible to have our cake and ensure that the input displays two decimal places when a default price is applied, but that would require either a customer validator or use of ng-currency. I'll leave it to somebody else to file a bug if they choose to work on it.