search

MonkeScripts / pe

0 stars 0 forks source link

-s can be used in Operational item #14

Open MonkeScripts opened 5 months ago

MonkeScripts commented 5 months ago

image.png -s can be used in operational item even though there should be no sale price

nus-se-bot commented 5 months ago

Team's Response

Duplicate of #778.

This is, again, related to the issue of input sanitization, which I've previously clarified on.

Observe that your input is valid (that is, your add command for an operational item is valid since it contains all of the necessary parameters). Thus, it passes the input validation check.

However, as we've clearly stated in our UG, the -s flag is unnecessary in the add -op ... operation.

In this case, even though the program has accepted your input, we've sanitized your input to remove unnecessary parameters and trailing characters. Thus, you will notice that no sale price is assigned to your product, and your additional junk input of dsafdd... is unrecognized as well.

Ultimately, your add command was correctly parsed by the application, and all irrelevant/redundant characters in your command have been ignored, as intended.

The 'Original' Bug

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

Poor sanititisation

image.png

[original: nus-cs2113-AY2324S2/pe-interim#906] [original labels: type.FunctionalityBug severity.High]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

From the only screenshot provided, it's shown that your inputs were sanitized and parsed correctly.

Your first two inputs were correctly invalidated as they do not fit our command format.

image.png

For your last input: search -q 0.. -e 17-09-2022..23-11-2024 ..23-11-2025, we see that your input was accepted. Why is this so? Well, this is because search -q 0.. -e 17-09-2022..23-11-2024 is a completely valid command. The only caveat is that you added some extra junk characters to the end of your command (..23-11-2025).

Ultimately, as you've provided a valid search command, our application is right to accept your input. Now that your command has passed the input validation check, it will be sanitized and parsed accordingly.

Evidently, the last part of your input (..23-11-2025) was correctly ignored by the application (given the fact that it is junk input and redundant), and the command was only executed on the valid parameters provided. Do note, that as a part of our input sanitization process, we delete unwanted characters from valid inputs, to handle typos from users. In this case, the trailing junk characters which you've included have been deleted and ignored by the application.

Therefore, your input has been validated and sanitized appropriately.

We'll reduce the severity of this bug to Low as this bug evidently has no severe impact on the functionality of the application. The initially assigned High severity is completely unjustified and unwarranted.

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 response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** Same reason, accepting is poor practice because of logs issues. An error should be thrown instead to completely reject erroneous commands.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Bug exists in all commands