Joseph31416 / pe

0 stars 0 forks source link

Missing descrition of addpts expected behaviour for some cases #15

Open Joseph31416 opened 7 months ago

Joseph31416 commented 7 months ago

Command: addpts n/john p/5

Actual: Added 5 point(s) to JAdolph Blaine Charles David Earl Frederick Gerald Hubert Irvin John Kenneth Lloyd Martin Nero Oliver Paul Quincy Randolph Sherman Thomas Uncas Victor William Xerxes

Expected: No points should be added as no one in contacts is named exactly as "john"

The user guide should have specified this behaviour as every a user could unintentionally add points to the wrong person, especially if there is a person named "john" and another name "john 2".

bug 15.png bug 15_1.png

soc-pe-bot commented 6 months ago

Team's Response

Same issue as that reply, and same response (Stated in UG)

The 'Original' Bug

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

Addpts commadn add points to the wrong user

Command: addpts n/john p/5

Expected: Point added to person named john

Actual: added to someone else

Screenshot 2024-04-19 at 5.09.43 PM.png


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

Their Response to the 'Original' Bug

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

The behaviour of our name searching is specified in section 4. Features of our UG. It clearly states that the first member listed with the partial name will be chosen

For commands that accept partial names, the system matches the input to the member whose name most closely resembles the provided partial name. If the partial name could refer to multiple members, the system will select the first member listed. To minimize confusion and errors, it is strongly recommended to use unique, full names of members when issuing commands. This practice also helps prevent duplicating member entries with similar names. Example: If there are members named Betsy Crowead and Betsy Dredge , and you issue a command for Betsy , the system will apply the command to the first Betsy Crowe listed in the member directory.

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: Thanks for responding. However I do not think that this is a duplicate as when I reported this, I did not realise that the behaviour was specified in the UG. As such, I was pointing out the fact that the behaviour should be specified in the UG. Thus, this is a documentation bug, which is clearly different from the functionality bug that this report is being marked as a duplicate of.


## :question: Issue response Team chose [`response.Rejected`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.DocumentationBug`] - [x] I disagree **Reason for disagreement:** As mentioned, when I reported this, I did not realise that the behaviour was specified in the UG. As such, I was pointing out the fact that the behaviour should be specified in the UG. Thus, this is a documentation bug if the description was indeed missing from the UG in the first place. This is why I accept the rejection as the behaviour was indeed specified in the UG.