nus-cs2103-AY1920S2 / pe-dev-response

0 stars 0 forks source link

Rewriting diary entries that aren't the date which I specified #2177

Open nus-pe-bot opened 4 years ago

nus-pe-bot commented 4 years ago

I wrote an empty diary entry (see previous issue) dated 2020-03-31 and when I went to use the appendDiary command on a different date (for instance, 2020-04-04), it replaced the empty diary entry and rewrote the date of the empty diary entry from 2020-03-31 to 2020-04-04. This occurs for both appendDiary and for editDiary.

I've attached before and after photos.

Screen Shot 2020-04-17 at 2.44.05 PM.png

Screen Shot 2020-04-17 at 2.46.03 PM.png

The specific commands I used were: addDiary d/2020-03-31 dc/ appenddiary d/2020-04-04 dc/test (but an entry for 2020-04-04 exists)

What I noticed is "test" replaces the empty addDiary entry on 03-31, and the entry on 04-04 doesn't get edited even though it was specified.


[original: nus-cs2103-AY1920S2/pe-interim#2138]

WANG-Yuchen-Alice commented 4 years ago

Team's Response

Dear tester, thank you very much for this report.

We have decided to accept this as a functional bug, but we claim it with the severity level low.

This response is based on the following reasons:

  1. This issue is unlikely to affect normal operations of the product, and it appears only in very rare situations and causes a minor inconvenience only. Because it is uncommon for user to input a diary with null content.
  2. Further, the problem only happens in the specific case when the user build a non-empty diary first, add an empty diary, and then append to the previous non-empty diary (in this specific order). With this, we consider it severity level low.
  3. For more common, relative command with equivalent function like clear/delete a diary, FitHelper can handle it well.

This issue is the root of other related issues, which is due to lack of lower bound check of Content of diary. Currently the diary content checks only the upper bound of the user input, which is 200 characters, but it should also checks for the lower bound, which is non-null.

Based on these reasons and consider the severity.low definition, we claim this error as low.

Hope you can understand. We thank you again for your suggestions and efforts.

Duplicate status (if any):

--