Able to change MC counts of modules

[keaganpzh]

Description

The MC count of each module is able to be edited by changing the modularCredit field in the .json file. This allows the user to manually change how much MCs a module is worth.

Steps to reproduce

1. Edit a module's MC count by editing the .json file directly.

Expected outcome

• The module's MC count should not be overwritten in the .json file, instead should be pegged to some constant value.

Actual outcome

• A module's MC count can be edited externally.

Screenshot

[nus-pe-script]

Team's Response

This should be a FunctionalityBug, not a FeatureFlaw

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:

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]}

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:

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---