Date input is not sanitised

[krusagiz]

1. Running the following command with a invalid sd start date parameter:

2. Results in the command succeeding with an budget added with an incorrect start date. As shown here:

[nus-pe-bot]

Team's Response

This issue is due to an attempt to allow more natural forms of date and time input by integrating Natty and paticularly the limitations of the natural language processing used by Natty. Natty attempts to parse anything a user enters that resembles a valid date as a date. This results in unexpected date time when the representation of the date a user enters does not align with Natty's expectations.

Natty attempts to recognize a wide range of date formats, but since there is an inherent ambiguity in the grammar describing these formats, some decisions need to be made arbitrarily.

Excerpt from Natty's documentation available here

As language is naturally ambiguous in the absence of context, and stronger natural language processing to determine said context, it is not feasible to correctly parse every single date that a user enters.

For example:

Attempting to parse 33 alone is ambiguous. 33/2 is less ambiguous, however, this format does no align with most common time inputs, and the date is also not a valid date. However, Natty is not aware of the context of this input and tries its best to determine what it could mean. This results in it parsing a time rather than a date as 33 is not a valid date in any context. This results in the outcome seen where Natty parses the 2 in the input an an hour rather than a month due to the absence of a valid date, since in most contexts 2 is taken to be a time.

For this particular case:

As stated in our user guide, users ‘can refer to http://natty.joestelmach.com/ for documentation and more information’. As seen from the ‘try it out’ section of the aforementioned website, Natty successfully parses a datetime input of ‘nov 32 2019’ as 1st Nov. This matches the success message in the screenshot of the bug report (1 Nov). The time field of the added budget in the report (12:00:00 AM) is an intended budget feature.

Hence, we are changing the bug type to a FeatureFlaw:

• This is not a functionality bug; the natural language datetime parsing feature is working as specified in the library.

type.FunctionalityBug: A functionality does not work as specified/expected.

• This is more of a completeness issue as the library is unable to perfectly parse all datetime input without enough information.

Downgrading severity to Low:

• The product still remains usable. Hence, this is not a High severity issue. Additionally, in normal usage, users would not want to enter an invalid date when tracking their expenses, and this situation would only really occur with a typo that results in a date being unintelligible or when someone is attempting to purposefully achieve unexpected outputs of the natural language date parser.

We are defining this issue as not in scope for the following reasons:

• This issue is mostly due to the limitations of the 3rd party library Natty, and due to our lack of knowledge regarding natural language processing. This behaviour is inherited from the 3rd party library.

• Given that there is no rigid date format and natural language processing is used, there is also no way to judge that an input which may be ambiguous is parsed exactly as the user intended. As such, I feel that this should not be blamed on the team.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your reason]

---

:question: Issue severity

Team chose [severity.Low]. Originally [severity.High].

• [ ] I disagree

Reason for disagreement: [replace this with your reason]

---

:question: Issue type

Team chose [type.FeatureFlaw]. Originally [type.FunctionalityBug].

• [ ] I disagree

Reason for disagreement: [replace this with your reason]

---