Emberlynn-Loo / pe

0 stars 0 forks source link

Unable to add duplicate name for different people #2

Open Emberlynn-Loo opened 6 months ago

Emberlynn-Loo commented 6 months ago

Steps to reproduce

  1. Input add n/Benjamin Lee p/98765432 e/ben@benscarrots.com a/311, Clementi Ave 2, #02-25 c/Awesome Carrots t/vegetables t/carrots
  2. Input add n/Benjamin Lee p/98765432 e/aa@gmail.com a/1234 c/Carrots

Expected No error message to be shown because it is a completely different person just with the same name

Actual Error message that person already exists is shown

Screenshot 2024-04-19 at 4.17.33 PM.png

nus-pe-script commented 6 months ago

Team's Response

Screenshot 2024-04-22 at 4.02.05 PM.png

Mentioned in UG under the Notes section for add

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: It is very easy to misinterpret this as addition parameters, which was one there was one person with tags and one person without tags as an extra parameter. Screenshot 2024-04-23 at 7.35.03 PM.png

It is not intuitive to read this as adding identifiers to the name parameter itself as identifier means any unique data for a person (from picture above). Users could also interpret it as other parameters being different like same exact name but different emails and such. This can be confusing for users.

I disagree with your decision to reject this bug as it is therefore valid, however I think it should be changed to a documentation type bug instead. This bug could have been solved by defining what identifier meant in a glossary.

Furthermore, your target audience is small restaurant owners. Duplicate names with awkward identifier numbers at the back could cause more harm than benefit.

Legal and Regulatory Compliance: In many jurisdictions, businesses are required to maintain accurate records of their transactions, especially for purposes like billing, taxation, and compliance with health and safety regulations. The accuracy of customer names is crucial in this context. For instance, legal documentation or financial transactions require customer names to be recorded exactly as they appear on government-issued IDs, which do not include numbers. By allowing numbers in the name fields, our application might inadvertently promote non-compliance with these standards, potentially exposing business owners to legal risks or administrative difficulties.

User Expectations and Data Integrity: Our users, particularly small business owners, rely on our application to provide tools that align with best business practices. The inclusion of numbers in name fields can lead to data inconsistencies, affecting everything from customer service to legal documentation. It is reasonable to expect that a business-focused application would enforce data entry norms that prevent such issues.

Impact on User Experience: Confusion or errors in inputting customer information can degrade the user experience, resulting in inefficiencies and potential discrepancies in important business documents.

There are ways to tackle duplicate names. The easiest would be to use a universally unique identifier (UUID) to each entry. This UUID can be a system-generated number or code that isn't necessarily displayed as part of the person’s name but is used internally to differentiate between individuals with the same name. This is common in database management systems where each row or record has a unique primary key. Furthermore, you have a tagging system already implemented. You could use numbers in those tags instead.