Open faaheem13 opened 6 months ago
Thanks for raising this. This is intended, and was mentioned in the UG under FAQ
section.
For why meetings are allowed in the past:
Bookkeeping purpose (not exhaustive as we do not want to limit how the user deals with definition of meeting) may include events that the staff and the user has taken part in the past that are critical to record (Eg. tracking school events that may have expenditures to them ) and the user would like to keep track of it but has forgotten to. Hence allowing adding meetings in the past would circumvent this problem. This is to allow them such that in the future when they are fact checking any other sources for discrepancies, the user will know that their source information is accurate.
For the date out of range the following response is exactly the same as why date is allowed out of range here:
Our definition at any point of time refers to a specific part of the timeframe that has existed, currently existing or will exist in the future. Another reason why we do not want to limit the timeframe as the definition of realistic range is too broad and general. There is no concrete and clear-cut number that will make everyone agree that it is realistic. Hence, our team agrees to satisfy everyone and meet the requirement of our software we will allow any valid date that has a possibility to exist at some point of time. Nonetheless some might find it as garbage values , but our software delivers correctly as it is told to. (Garbage in, garbage out)
Team chose [response.NotInScope
]
Reason for disagreement: [replace this with your explanation]
The app takes in dates that go as far back as 0012 (which again is very far behind in the past).
However, I believe it can be easily solved: a range constrain should be introduced.