soc-se-bot
commented
1 week ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Program does not handle case when the text file
Steps to recreate the bug: 1)change number of pullup to negative.
Since some of the default data is -1, some user may make a mistake when editing the text file by adding a negative sign before some data. It does not make sense for the number of pull up to be negative. Instead of allowing the user to load obviously incorrect data into the program, maybe you could consider removing the data point or clarifying with the user
[original: nus-cs2113-AY2425S1/pe-interim#211] [original labels: severity.Low type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thank you for bringing this to our attention. We acknowledge that this accepting negative inputs via text file editing results in a nonsensical output, and that there are some lacking precautions against this behaviour in the current user guide, but we feel that this issue is
Not in Scope, for three reasons:1) This issue only arises in the exceptionally rare case that a user goes out of their way to manually edit data via the text file, which is not a condoned action in the UG and is thus implictly done at users' own risk. Note that in this case, they have made the concious decision to not use the respective commands provided within the program that do have safeguards against this error.
2) In the event a user chooses to edit data via the save file, we as developers are not able to provide precautionary messages before, or during the event. Additionally, the amount of work needed to provide a tailored error message addressing the specific variable mismatch would be out of proportion with the rarity of this behaviour bug, and actually reduces the usefulness of the current data loading feature in the event of data corruption, where there may be multiple erronous entries in the save file.
3) There are already existing precautions against some level of data-corruption/malformation in the program that ignore erronous save-files. Evidently they did not catch this case which they should have, but they are already out-of-scope additional precautions given that data editing was not an advertised feature of the program, and thus we do not believe that catching cases such as this - which could be considered user self-sabotage - is in scope.
We appreciate your help in making our program more resilient and user friendly.
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`] - [x] I disagree **Reason for disagreement:** [replace this with your reason] Firstly, there was no mention in the user guide on any information regarding data file saving/loading/editing, this opposes the dev team response in point 1. The warning to not make edits on the data file is missing. Given that the target users are teens between the age of 12 - 24 years old, where they are curious about things and would like to try to figure out things, they might be curious in the data file and edit it to see what will happen to the app. Therefore the dev team should treat this with utmost importance when they have implemented data file saving and loading. Secondly, regarding the dev team response in point 2 and 3, since the dev has mentioned that there is some form of data-corruption/malformation in the program that ignore erronous save-file, I believe they could try to figure out way to void the entries in the save file if the save file has been edited to not fit in the valid parameters. Lastly, according to the course website, this bug does not fit in the criteria of response.NotInScope as if did not satisfy at least one of the point. I have explained point 1 where the UG did not specifies that file editing is not supported or coming in a future version. Regarding point 2, there were instances where the software did not fails gracefully due to the edit of the save file. In those instances, the app crashes and I was unable to use the app at all until i rectify the edit to be something that will allow the app to work again. In 
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** [replace this with your reason] I believe this bug can be considered both a functionality bug as well as a feature flaw. In my stance that this is a feature flaw because, some of the save file edits allow the program to continue to run while some of the edits simply just crashes the program and does not allow the program to run unless the edit are reverted to be edited to match the valid parameters. There is inconsistent handling or user modifications in this case.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** [replace this with your reason] I initially place this as severity.High but after consideration from the dev team response as well as reading through the course website, I believe this bug should be considered as severity.Medium instead of severity.Low as this bug did not only caused a minor inconvenience since the data file is not protected and can be easily edited. This is not severity.High too as the editing of save file might not be performed by most users. Therefore a severity.Medium seemed to be the best option.
Editing the saveFile.txt is allowed only until the input values were changed from int to float, which then prompted an illegal access to saveFile.
While the changing of age and input values to negative still allow the app to run, with exceptions displayed as string in 'view' command and negative values being ceil to 0. After exiting the app after the 'view' command, the invalid inputs still remain in the saveFile.