UG should have stated clearly that only one `NAME` can be searched for at one time

[Punpun1643]

It is not intuitive that only ONE name can be searched for at one time e.g. I can't do personfind Nicole Emily and expected to find results where all the employee with the names Nicole and Emily are shown. You should have explained clearly and give caution because in an extreme case where thought I can find multiple persons and I do personfind Nicole Hardware and say in the extreme situation where there is a contact with the name Hardware I would thought that that particular contact does not exists in the list when instead it does.

Severity low because it only occurs in rare situation that might confuse the new readers

[nus-se-bot]

Team's Response

No details provided by team.

The 'Original' Bug

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

personfind description in UG does not match actual behavior

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.

---

In UG, the description for personfind implies that the first keyword given will be used for only the name, while the rest will be used for only tags. In actuality, however, all parameters given are used for BOTH names and tags.

Example: UG states that personfind Nicole Hardware finds all the employees named ‘Nicole’, with the ‘Hardware’ tag. In reality, personfind Nicole Hardware finds all employees who are named Nicole or have the Nicole tag AND are named Hardware or have the Hardware tag.

---

_{[original: nus-cs2103-AY2122S2/pe-interim#2970] [original labels: severity.Medium type.DocumentationBug]}

Their Response to the 'Original' Bug

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

Accepted as a bug. The command summary has the correct command format, while the personfind section contains the wrong format.

Downgrading severity to severity.Low.

Bug Severity Labels

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.

The reason is because the bug will have little effect on the user:

• The functionality still works as expected
  • If the user searches for Nicole Hardware expecting [NAME] [TAG]..., the command produces true positives (all users with name Nicole and tag Hardware are found)
• False positives are rare and does not severely affect the user
  • If the user searches for Nicole Hardware expecting [NAME] [TAG]..., there are a few cases of false positives:
  • Case 1: There is a user with the tags Nicole and Hardware (a person Tom with tags Nicole and Hardware)
  • Case 2: There is a user with the name Nicole Hardware
  • Case 3: There is a user with the name Hardware and tag Nicole
  • All other cases should follow from these cases
  • In response:
  • Case 1: Technically follows the specifications (empty [NAME] and Nicole and Hardware as [TAG])
  • Case 2: Technically follows the specifications (Nicole Hardware as [NAME] and empty [TAG])
    • Although it can be argued that [NAME] implies one word, nonetheless, the side effects of this are negligible (see below)
  • Case 3: Should be a rare case (rare that a user has Hardware as a name and Nicole as a tag, and even rarer that both happen simultaneously) and does not significantly affect the user (user may see an additional entry in the list but personfind still filters the list making it easier for the user to find the intended person, which is the whole intention of the feature)

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---