search

javinchua / pe

0 stars 0 forks source link

Editing of json file causes unexpected error #7

Open javinchua opened 9 months ago

javinchua commented 9 months ago

Upon adding the last object into the json file, it considers the file as an invalid format and does not accept it. I believe this is because the name, description and modularcredits have not been filled in but as a user of this application, I do not have the ability to edit the name description and modular credits of each module that I add. Hence, I should not be expected to know this information when adding another module into the json file.

image.png

Perhaps the omission of these fields will be more appropriate.

nus-pe-bot commented 9 months ago

Team's Response

The fix for #4149 would address this issue as well. Therefore, we consider it as a duplicate.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

There is no validation check for the MCs of a module

The ST2334 Module was created with the correct number of MCs (4). Then, I proceeded to change the data file (changed MCs to 200) and relaunched the app:

image.png

Upon relaunching the app and running calculateMC ST2334 I get:

image.png

For clarity, the two modules in the data file were ST2334 and MA1521 (with 4 MCs).

Perhaps a validation check could be done similar to other fields (e.g. module code).

I have tagged this as medium as this has repercussions for another feature (specifically calculateCAP where the MCs stored in the data file is used for the CAP calculation).

[original: nus-cs2103-AY2324S1/pe-interim#3203] [original labels: type.FunctionalityBug severity.Medium]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Editing the module data manually is classified under Advanced Use in the UG. We feel that as this requires users to behave weirdly to self-sabotage their own module plan, as a user would not dive into the data folder to give themselves 200 MCs for one module.

As per the textbook, deliberate sabotage should not be considered as a bug: image.png

As such, we also feel that the severity should be lower as users would have to go out of their way and expend significant effort to cause this issue. However, we do acknowledge that this is something we can look into in a future release. Thank you for the feedback.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: I believe I am addressing a different scenario and not problems caused by extreme user behavior. In the bug which I raised, I mentioned that adding of an additional module requires me to add the name, description and modularcredits, else it is considered as an invalid format. I believe this is a featureflaw because users are expected to be able to add modules by editing the json file, but the user should not be expected to know the name, description and modularcredits. This aligns with the basic add feature of the application where when a user wants to add a module, he only needs to specify the code, year and semester, instead of having to specify the name, description and modualrcredits. As such, I believe it is a different bug, and not about sabotage.

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** In the bug which I raised, I mentioned that adding of an additional module requires me to add the name, description and modularcredits, else it is considered as an invalid format. I believe this is a featureflaw because users are expected to be able to add modules by editing the json file, but the user should not be expected to know the name, description and modularcredits. This aligns with the basic add feature of the application where when a user wants to add a module, he only needs to specify the code, year and semester, instead of having to specify the name, description and modualrcredits. As such, I believe it is a different bug, and not about sabotage.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** In the bug which I raised, I mentioned that adding of an additional module requires me to add the name, description and modularcredits, else it is considered as an invalid format. I believe this is a featureflaw because users are expected to be able to add modules by editing the json file, but the user should not be expected to know the name, description and modularcredits. This aligns with the basic add feature of the application where when a user wants to add a module, he only needs to specify the code, year and semester, instead of having to specify the name, description and modualrcredits. As such, I believe it is a different bug, and not about sabotage.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I believe this makes the application limited in its uses for advanced users, because users are supposed to be allowed to edit the json file and add their own modules, but the current format requirements of the json file are too restrictive.