nus-pe-script
commented
10 hours ago Team's Response
Following this, our app does not support a warning system for checking of case-sensitivity when directly editing the data file. If you are an advanced enough user to edit the data file directly, you would understand what case-insensitive entailed, i.e. 1A = 1a, and would thus not enter them at the same time when manually updating.
As it would take a lot of extra effort to put in checks for this, we instead channelled our efforts toward implementing and refining other features and postponing this to a future implementation, especially since it is rare for users to edit the save file and even rarer that such advanced users would edit the file incorrectly.
Thus we have labelled this as a low-severity and not in scope, in accordance with the level of support for editing the data file as mentioned in the website.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I disagree with this statement. The handling of tags as case-insensitive was clearly stated in the user guide, so the way the JSON file processes tags should reflect that. Allowing the file to accept duplicates with differing cases (e.g., “1A” and “1a”) completely goes against this and creates inconsistency. This isn’t just a minor issue—it impacts the app’s reliability and how much users can trust the documentation. The misalignment between the file’s acceptance of duplicates and the application’s inability to handle them correctly creates confusion and reduces the quality of the user experience.
In the UG, the "study group tags are case-insensitive" and it encourages "advanced users are welcome to update data directly by editing that data file". However, addressbook.json accepts tags with differing cases without any error.
In addressbook.json: shows tags with differing cases allowed
However, in the application, the tag doesnt show:
Implication: Even though the tag with different cases are not showing in the application, it being accepted in addressbook.json when launching might be problematic for users who are editting the addressbook.json file directly. It may cause confusion and inconvenience the users.
As such, I have placed it as medium severity under functionality bug as it goes against the teams intention on tag's case-insensitivity.