Open javinchua opened 9 months ago
The fix for #4149 would address this issue as well. Therefore, we consider it as a duplicate.
[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:
Upon relaunching the app and running
calculateMC ST2334
I get:
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]
[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:
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.
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.
Perhaps the omission of these fields will be more appropriate.