Shux347 / pe

0 stars 0 forks source link

Social media handle constraint error #3

Open Shux347 opened 1 week ago

Shux347 commented 1 week ago

Screenshot 2024-11-15 at 4.40.06 PM.png Above: User Guide says Social Media Handle cannot take in '\' Below: I was able to input '\' and this resulted in further unexpected behaviour as the tag prefix was now undetected

Screenshot 2024-11-15 at 4.39.33 PM.png

nus-pe-bot commented 4 days ago

Team's Response

It was already specified in the UG that: Social Media Handle field cannot take in \ and all the relevant command formats in the UG (such as for add and edit commands) include obvious spacing, for instance: Screenshot 2024-11-17 at 2.57.56 PM.png

Screenshot 2024-11-17 at 2.57.32 PM.png

Additionally, with regard to whitespaces: Screenshot 2024-11-17 at 3.35.30 PM.png 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

It is unlikely for users to be storing social media handles with a backslash, as all the major social media platforms, such as but not limited to Facebook, Instagram, X (formerly Twitter), Reddit or Tiktok, do not accept \ in the usernames.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Address constraint is incorrect

Screenshot 2024-11-15 at 4.28.40 PM.png

Above: User guide says address cannot be blank Below: I managed to add a contact leaving address field blank Screenshot 2024-11-15 at 4.28.34 PM.png


[original: nus-cs2103-AY2425S1/pe-interim#1708] [original labels: severity.Medium type.FunctionalityBug]

Their Response to the 'Original' Bug

[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 for add and edit commands) include obvious spacing, for instance: Screenshot 2024-11-17 at 2.57.56 PM.png

Screenshot 2024-11-17 at 2.57.32 PM.png

\ 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, Screenshot 2024-11-17 at 3.35.30 PM.png 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.

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: [replace this with your explanation]


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]