Incorrect value displayed - should the success message or the logic of the code be changed?

[kjw142857]

Hi Prof @damithc, we are considering two approaches to modifying a problematic behaviour in our app and would like to see whether either/both of them are allowed.

• Currently, two of our commands (linkloan and editloan) allow passing in of a monetary value (the loan value) as a parameter.
• In our v1.3 UG, it was stated for linkloan that the loan value must be (up) to 2d.p., following the general consensus that money should be to at most 2 decimal places. However, we missed out including this for editloan (bug in the UG). It must be noted that it does not make much sense for linkloan to disallow > 2d.p. but editloan to allow it.
• Right now our linkloan command is erroneously able to accept > 2d.p. values. The > 2d.p. values are accepted by the app and stored correctly, and displayed correctly when a user accesses the loan. This bug was reported by testers in v1.3 due to its difference from the UG.
• However, the success message displays the loan to only 2d.p. (i.e rounds it off) as we implemented the success message to show 2d.p. values, since it was intended for only 2d.p. values to be accepted. For instance, a loan of 0.0001 would be displayed as 0.00 in the success message. Therefore, this might fall under incorrect results in Q5 of the FAQs for the feature freeze, since the value displayed in the success message is not the value the user entered.

Which of these two lines of thinking would be allowed to approach the issue while maintaining adherence to the feature freeze?

1. The issue is in the linkloan command being to accept 2d.p. values, since our v1.3 user guide says it doesn't. We should modify our linkloan (and possibly by extension, editloan?) command(s) to reject values that are more than 2d.p., upon which the success message will always be correct.
2. The issue is in the success message rounding the loan to 2d.p. We should modify the success message to allow it to show more than 2d.p. in the loan value, and edit the UG to remove the part saying the loan value must be (up) to 2d.p.

Here are some screenshots for reference: Adding a > 2d.p. loan to the user (not supposed to be allowed...) which succeeds Success message does not show the loan value correctly But when viewing the user's loans, the loan value is shown correctly (and it is also stored correctly)

[damithc]

@kjw142857 How about you update the UG to inform users that amounts should not exceed two decimal points as the app behavior is not optimal for any higher precision? Any further tweaks to validity checks can be a planned enhancement.

[kjw142857]

Hi Prof, thank you for the reply! We will adopt your guideline.

To summarise, here is what we will do:

• We will not make any further edits to the logic of how a loan value is handled, or the value displayed for a loan > 2d.p.
• We will update the UG to inform the user that if the loan has > 2d.p., the behaviour of the app will not be optimal. We will also include filtering out > 2d.p. values in the Planned Enhancements.