search

bhnuka / pe

0 stars 0 forks source link

findPerson can take in nonsensical input #2

Open bhnuka opened 10 months ago

bhnuka commented 10 months ago

findPerson can take in @, even though name can only have alphanumeric characters and spaces.

nus-se-script commented 9 months ago

Team's Response

Bug #4687

Thank you for your bug report.

We have identified this report as a duplicate of a previous bug report.

In addition, this behaviour does not cause any error to the user and is unlikely to affect the normal operations of the product.

Hence, we will downgrade this to a Low severity, which is the same level as the original bug.

We hope that you understand our decision. Thank you.

The 'Original' Bug

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

Findperson / tag / task should also follow restrictions placed on addperson/tag/task

The restriction placed on names,tags and tasks are that only alphanumeric characters are allowed ap n/. p/93843333 e/test@gmail.com a/Test addy Screenshot 2023-11-17 at 4.52.52 PM.png

However, if we do ft . or fp . or ftag ., the command goes through and shows nothing (since we have no names or tags or tasks with .) Screenshot 2023-11-17 at 4.53.13 PM.png

Screenshot 2023-11-17 at 4.53.32 PM.png

I feel like putting in non-alphanumeric characters when finding should result in an error message, which would be the same error message as the specific field eg. fp . should show the error shown in the first screenshot and not go through

[original: nus-cs2103-AY2324S1/pe-interim#4230] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Bug #4961

Thank you for your bug report.

For findPerson, we have a planned enhancement in the Developer Guide to allow non-alphanumeric characters in Person's names.

To be consistent with this planned enhancement, all other find commands will follow the format of findPerson (i.e. accept non-alphanumeric characters) so that the user does not need to remember which find command accepts non-alphanumeric characters and which do not. This makes the user experience more smooth and intuitive.

For findTask, currently, a task's title and note can already contain non-alphanumeric characters, so the suggestion is invalid.

We hope that you understand our decision. Thank you.

  • Response: Not In Scope (planned enhancement)

    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.NotInScope`] - [x] I disagree **Reason for disagreement:** Just because you state that this is a planned enhancement does not mean that this behaviour should be allowed ("this behaviour" being accepting non-alphanumeric characters for findPerson) in the current iteration. Restrictions should be as per the functionalities in the current iteration, and hence, findPerson should be restricted to alphanumeric characters for this iteration. In your future iterations, when you actually expand on what can be accepted for Persons, only then should you expand on accepted inputs for findPerson. Thus, I still believe this to be a relevant bug.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** Considering that this is an unexpected output, it should be considered as a FunctionalityBug, rather than FeatureFlaw.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]