Open publicmain opened 1 week ago
publicmain
commented
1 week ago 
if there are no space between address and t\friends, this product will consider t\friend will be part of the address, but apparently its not, this product should check whether if tag is exist or not or sth
soc-pe-bot
commented
1 week ago 
As per the CS2103T website, one can observe that deliberate sabotage is not considered to be a functionality bug. More specifically,
such mistakes should not crash the app, corrupt the data, or make it unusable
The application does not become unusable, the data is still correctly stored as the user input it, and the application does not crash.
Furthermore, the command templates provided should the user click on the GUI buttons already includes the space, as do all mentions of relevant commands in the UG and all example commands provided in the UG, in the help menu of the application, in the manual testing instructions in the DG and the error messages for those commands in the application.
Additionally, the constraint of tP is mentioned on the CS2103T site to be:
Following from the Constraint-Typing-Preferred, if the app is optimized for the target user (graded under the product design criterion), a user who can type fast should be able to accomplish most tasks faster via a command line interface (CLI), compared to a hypothetical GUI-only version of the app
So it would be reasonable to assume that this application should be following the standards of a command-line application. And in many widely used and acclaimed command line systems, including but not-limited to Linux, Unix, POSiX and other similar systems, along with their respective command shells such as but not limited to ZSH, Bash or even Windows Powershell/Command Prompt, it is widely accepted that whitespaces are used as a delimiter between command arguments. For example, in the following document:
POSIX.1-2024 is simultaneously IEEE Std 1003.1™-2024 and The Open Group Standard Base Specifications, Issue 8, Section 12.1
available from https://pubs.opengroup.org/onlinepubs/9799919799/ One can see the following excerpt:
Option-arguments are shown separated from their options by
characters, except when the option-argument is enclosed in the '[' and ']' notation to indicate that it is optional. This reflects the situation in which an optional option-argument (if present) is included within the same argument string as the option; for a mandatory option-argument, it is the next argument. The Utility Syntax Guidelines in 12.2 Utility Syntax Guidelines require that the option be a separate argument from its option-argument and that option-arguments not be optional, but there are some exceptions in POSIX.1-2024 to provide for continued operation of historical applications
Thus, it would be reasonable, both from reading the UG and from command line application standards, to assume that whitespace can serve as a delimiter, and not introducing that whitespace between arguments can lead to unexpected behaviour. In this instance, the unexpected behaviour is not something that causes catastrophic failure of the application or corruption or loss of user data, and thus we believe that it is out of scope
[The team marked this bug as a duplicate of the following bug]
Address constraint is incorrect
Above: User guide says address cannot be blank Below: I managed to add a contact leaving address field blank
[original: nus-cs2103-AY2425S1/pe-interim#1708] [original labels: severity.Medium type.FunctionalityBug]
[This is the team's response to the above 'original' bug]
It was already specified in the UG that: User guide says that address field cannot take in
\and all the relevant command formats in the UG (such as foraddandeditcommands) include obvious spacing, for instance:
\ is rather unlikely to be used in the addresses of individuals or contacts, especially not physical addresses. The only 'addresses' that commonly use \ would be file paths, but the target users of the application are highly unlikely to be storing contacts (of people) with \ in their address.
And on the topic of spacing,
such mistakes should not crash the app, corrupt the data, or make it unusable
The application does not become unusable, the data is still correctly stored as the user input it, and the application does not crash.
Furthermore, the command templates provided should the user click on the GUI buttons already includes the space, as do all mentions of relevant commands in the UG and all example commands provided in the UG, in the help menu of the application, in the manual testing instructions in the DG and the error messages for those commands in the application.
However, we recognise that this can still be used in rare situations and could cause slight inconvenience to those users, and hence would believe it is a low severity bug.
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)
Reason for disagreement: Dear Testing Team,
Thank you for your response to the bug I reported. However, I believe it is necessary to further discuss this issue and provide stronger evidence to demonstrate that it is a functional defect that needs to be addressed.
Firstly, categorizing this issue as a result of deliberate sabotage is inaccurate. Users inadvertently omitting a space between the address and the tag is a common mistake, not an intentional act. According to the CS2103T guidelines, if an issue arises from an unintentional user error (e.g., missing a space between two parameters), the application should handle it gracefully rather than allowing the error to propagate.
While the application does not crash and the data is stored as entered by the user, the core issue lies in the incorrect parsing of the data. Users expect "t\friends" to be recognized as a tag, but the application erroneously includes it as part of the address. This incorrect parsing leads to data inconsistency, undermining user trust and negatively impacting the overall user experience.
Good software design should include input validation and provide clear feedback when a format error is detected. In this case, the application should notify users that they may have missed a necessary space rather than silently accepting the incorrect input and producing an inaccurate output.
Although you mentioned that all command templates and examples include spaces, there is no explicit warning in the user guides or the application itself that omitting a space will lead to significant parsing errors. Users should not be expected to infer the strictness of input formats, especially when it is not clearly stated.
Even in command-line applications, parameter parsing errors typically result in error messages. For example, in Linux command lines, incorrect parameter formats prompt the system to return error messages. Referencing POSIX standards does not justify ignoring user input errors; instead, it emphasizes the importance of correctly handling inputs.
According to best practices in software engineering, applications should be capable of handling common user errors rather than only functioning correctly under ideal conditions. Ignoring these errors can lead to issues during actual usage, reducing user satisfaction.
Incorrectly parsing and storing user data affects not only the current operation but can also have negative implications for subsequent data processing and business logic. Maintaining data integrity is a fundamental requirement for any application.
The CS2103T module emphasizes developing robust, user-friendly applications that can gracefully handle errors. Addressing this issue aligns with course requirements and contributes to improving the overall development standards of the team.
According to the CS2103T defect severity guidelines, functional defects include:
Situations where the input format is correct but leads to incorrect results. User errors should not cause severe consequences in the application. In this case, missing a space is a user error that the application should handle appropriately without leading to incorrect data parsing.
Conclusion
In summary, this issue does not stem from deliberate user sabotage but from the application's failure to correctly handle common user mistakes. To ensure data accuracy and a positive user experience, I recommend treating this as a functional defect that needs to be fixed.
