soc-se-bot
commented
2 months ago Team's Response
Thank you for the response! The team believes this is an acceptable system behavior considering that LongAh is designed to keep track of transactions that have already taken place. This means that the transaction time is ultimately a parameter managed by the user, and the system will recognise it as valid as long as the transaction time is of the past. It would be illogical to intentionally put a restriction on the period of transactions since it will not only be difficult to justify the choice of this period and also likely create inconvenience for our users. (For instance, the system restricts the period from 30 years before to now, but I would like to guide an elderly to make use of the system to keep track of long passed debts Or the user inputs a transaction now, but opens it up only 30 years later. Is this transaction automatically disregarded?)
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I feel that the program would still be more elegant should a period window be set.
Yes, in this case of example given it would make sense. However 30 years is not a very long period ago. The program can potentially still be more elegant and user friendly by catching errors made in keying wrong years such that users would not need to execute a delete command and then reproduce the transaction again.
The bug report aims to point out examples on the extreme spectrum and I feel that a reasonable window period could still be set such as a 100 years back. If the counter example given above invalidates this bug report completely, then a counter-counter example from me could be if no restriction is to be placed on setting the years, why am I unable to set alphabets in the year, should I have a year dating back to eg. 100 BC?
there is error handling in setting a date for the future but not of a time period dated too long ago such as year 0001