nus-pe-bot
commented
1 year ago Team's Response
Hi! Thank you for your detailed report regarding the date validation in our application. We appreciate your time and effort in bringing this to our attention. I would like to provide some insights into the design decisions around our date handling, particularly concerning the year field.
- Arbitrary Lower Limit on Year Field:
The choice to allow the year 0000 in our date validation is indeed intentional. The deadline field's primary purpose, is to store internship application deadlines, which are usually in the future. However, we allowed for entry of deadlines in the past for book keeping purposes. So in that sense, the year 0000 was just set to be an arbitrary lower limit, instead of a year that users would actually need. Setting it to be 0001or 0002or 0003 ... doesn't provide additional value and only begs the question of "When to stop". Since we do not want to make any assumptions about our users and how they intend to use the app, allowing the year 0000 is not necessarily wrong. Our goal is to maintain flexibility in the system while adhering to a logical framework.
- Handling Erroneous Inputs:
We understand your concern about 0000 being entered as a result of an accidental input. For this, we intend to warn the user as seen from the planned enhancement for the deadline field for entry of deadlines in the past:
- Validity of Extreme Year Values:
It's also important to note that while years like 9999 may seem extreme, they are technically still valid. Our system is designed to be robust and future-proof, accommodating a wide range of date inputs.
We will be lowering this bug to a low as well, as such inputs are very rare cases of the product as well.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: Thank you for the detailed response.
I recognize the intentions behind the current date validation approach, especially in terms of flexibility. However, I propose that we consider the balance between flexibility and realistic usage. The allowance of the year 0000, absent in the Gregorian calendar, may introduce unnecessary complexity into data interpretation, affecting user experience.
While it's commendable to future-proof the application, it's equally important to ensure past dates are logically consistent. Dates such as the year 0000 can be misleading and might degrade the integrity of the data. The enhancement you're planning, as per the attached image, doesn't seem to address entries before the common era, which could still lead to input errors.
Moreover, the upcoming reminders feature could be complicated by the allowance of such historically irrelevant years. It's crucial to consider how such features interact with the flexibility of date input.
To mitigate these issues, I recommend introducing a historically and practically relevant range for the year field. A starting year that matches the period of modern record-keeping would likely suffice for the vast majority of users and prevent confusion.
I appreciate your willingness to engage in this dialogue, and I am keen to continue this conversation to enhance the application's functionality and user experience.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** While I understand the perspective that inputs like the year 0000 may occur infrequently, the severity of a bug should not solely be determined by its frequency but also by its potential impact. The designation of the year 0000 as a valid entry can lead to significant confusion, as this year does not exist in the Gregorian calendar and is not recognized in any modern timekeeping system. Allowing such an entry directly affects the integrity of the data collected and managed by the application. This, in turn, can have downstream effects on any features that rely on date calculations, such as reminders, which are central to the application's purpose. Moreover, the impact on user experience is non-trivial. Users who inadvertently enter such dates may not understand the implications or may not receive adequate feedback from the system about the inaccuracy, leading to errors in data entry that may not be immediately noticeable but can cause issues over time. Given that the field in question is used for tracking application deadlines—a critical function for users—the potential for confusion and error introduces risks that warrant a more cautious approach. In light of these considerations, maintaining the medium severity classification would underscore the importance of this issue and ensure that it receives the appropriate level of attention during prioritization and resolution. I believe that adjusting the year validation to a more realistic range is a critical improvement and not merely an enhancement. Thus, keeping the bug at medium severity would reflect its true impact on the application's overall reliability and user satisfaction.
The deadline field can be set to incorrect values:
Through the Add command:
through the edit command:
The issue seems to be related to date checks; whilst the day (DD) value is checked to ensure that it is between 01 and 31, with additional checks based off the month (MM) value to ensure that special months such as February have a valid input range, the year field seems to allow invalid year values (namely 0000).
There is a check for leap years, so good job!
However, from the user perspective, this could mean that a wrong keypress or input is accepted, with the issue going either undetected, or having to be addressed by retroactively editing the company application.