nus-pe-bot
commented
1 day ago [IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]
Team's Response
Thanks for your bug report. We appreciate the feedback regarding the behavior of the application when the data file is set to read-only.
After reviewing the issue, we would like to clarify the following points:
Constraint -Single-User The application is explicitly designed for single-user environments, in line with the project constraints. The assumption of unrestricted access to the data file aligns with this single-user model. As such, shared or restricted-access environments (e.g., read-only scenarios) are explicitly outside the intended scope of the application. Hence, it is "unlikely to affect normal operations".
User Guide "Quick Start" instructions The User Guide's "Quick Start" instructions direct users to copy the app file to a folder for use. This inherently implies that the folder and its contents are writable for the app file to be successfully copied. If users encounter a read-only scenario, it indicates a deviation from the prescribed setup. The behavior should not be classified as a bug since it results from misconfigured user environments and the app successfully catches this.
As such, we are reclassifying this to low severity since a read-only environment is unlikely to occur in the intended single-user setup and would only occur if a user manually modifies the folder permissions. In that case, it would only cause "a minor inconvenience" since all the user needs to do would be to revert the change.
Users following the "Quick Start" instructions in the User Guide would not encounter this issue, as the folder containing the application file must be writable.
Since a read-only environment represents a deviation from the supported setup, blocking all commands without allowing view-only commands in a read-only environment is deliberate to flag it out to users early and ensure they rectify the issue.
As allowing basic view-only functions in read-only environments would require developing additional features to accommodate use cases outside the project’s intended scope, this would be a feature enhancement for future versions, not a bug in the current implementation, hence are not part of the current scope.
To further mitigate confusion, we can enhance the User Guide to explicitly state the need for writable data files to ensure seamless operation, hence we are reclassifying this to a documentation bug.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your reason]
## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your reason]
When the data file is set to read-only, the application blocks all commands, including view-only commands like list , find, help , and exit . This restricts users in shared or limited-permission environments from accessing essential non-data-changing features.
Steps to Reproduce: 1. Set the data JSON file to read-only. 2. Open the application. 3. Try executing a non-data-changing command, such as help .
Expected Result: Non-data-changing commands should execute normally, allowing view-only access even without write permissions.
Actual Result: The application blocks all commands if the data file is read-only, including non-modifying commands.
Severity: Medium – This flaw prevents users with restricted permissions from performing even basic view-only functions, causing regular inconvenience in shared or limited-access setups.
Rationale for Medium Severity:
Suggested Fix: Enable non-data-changing commands to execute even when the data file is read-only, ensuring that users in restricted environments can access view-only functionalities without write access. This adjustment would significantly improve usability for users who require read-only access.