acekhoon / pe

0 stars 0 forks source link

Case sensitivity of role and the name of CCAs for filter function #2

Open acekhoon opened 7 months ago

acekhoon commented 7 months ago

Description: In the real context, role named "Treasurer" and as "treasurer" would mean the identical role, but this treasurer cannot be used to search the role Treasurer, and this was not mentioned in the user guide as well. As an user, I feel this is categorized under Feature Flaw since it might be considered as a partial implementation of filter function. This happened for the name of CCA as well since "NUS Cycling" and "NUS cycling" would be highly likely that they are the same CCA.

Steps to reproduce: Typed in command "filter r/treasurer c/NUS Cycling" (OR filter r/Treasurer c/NUS cycling)

Expected: 2 persons listed!

Actual: 0 persons listed!

Screenshot 2024-04-19 at 4.21.38 PM.png

soc-pe-bot commented 7 months ago

Team's Response

Although this is valid, we find that this should be VeryLow as it is very unlikely for the user to encounter this as an issue. In the case where there is a typo and the capitalization is omitted, the user would immediately notice that there are two treasurers indicated and rectify it accordingly. So in the end it is purely cosmetic.

The 'Original' Bug

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

Case Sensitivity for Duplicate Detection for add method when it comes to adding a new person

Description: From what has tested so far, the duplicate detection is done via the name of the person since adding person named John Doe is not allowed. However, since "John Doe" and "john doe" are likely to be the same person (since they share the exactly identical address, email address and phone number), I believe that the product should identify them as a same person. This can be referred to this paragraph from PE website:

"Bugs related to duplicate detection: Duplicate detection (e.g., detecting if two persons in the address book are the same) is not trivial; often, detecting only the exact string/value matches is not enough. For example, John Doe and john doe are likely to be the same person. Similarly, extra white space (e.g., the user typed an extra space between the two names) is unlikely to mean they are two different persons. Typically, it is best if you can give a warning in such near match cases so that the user can make the final decision."

Stepts to Reproduce: Typed in "add n/John Doe p/98765432 e/johnd@example.com a/6 Sin Ming #01-01" to add John Doe, and added another John Doe by typing in "add n/john doe p/98765432 e/johnd@example.com a/6 Sin Ming #01-01"

Expected: This person is already exists in the addressbook

Actual: New person added: john doe; Phone: 98765432; Email: johnd@example.com; Address: 6 Sin Ming #01-01; Roles: ; CCA: ; Amount: 0.0; Attendance: 0/0; Metadata: //NO METADATA//

Screenshot 2024-04-19 at 4.29.33 PM.png


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

Their Response to the 'Original' Bug

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

Valid

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]