JSON Format Being Corrupted

[KhoonSun47]

Steps to reproduce:

• If the user tries to edit the field name "tags" for the JSON File, this data should be deemed as corrupted since it should follow the AB3 storage such that each field name will be validated.
• However, currently, if user were to edit the "tags" into something else, the system will still deemed the data as not corrupted and run as per normal, which should not be the case.

Actual Output: Step 1: The user went to JSON file and change the field name of "tags" to something else and save it.

Step 2: The user went to run the system as per normal on the terminal.

Expected Output: It should be invalidated and displayed an empty list instead.

One example on how it should be validated. Step 1: The user went to JSON file and change the field name of "name" to something else and save it.

Step 2: The user went to run the system as per normal on the terminal. As you can see here, the data is invalidated and the displayed list is empty

Suggestion: Add validation to check for the field name "tags" to be validated.

[soc-pe-bot]

Team's Response

Thanks for bringing up the issue. As per the user guide, editting data file will cause unexpected behaviour and this is expected. So, to further validate such error, it could be a future enhancement. And user would rarely edit it unless they are advanced user as specified by the user guide.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: I disagree that this response is "response.NotInScope" and that it should be "response.Accepted" instead. 


According to the User Guide, any modifications to the data file that invalidate its format prompt HRConnect to discard all data and restart with an empty file. 


Thus, altering the "tags" field name implies corruption of the file (as the format is invalid), warranting a check for this corruption and the display of an empty list thereafter.

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** I disagree that this issue should be classified as a "type.Feature Flaw”, and it should still be remained as a “type.Functionality Bug”. 
 As stated on the website, a “Functionality Bug” covers manual edits to the data file. 

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I disagree to the downgrading of this response's severity from "severity.Medium" to "severity.Low." 
 If HR managers, particularly advanced users, modify the data and then discover that not all fields are validated, it can lead to confusion and occasional inconvenience. 
 The product still functions, but this oversight can impair the user experience for those who manually edit the data file. 

---