Duplicate Names Are Not Allowed

[ZaydM18]

Steps to Reproduce:

1. View 'FAQ' in User Guide
   OR
2. Type in an otherwise valid add command, with the only exception being using the same name as an existing household.

Expected: Duplicate names should be allowed.
Actual: No duplicate names are allowed.

Explanation: For a social worker management app, where the suggested format is to save families as households according to the surname of one of the residents, it should be reasonably expected that multiple households will carry the same name. This flaw has been addressed in the User Guide, so that 'ambiguity' is minimised. However, households are already expected to carry unique IDs, addresses and phone numbers. This provides many layers of checks and balances to minimise ambiguity, and so duplicate names should be allowed in the app, or at the very least, automatically added with a sequence number (e.g. Tan Family (1), Tan Family (2)).

[soc-pe-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

As per the user guide, this is an intended functionality. Similar to how the phone's contact application works, we aim to minimise ambiguity by disallowing the same name. While it is possible for the user to scrutinise and identify that the households of the same name are in fact different households, we are catering for the fact that this is for social workers who may only be glancing through this list. Therefore, they should be able to distinguish one household from the next immediately and are not expected to perform multiple steps to distinguish a household i.e. check the name, check the id is different/ address/ contact is different.

While automatically adding a sequence number as highlighted is possible, (1)/(2) still does not serve the purpose of resolving ambiguity for the social workers at a glance.

The 'Original' Bug

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

duplication handling

prompt add n/Ng family a/Blk 44 Bedok North Street, #13-04 p/95553738 shows a duplication error when there is already
add n/Ng family a/Blk 44 Bedok North Street, #13-03 p/95553737 in the list

when same family name can be highly possible(compare to full name) it can be different family with same family name since the address and phone are different

expected: added successfully without throwing error

---

_{[original: nus-cs2103-AY2425S2/pe-interim#1374] [original labels: type.FunctionalityBug severity.High]}

Their Response to the 'Original' Bug

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

As per the user guide, this is an intended functionality. Similar to how the phone's contact application works, we aim to minimise ambiguity by disallowing the same name. While it is possible for the user to scrutinise and identify that the households of the same name are in fact different households, we are catering for the fact that this is for social workers who may only be glancing through this list. Therefore, they should be able to distinguish one household from the next immediately and are not expected to perform multiple steps to distinguish a household i.e. check the name, check the id is different/ address/ contact is different.

Items for the Tester to Verify

❓ 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]

---

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: The dev team's argument hinges on the particular design choice that they implemented to reject duplicate names as a feature. However, this has already been addressed in my original bug report, where I clearly stated that I understood that it was a design choice, but that it was a flawed one. The rejection stems from the idea that everything is working exactly as intended, therefore there is no bug to be reported (with respect to the handling of duplicates). This is incorrect, as even if the dev team has specified that this behaviour is intended in the User Guide, the criticism is levelled at the choice to reject duplicate names as a design decision.

It was not the case that the dev team's choices were outright ignored, but that even acknowledging their design decision it should be understood that this is a reasonable flaw with the product itself. It is not something that can simply be explained away as a personal choice when there are many valid reasons to allow duplicate names, especially when the app pertains to storing entire households under a single surname, and surnames are very commonly shared between different families across the world.

---

❓ Issue type

Team chose [type.FunctionalityBug]
Originally [type.FeatureFlaw]

• I disagree

Reason for disagreement: Once again the dev team's response hinges on the idea that I reported what is clearly correct behaviour in the context of their current version instead of reporting their design choice as a feature flaw. The current version does not allow duplicate names, which is intended behaviour as described in the user guide and error message. Therefore, this would not be a functionality bug, and had I reported it as such, would have clearly been incorrect. However, the bug reported was a criticism of the design decision to not include duplicate names. This is a feature flaw because it should be reasonable to expect a social worker to encounter multiple families with the same household name or surname. The dev team has said that this is done to minimise ambiguity, but this is not necessary, as there are already multiple measures in place to ensure that households are identified uniquely. The address and phone number fields also do not allow duplicates, and each household also has a unique Household ID identifier. The idea that a social worker 'may only glance through the list' (as suggested by the dev team) is not really relevant, because many social workers may not simply want to sift through the list and instead look up information such as session details and particular notes.

---