Description
Frédérick Capovilla
2013-12-10 22:09:11 UTC
Comment hidden (obsolete)
Excellent! I would like to note that the accounts rewrite ( Bug 6427 ) also has this feature. Kyle Created attachment 26103 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. Patch tested with a sandbox, by Joel Aloi <aloi54@live.fr> Created attachment 26108 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. Signed-off-by: Joel Aloi <aloi54@live.fr> I am worried about the changes to Accounts.pm. We need unit tests to go with this patch. Created attachment 29757 [details] [review] Bug 11373 - Unit tests for Accounts.pm I added unit tests for the modified subs in C4/Accounts.pm. makepartialpayment() WriteOffFee() modified: t/db_dependent/Accounts.t This last patch does not need a signoff (will be done by QA). I am sorry, but this doesn't seem to work for me. I have added various fines and fees to my patron account. Then I chose "Pay amount" and changed the collected from patron value to be higher than the total amount owed. I didn't see anything telling me how much change to give back to the patron. The open fines were paid and the additional money was 'lost'. The same happens for paying individual fines. Please retest. Created attachment 29938 [details] [review] Bug 11373 - Fixed: 'Change to give back' not displaying. I tested the last patch and found that the case 'amount oustanding == amount paid' was not handled in paycollect.p . The confirmation box should now appear when those values are equal and the amount collected is higher than the amount paid. I have found another problem while testing. When paying all fines or selected fines, the 'The amount collected is greater than the total amount paid.' message would appear even when the entered data was correct. Both issues were adressed in this patch. modified: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt modified: members/paycollect.pl Am I supposed to apply to all these patches? I got the following: Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 11373: Add a "cash register" feature to the fine payment form. /home/nengard/kohaclone/.git/rebase-apply/patch:242: trailing whitespace. $template->param( /home/nengard/kohaclone/.git/rebase-apply/patch:247: trailing whitespace. $template->param( warning: 2 lines add whitespace errors. Using index info to reconstruct a base tree... <stdin>:242: trailing whitespace. $template->param( <stdin>:247: trailing whitespace. $template->param( warning: 2 lines applied after fixing whitespace errors. Falling back to patching base and 3-way merge... Auto-merging members/paycollect.pl Auto-merging C4/Accounts.pm CONFLICT (content): Merge conflict in C4/Accounts.pm Failed to merge in the changes. Patch failed at 0001 Bug 11373: Add a "cash register" feature to the fine payment form. When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-11373-Add-a-cash-register-feature-to-the-fine--I0lypc.patch Created attachment 36875 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. Signed-off-by: Joel Aloi <aloi54@live.fr> Created attachment 36876 [details] [review] Bug 11373 - Unit tests for Accounts.pm I added unit tests for the modified subs in C4/Accounts.pm. makepartialpayment() WriteOffFee() modified: t/db_dependent/Accounts.t Created attachment 36877 [details] [review] Bug 11373 - Fixed: 'Change to give back' not displaying. I tested the last patch and found that the case 'amount oustanding == amount paid' was not handled in paycollect.p . The confirmation box should now appear when those values are equal and the amount collected is higher than the amount paid. I have found another problem while testing. When paying all fines or selected fines, the 'The amount collected is greater than the total amount paid.' message would appear even when the entered data was correct. Both issues were adressed in this patch. modified: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt modified: members/paycollect.pl Fixed the conflicts. Comment on attachment 36875 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Review of attachment 36875 [details] [review]: ----------------------------------------------------------------- Changing the sign of what was there before would need something done during upgrade to change it to a new way of processing. This wasn't done, so frankly, I think the logic I highlighted is broken. Though, admittedly, I did not run this code yet. ::: C4/Accounts.pm @@ +722,5 @@ > my $insert = 'INSERT INTO accountlines (borrowernumber, accountno, date, amount, ' > . 'description, accounttype, amountoutstanding, itemnumber, manager_id, note) ' > . ' VALUES (?, ?, now(), ?, ?, ?, 0, ?, ?, ?)'; > > + $dbh->do( $insert, undef, $borrowernumber, $nextaccntno, $payment, 0-$amount is the negative of $amount. This is a vast change! Is this correct? @@ +728,5 @@ > > UpdateStats({ > branch => $user, > type => 'payment', > + amount => $payment, This is 0-$amount which is the negative of what was put here before. @@ +739,4 @@ > action => 'create_payment', > borrowernumber => $user, > accountno => $nextaccntno, > + amount => $payment, On a positive note, by putting $payment earlier, it can be used nicely here. @@ +820,4 @@ > UpdateStats({ > branch => $branch, > type => 'writeoff', > + amount => $payment, Again, 0-$amount is negative of what was there before. Patch does not apply. Auto-merging members/paycollect.pl Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt Auto-merging C4/Accounts.pm CONFLICT (content): Merge conflict in C4/Accounts.pm Created attachment 60528 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. Signed-off-by: Joel Aloi <aloi54@live.fr> Created attachment 60529 [details] [review] Bug 11373 - Fixed: 'Change to give back' not displaying. I tested the last patch and found that the case 'amount oustanding == amount paid' was not handled in paycollect.p . The confirmation box should now appear when those values are equal and the amount collected is higher than the amount paid. I have found another problem while testing. When paying all fines or selected fines, the 'The amount collected is greater than the total amount paid.' message would appear even when the entered data was correct. Both issues were adressed in this patch. modified: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt modified: members/paycollect.pl I rebased the patches and now they apply properly. I removed the changes in the file C4/Accounts.pm since the sub makepartialpayment was moved and renamed to sub pay in Koha/Accounts.pm, the patch works fine with the new changes. I obsoleted the second patch which contained the tests for C4/Accounts.pm, because the module has it's own test files. I added a test plan everyone can test it. Test Plan 1) Apply patch 2) Select a patron with a fine. 3) Go to the selected details patron. 4) Go to the fines tab. 5) Click the button pay amount or pay selected. 6) Choose the amount paid equal to the outstanding amount(exemple : 3$). 7) Choose the amount collected to be more than the outstanding amount(exemple :5$) 8) Click the button confirm. - You should be prompted with a message saying : "Change to give back: 2.00" 9) Click on the button above Confirm payment. The selected patron should not have an outstanding fines left. Patch tested with a sandbox, by Candice Hope <candiceh@payson.org> Created attachment 61233 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. Signed-off-by: Joel Aloi <aloi54@live.fr> Signed-off-by: Candice Hope <candiceh@payson.org> Created attachment 61234 [details] [review] Bug 11373 - Fixed: 'Change to give back' not displaying. I tested the last patch and found that the case 'amount oustanding == amount paid' was not handled in paycollect.p . The confirmation box should now appear when those values are equal and the amount collected is higher than the amount paid. I have found another problem while testing. When paying all fines or selected fines, the 'The amount collected is greater than the total amount paid.' message would appear even when the entered data was correct. Both issues were adressed in this patch. modified: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt modified: members/paycollect.pl Signed-off-by: Candice Hope <candiceh@payson.org> It works. It looks perfects! Created attachment 67348 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. If the amount received is greater than the amount to pay, a message is shown to tell the employee how much money to give back. This obsoletes (both) previous patches that did not apply Created attachment 68296 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Created attachment 70043 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Necessary rebase to apply on current master Comment on attachment 70043 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Review of attachment 70043 [details] [review]: ----------------------------------------------------------------- I am wondering about the usability here. For paying a partial fine I am forced to manually edit 2 input fields which adds more steps for the busy circulation desk and also might cause more potential for errors. Maybe it would make sense to automatically change the amount collected to the amount paid when it's changed? Or to make this optional? I'd like to get some librarians to weigh in on these changes if possible. Some other small issues noted below. QA tools are clean. ::: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt @@ +98,5 @@ > </ul> > <div class="tabs-container"> > +[% IF (error_negative) %] > + <div id="error_message" class="dialog alert"> > + <span>The amount paid can't be negative!</span> Why the additional spans everywhere? A message inside a div should not need it (see also other cases below). @@ +175,5 @@ > + [% give_change %] > + </li> > + [% ELSE %] > + <li> > + <label for="paid">Amount paid :</label> No additional spaces between text and : please :) ::: members/paycollect.pl @@ +128,5 @@ > + elsif ($total_paid < $total_due and $total_collected ne $total_paid) { > + $template->param( > + amount_paid => sprintf('%.2f', $total_paid), > + amount_collected => sprintf('%.2f', $total_collected), > + give_change => sprintf('%.2f',($total_collected-$total_paid)) I am wondering about the formatting done in various spots in the patch. I'll ask a second opinion about that. Please note that we have a TT plugin for displaying prices in different ways and CurrencyFormat system preference (entering prices still happens with . ). > I am wondering about the usability here. For paying a partial fine I am
> forced to manually edit 2 input fields which adds more steps for the busy
> circulation desk and also might cause more potential for errors. Maybe it
> would make sense to automatically change the amount collected to the amount
> paid when it's changed? Or to make this optional?
>
> I'd like to get some librarians to weigh in on these changes if possible.
Another idea: leave the amount collected empty initially, meaning the amount paid equals the amount collected. And only have people enter an amount if that isn't the case. That means you could still collect payments without extra clicks needed as before, but when you need it use of the field will be easier as you don't need to ovrwrite/delete the amount in it first.
Created attachment 71975 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Created attachment 71976 [details] [review] Bug 11373: Follow-up after code review Hi Katrin, Following your comments, I made cosmetic adjustments to the previous patch: - <span> no longer present in alert dialog - I also toned down from 'exclamation mark' to a simple period - removed the dangling space before ':' - server side formatting was changed from sprintf to $Price - I also removed the formatting in the <input> fields. It made no sense to me that formatting was used for data traveling between the page and the server, unbeknown to the user. About the behavior of the form: I agree with you, the UX should definitely be more user-friendly. Now, I'm open to changes, but I'd rather implement everything once we reach a consensus on how it should behave than doing "flavors" of the same patch just for QA. Nothing personal ;) I'll put this back to 'Needs signoff', for now, just to make it clear that I want people testing this patch, but feel free to dial it back to "Failed QA" or "In discussion". I'll be keeping a close eye on this. > Following your comments, I made cosmetic adjustments to the previous patch: > - <span> no longer present in alert dialog > - I also toned down from 'exclamation mark' to a simple period > - removed the dangling space before ':' > - server side formatting was changed from sprintf to $Price > - I also removed the formatting in the <input> fields. It made no > sense to me that formatting was used for data traveling between the page and > the server, unbeknown to the user. Thx! > About the behavior of the form: I agree with you, the UX should definitely > be more user-friendly. Now, I'm open to changes, but I'd rather implement > everything once we reach a consensus on how it should behave than doing > "flavors" of the same patch just for QA. Nothing personal ;) > > I'll put this back to 'Needs signoff', for now, just to make it clear that I > want people testing this patch, but feel free to dial it back to "Failed QA" > or "In discussion". I'll be keeping a close eye on this. I totally agree with this approach. It might make sense to ask on the mailing list as well to get some attention on this. Created attachment 77584 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Created attachment 77585 [details] [review] Bug 11373: Follow-up after code review Created attachment 79122 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Patch did not apply. Rebased. Where is the commit message gone? Hi Blou, Great work. I've just some findings. Patch is working,but: - confirmation button has some formatting problem = https://prnt.sc/kwd2do - Cancel link is broken, without borrower number (http://localhost:8081/cgi-bin/koha/members/pay.pl?borrowernumber=) - this funkcnionaly should be optional, so weneed enable=disable it from administration menu Just two steps to heaven :-) Thank You Mike Created attachment 79171 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Fixed the rest, but for the padding in the button, we'll need to find another solution since an <input> under a class="dialog message" will show like that. Not sure why the staff.css specifies that padding, but clearly having a confirm button in a message dialog is not the standard Koha way. Created attachment 79188 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Signed-off-by: Michal Denar <black23@gmail.com> (In reply to Blou from comment #41) > Fixed the rest, but for the padding in the button, we'll need to find > another solution since an <input> under a class="dialog message" will show > like that. Not sure why the staff.css specifies that padding, but clearly > having a confirm button in a message dialog is not the standard Koha way. That is because you should have icon on that button - try to add a class="approve" to button. (In reply to Josef Moravec from comment #43) > (In reply to Blou from comment #41) > > Fixed the rest, but for the padding in the button, we'll need to find > > another solution since an <input> under a class="dialog message" will show > > like that. Not sure why the staff.css specifies that padding, but clearly > > having a confirm button in a message dialog is not the standard Koha way. > > That is because you should have icon on that button - try to add a > class="approve" to button. And add the icon itself like this: <i class="fa fa-fw fa-check"></i> The information on this page is duplicate: https://screenshots.firefox.com/o2GtPtGugLjtJSqq/localhost why do you even add the dialog? Also this could be enabled disabled, please add system preference for this. Comment on attachment 79188 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Review of attachment 79188 [details] [review]: ----------------------------------------------------------------- ::: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt @@ +75,5 @@ > + <div id="change_message" class="dialog message"> > + <span>The amount collected is greater than the total amount paid.</span><br /> > + <strong>Change to give back: [% give_change | $Price %]</strong><br /><br /> > + <input type="submit" name="submitbutton" value="Confirm payment" /> > + <a class="cancel" href="/cgi-bin/koha/members/pay.pl?borrowernumber=[% patron.borrowernumber %]">Cancel</a> use uri filter @@ +120,5 @@ > + [% IF ( give_change ) %] > + <li> > + <label for="paid">Amount paid:</label> > + <input type="hidden" name="paid" id="paid" value="[% amount_paid %]" /> > + <input type="hidden" name="collected" id="collected" value="[% amount_paid %]" /> use html filter @@ +134,5 @@ > + </li> > + [% ELSE %] > + <li> > + <label for="paid">Amount paid:</label> > + <input name="paid" id="paid" value="[% amountoutstanding | format('%.2f') %]" onchange="moneyFormat(document.payform.paid)"/> use $Price filter @@ +141,3 @@ > <li> > + <label for="collected">Collect from patron:</label> > + <input name="collected" id="collected" value="[% amountoutstanding %]" onchange="moneyFormat(document.payform.collected)" /> use $Price filter @@ +233,5 @@ > </li> > + [% IF ( give_change ) %] > + <li> > + <label for="paid">Amount paid:</label> > + <input type="hidden" name="paid" id="paid" value="[% amount_paid %]" /> use html filter @@ +238,5 @@ > + [% amount_paid | $Price %] > + </li> > + <li> > + <label>Collected from patron:</label> > + <input type="hidden" name="collected" id="collected" value="[% amount_paid %]" /> use html filter @@ +248,5 @@ > + </li> > + [% ELSE %] > + <li> > + <label for="paid">Amount paid :</label> > + <input name="paid" id="paid" value="[% total %]" onchange="moneyFormat(document.payform.paid)" /> use $Price filter @@ +259,3 @@ > [% END %] > <!-- default to paying all --> > + <input name="collected" id="collected" value="[% total %]" onchange="moneyFormat(document.payform.collected)"/> use $Price filter (In reply to Josef Moravec from comment #45) > The information on this page is duplicate: > > https://screenshots.firefox.com/o2GtPtGugLjtJSqq/localhost > > why do you even add the dialog? > > Also this could be enabled disabled, please add system preference for this. The dialog is here maybe to explain to the user why they are still on the page, because otherwise they just see a slight different formatted form when the change is not null. If the dialogue is not a matter but the duplication is, removing the "Change to give back:" line could be an option. What do you want to add to system preferences precisely? The whole feature with the change? Is that what you mean by "this"? Thanks for replying. (In reply to Pierre-Marc Thibault from comment #47) > (In reply to Josef Moravec from comment #45) > > The information on this page is duplicate: > > > > https://screenshots.firefox.com/o2GtPtGugLjtJSqq/localhost > > > > why do you even add the dialog? > > > > Also this could be enabled disabled, please add system preference for this. > > The dialog is here maybe to explain to the user why they are still on the > page, because otherwise they just see a slight different formatted form when > the change is not null. If the dialogue is not a matter but the duplication > is, removing the "Change to give back:" line could be an option. Yes, the duplication is problem for me, now it is a bit confusing. I think the form itself should not be there, only dialog with all the information and the amount to give back to patron should be emphasized. > What do you want to add to system preferences precisely? The whole feature > with the change? Is that what you mean by "this"? Yes, that's exactly what I mean, because this change the behavior of pay functionality. > > Thanks for replying. Not at all ;) I think simple is best. Instead of confirming on the form and the dialog and then paying, there should be a disabled input which shows the change each time a number input is changed. You get the change feedback instantly, just click once for paying and there is no duplication data on the page. The bug description is really misleading.. this doesn't add a cash register/till at all, rather it's just a method of displaying change to give. The commit should describe what the feature does. 'cash register feature' is not enough as its is ambiguous as to what kind of functionality you are adding. It might be better to handle this in javascript, theres no need to send to the server for this calculation it could all be handled more efficiently in the browser Created attachment 79507 [details] [review] System preference added, dialog removed, disabled input added to show the change in the form. This patch removes the dialog because it was redundant with the form. As the numbers fields are formated when they are changed, it is convenient to calculate and show the change at the same time. When the change value cannot be calculated (amount collected < amount paid), its value is brought back to 0.00. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$) - Confirm that the change is correct (example : 5$ - 3$ = 2$) - Click the button confirm. - Confirm that the payment has been made. - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the input change is gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Created attachment 79509 [details] [review] Bug 11373: System preference added, dialog removed, disabled input added to show the change in the form. This patch removes the dialog because it was redundant with the form. As the numbers fields are formated when they are changed, it is convenient to calculate and show the change at the same time. When the change value cannot be calculated (amount collected < amount paid), its value is brought back to 0.00. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$) - Confirm that the change is correct (example : 5$ - 3$ = 2$) - Click the button confirm. - Confirm that the payment has been made. - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the input change is gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Bug status put at Needs Signoff because many things have changed. Created attachment 79529 [details] [review] Bug 11373: Add a "cash register" feature to the fine payment form. Works as intended. Signed-off-by: Simon Pouchol <simon.pouchol@biblibre.com> Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Michal Denar <black23@gmail.com> Created attachment 79530 [details] [review] Bug 11373: System preference added, dialog removed, disabled input added to show the change in the form. This patch removes the dialog because it was redundant with the form. As the numbers fields are formated when they are changed, it is convenient to calculate and show the change at the same time. When the change value cannot be calculated (amount collected < amount paid), its value is brought back to 0.00. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$) - Confirm that the change is correct (example : 5$ - 3$ = 2$) - Click the button confirm. - Confirm that the payment has been made. - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the input change is gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. https://bugs.koha-community.org/show_bug.cgi?id=11373 Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Michal Denar <black23@gmail.com> I've asked Pierre-Marc to squash these, since the second patch is mostly useless, and the second one is mostly removing the first one's changes. I know how QA will appreciate looking at this, so he's going to do a new one that's easier to interpret (and will need sign off). My apologies to Michal who took the time already to sign it off. Created attachment 79538 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$) - Confirm that the change is correct (example : 5$ - 3$ = 2$) - Click the button confirm. - Confirm that the payment has been made. - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the input change is gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Created attachment 79549 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$) - Confirm that the change is correct (example : 5$ - 3$ = 2$) - Click the button confirm. - Confirm that the payment has been made. - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the input change is gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Signed-off-by: Michal Denar <black23@gmail.com> This should be further simplified. - if preference is set, UI should send to backend the exact amount, since we presume the change has been given back. - no need to overwrite the error_over behavior. It will be necessary when the pref is not set. - in fact, the modification to members/paycollect.pl are not necessary, imo. - if preference is set, make the change comment very obvious (color message?) - The patch should focus on the functionality. Do not rewrite all the format() to $Price if not related to the feature. This should be a separate patch. To consider: making the submit button have a confirm popup when change is to be given back. Not need to go to the backend for that. Created attachment 79759 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the inputs paid and change are gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. The code is simpler and the formating is only on new lines. The change comment is similar to the others and is not related to the bug, so it has not been changed. A dialog box has been added, it's possible to reconfirm or not the payment when the change isn't 0.00. Comment on attachment 79759 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. Review of attachment 79759 [details] [review]: ----------------------------------------------------------------- Great job, just one little thing, reading the code only: ::: members/paycollect.pl @@ +194,4 @@ > patron => $patron, > total => $total_due, > ExtendedPatronAttributes => C4::Context->preference('ExtendedPatronAttributes'), > + FineChange => C4::Context->preference('FineChange'), Use Koha.Preference template plugin and do not pass system preferences as template parameter Created attachment 79944 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the inputs paid and change are gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Created attachment 79951 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. This includes also a new system preference called FineChange which enables or disables the feature. Test plan : - Apply patch. - Make sure FineChange is at ENABLE in System preferences > Patrons. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). - Make sure FineChange is at DISABLE in System preferences > Patrons. - Select a patron with a fine and go to Fines > Pay fines. - Confirm that the inputs paid and change are gone. - Choose an amount collected (exemple : 3$). - Click the button confirm. - Confirm that the payment has been made. Signed-off-by: Michal Denar <black23@gmail.com> Comment on attachment 79951 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. Review of attachment 79951 [details] [review]: ----------------------------------------------------------------- Can one still overpay when using this system? What if the librarian finds they don't have the appropriate change in the drawer, can they continue with the transaction inputting the full amount and as such creating a credit? ::: koha-tmpl/intranet-tmpl/prog/en/modules/members/paycollect.tt @@ +108,5 @@ > + <input id="collected" value="[% amountoutstanding | $Price %]"/> > + </li> > + <li> > + <label>Change to give: </label> > + <input id="change" value="0.00" disabled/> This shouldn't be an 'input' in my opinion, rather it should be more clearly distinguished as information.. perhaps a span with a class highlighting in 'red' if the patron is owed change? @@ +220,5 @@ > + <input id="collected" value="[% total | $Price %]"/> > + </li> > + <li> > + <label>Change to give: </label> > + <input id="change" value="0.00" disabled/> As above (In reply to Martin Renvoize from comment #50) > The bug description is really misleading.. this doesn't add a cash > register/till at all, rather it's just a method of displaying change to give. Hi Martin, do you have a good idea for a new bug title? I agree it might be a little misleading the way it is. Hi Martin, I just tested: Overpaying and creating a credit by it is not possible right now. I think it was intentionally changed as the credits caused a bit of trouble and should be added intentionally. To add more: you missed the database part of adding a system preference, see https://wiki.koha-community.org/wiki/System_Preferences#Adding_a_new_system_preference I think the overpaying note might not be valid, but the other remarks (input, db update) are, can you please check? I'm not so sure this should be syspref driven.. I can't see any negative effects from it that one would want to disable it for (except, personally i'd like to be able to overpay if required and as such have this enhanced a little further to allow payment + keep the change as credit). Created attachment 80414 [details]
Mockup
The initial implementation added more steps I think, which was part of the reason to ask to make it optional. I haven't tested tihs one yet, but I feel we shouldn't add more to it right now. Right now, all the required fields are filled automatically. Moreover, if the change is null (0.00), submitting the form bring users back to the Pay fines page immediately. Users can click a single time to pay the full fine. I agree with the idea that adding a system preference is irrelevant in this context and, therefore, I am going to remove it. I also agree that disabled inputs should be turned into spans to avoid confusion. I think that if the change is null the span should be blank and if not it should be filled in red. Created attachment 80986 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. Test plan : - Apply patch. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). Please rebase on master. Created attachment 82420 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. Test plan : - Apply patch. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). Created attachment 82797 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. Test plan : - Apply patch. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). Signed-off-by: Michal Denar <black23@gmail.com> Created attachment 83804 [details] [review] Bug 11373: (follow-up) Add "change calculation" feature to the fine payment forms This patch provides some follow-ups, including corrections to the JavaScript and updates to the text for readability. - Remove obsolete script "type" attribute - Update the use of the obsolete jQuery method "bind" - Use Bootstrap's built-in "show" option instead of simulated click - Handle preventDoubleFormSubmit function's "waiting" class if modal is closed manually To test, apply the patch and follow the original test plan. Everything should work as expected. Note that when the modal is shown, the cursor changes to the "waiting" one when you hover over the body of the page. If you click "No" in the modal, the cursor should return to normal. Created attachment 83812 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. Test plan : - Apply patch. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Created attachment 83813 [details] [review] Bug 11373: (follow-up) Add "change calculation" feature to the fine payment forms This patch provides some follow-ups, including corrections to the JavaScript and updates to the text for readability. - Remove obsolete script "type" attribute - Update the use of the obsolete jQuery method "bind" - Use Bootstrap's built-in "show" option instead of simulated click - Handle preventDoubleFormSubmit function's "waiting" class if modal is closed manually To test, apply the patch and follow the original test plan. Everything should work as expected. Note that when the modal is shown, the cursor changes to the "waiting" one when you hover over the body of the page. If you click "No" in the modal, the cursor should return to normal. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Works well for me, signing off Created attachment 84653 [details] [review] Bug 11373: Show the difference between the amount collected and the amount paid of a fine payment. This patch adds a feature in the fine payment section. It allows to see the change due to patrons when the amount collected is higher than the amount paid. Test plan : - Apply patch. - Select a patron with a fine. - Go to Fines > Pay fines. - Click the button pay. - Choose the amount paid equal to the outstanding amount (exemple : 3$). - Choose the amount collected to be more than the outstanding amount (exemple : 5$). - Confirm that the change is correct (example : 5$ - 3$ = 2$). - Click the button confirm. - Click on Yes in the dialog box. - Confirm that the payment has been made (example : last amount = 3$). Signed-off-by: Michal Denar <black23@gmail.com> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> Created attachment 84654 [details] [review] Bug 11373: (follow-up) Add "change calculation" feature to the fine payment forms This patch provides some follow-ups, including corrections to the JavaScript and updates to the text for readability. - Remove obsolete script "type" attribute - Update the use of the obsolete jQuery method "bind" - Use Bootstrap's built-in "show" option instead of simulated click - Handle preventDoubleFormSubmit function's "waiting" class if modal is closed manually To test, apply the patch and follow the original test plan. Everything should work as expected. Note that when the modal is shown, the cursor changes to the "waiting" one when you hover over the body of the page. If you click "No" in the modal, the cursor should return to normal. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com> Signed-off-by: Josef Moravec <josef.moravec@gmail.com> If I choose 'Pay amount' and set the amount paid to higher than the fines and collect more than is being paid I get the modal calculating the change and a confirm, but then the payment is rejected. I feel like the Amount paid error should take precedence and prevent the modal and confirmation from appearing. Does that seem reasonable? (In reply to Nick Clemens from comment #85) > If I choose 'Pay amount' and set the amount paid to higher than the fines > and collect more than is being paid I get the modal calculating the change > and a confirm, but then the payment is rejected. > > I feel like the Amount paid error should take precedence and prevent the > modal and confirmation from appearing. > > Does that seem reasonable? I neglected to revert these so...I will file a dependent bug report Awesome work all! Pushed to master for 19.05 Great enhancement, will not be backported however. I have to say I am not a fan of the modal. It adds an extra step and has too much text. (In reply to Katrin Fischer from comment #89) > I have to say I am not a fan of the modal. It adds an extra step and has too > much text. I got some more feedback in chat - I've added bug 22359 for more discussion and ideas. |