Shux347 / pe

0 stars 0 forks source link

Financial info constraints error #2

Open Shux347 opened 1 week ago

Shux347 commented 1 week ago

Screenshot 2024-11-15 at 4.34.01 PM.png

Above: User guide says that financial info cannot take in '\' Below: I was able to input in a '\' and this further resulted in unexpected behaviour as the Social Media Handle prefix was subsequently undetected

Screenshot 2024-11-15 at 4.36.20 PM.png

nus-pe-script commented 3 days ago

Team's Response

It was already specified in the UG that: User guide says that financial info 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

Furthermore, on the topic of whitespacing, 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 blank characters

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.

Thus, it is already clear to the user that they should not be using \ and that they should have spacing between their fields, plus, in the field of financial information, we believe that it would be very unlikely that a user would include ONLY a backslash (or even multiple ones) in that field, and are unable to find real-world examples that would be relevant to the target audience of this application.

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]