Open prave1n opened 1 week ago
Thank you for your feedback.
We allowed this behaviour for two main reasons:
Preventing overzealous input allows for users to set arbitrary dates to indicate any specialised meanings (e.g. unconfirmed date) and we give users the trust and freedom to choose what they wish to do with the input of possibly unrealistic but valid dates.
We trust users are vigilant enough to input and recheck the inputted date. Typos in date input will not be addressed properly by just limiting the dates to after the birth date as incorrectly inputting dates can still pass this check if after the birth date.
As such, it might not be in scope for fixing as it does not affect normal usage of the application, and might even be detrimental to fix for our users.
Team chose [response.NotInScope
]
Reason for disagreement: [replace this with your explanation]
Steps to replicate:
add n/John Doe i/S1234567A d/2000-01-01 g/M p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25
addAppt Physio i/S1234567A @d/1990-05-19 @t/1100-1230
expected output: error message since appointment date is before birth date of patient
actual output: successfully adds the appointment
this is an invalid input for the date as it should not be possible to add an appointment for the patient even before their birth date