soc-pe-bot
commented
1 day ago Team's Response
This is intended behaviour. We do not think that leaving the current ID after clear is problematic because it does not affect the user experience of using the app. Furthermore, clear is not the same as a reset. If a user really wants to reset the app's data, they can simply delete JSON data file.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: The clear command, by definition, is intended to "clear all contacts and events," giving users a clean slate. Retaining IDs after clearing contradicts this purpose and creates the impression that the system is not fully reset. The mismatch between the expected and actual behavior undermines user trust in the command, as users may question whether the data was fully cleared.
Initially, the index (position in the list) and the ID (unique identifier) align, simplifying operations for users. However, after clearing: The IDs start from the previous state (e.g., ID = 4), while the index starts fresh (e.g., Index = 1). This misalignment introduces unnecessary complexity and increases the likelihood of user errors. Commands in the system accept both index and ID for identifying entities. After clearing, this inconsistency can lead to:
Data Retrieval Errors: Commands requiring IDs like list might fail or produce unintended results when users mistakenly use the index instead of the ID or vice versa.
The system's flexibility in accepting both index and ID becomes problematic after clearing: Users may inadvertently use the wrong identifier, leading to significant operational mistakes. The misalignment forces users to navigate inconsistencies that disrupt workflows, especially in professional contexts like event planning.
Reliance on Manual File Deletion Is Unreasonable:
The team suggests manually deleting the JSON file as a workaround. This is not user-friendly because: Non-technical users may not know where the file is stored or how to safely delete it. Manual file manipulation increases the risk of data corruption or accidental loss. The clear command exists to provide an accessible and user-friendly way to reset the app. Requiring manual intervention defeats its purpose and introduces unnecessary friction.
The team claims that "clear is not the same as reset," but this distinction is: Neither documented in the User Guide nor communicated to users. Misleading, as users naturally equate clearing data with resetting all associated counters, including IDs. If this behavior is intentional, the system must explicitly clarify this distinction through documentation or in-app messages (e.g., "Note: IDs are retained after clearing data.").
The current behavior is inconsistent with user expectations and industry standards. Many systems reset counters upon clearing data. For example: Database systems like MySQL provide options to reset auto-increment counters when tables are cleared. Event management applications typically reset all identifiers when data is purged to maintain consistency and simplify workflows.
The bug affects all users who rely on the clear command to start fresh. Since this command is fundamental to resetting data, any inconsistency in its behavior impacts every user. Users naturally expect the clear command to reset all data, including IDs, providing a consistent and predictable state. Failing to do so creates confusion and disrupts their workflow. By not resetting IDs, the system disrupts a fundamental use case for the clear command, making this a Feature Flaw with high severity due to its widespread impact.
After I use clear command to clear all the data, the people id is not reset. People using clear command to start over the system so the id should be reset. This product didn't reset the data properly. The id starts from 5 after I clear the app. It doesn't make sense.