search

nus-cs2103-AY2021S2 / pe-dev-response

0 stars 0 forks source link

Error in JSON not handled #994

Open nus-pe-bot opened 3 years ago

nus-pe-bot commented 3 years ago

Steps to Reproduce: Edit JSON start date of a task to be earlier than end date. list

Expected: "If your changes to the data file makes its format invalid, ModuleBook3.5 willdiscard all data and start with an empty data file at the next run." from the UG. But it did not start with an empty data file

Actual: No errors thrown . Used saved data

Screenshots:

Screenshot 2021-04-16 at 2.55.43 PM.png

[original: nus-cs2103-AY2021S2/pe-interim#994] [original labels: severity.High type.FunctionalityBug]

AiwassPrime commented 3 years ago

Team's Response

Thank you for pointing this out, we discussed this issue among the developers weeks ago, we had our special reason to keep this feature.

Changed the severity from high to low: As stated in the marking scheme, "A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only." Editing the saved data is not considered a normal operation, and even you edit the JSON file in this manner, it will not cause any bug in our module book except that YOU MAY THINK the task becomes meaningless.

Changed the Bug Type from FunctionalityBug to FeatureFlaw: “If your changes to the data file make its format invalid, ModuleBook3.5 will discard all data and start with an empty data file at the next run.” Change the start time later than the deadline does not make the data file's format invalid. In fact, we do not have the definition of invalid tasks, we only have the invalid format of each field of a task. It is just "you are suggested not to change the start time later than the deadline", it is not because "the start time later than the deadline is an invalid format". So the behavior of our module book is indeed consistent with the user guide, as there is nothing wrong with that special format. I think you may mean: we do restrict a user from editing a start time and deadline in the main program, why we do not have this restriction on editing JSON file, why there is such inconsistency? This clearly belongs to a feature flaw.

Why I reject this bug report: Firstly, there is no bug related to this issue, and most importantly, it even causes no inconvenience to a user. As we stated in UG, "Advanced users are welcome to update data directly by editing that data file." As an advanced user, you should clearly know the meaning of each entry in the JSON file. Given that, if you feel any inconvenience caused by a task with its start time later than its deadline appears in the task list, you should not change it in the first place.

Secondly, We prevent a new user from editing a start time later than the deadline by setting a restriction in our parser, just in case they are not familiar with the notations "a/" and "b/" and misuse them. For an advanced user, we decided to give you full authority to edit a task, you can make use of this feature to achieve your own purpose, as long as it is in the correct format.

Thirdly, a task with a later start time has its own value. You can make use of this feature to achieve your own purpose. Here are some examples:

  1. Let's say you have two tasks, "Ventilation: keep your door open" from 12:00 to 16:00, "Walk your pet dog" from 13:00 to 15:00. If you sort the task list according to the deadline, "walk your pet dog" will appear first. But actually, you should open your door first. In the current version of the module book, we do not support the functionality of compare a start time with the deadline. If you are an advanced user, you want to make "Ventilation: keep your door open" in the front of "Walk your pet dog" without losing any information (and you do not want to separate the first task into "open the door" and "close the door"). You can simply edit the JSON file to startTime: 16:00, deadline: 12:00, and you will achieve the effect. This applied to all tasks that you do not need to physically present.
  2. Easier for the developer to test other features such as sort, when you change the deadline in JSON file, you do not need to care about the start time for every task, you can just adjust the deadline and the order will change. If we implemented this restriction, if you miss any start time, the entire file will be gone, and usually, a test on sort contains many tasks.

Duplicate status (if any):

--