search

Tsenrae / pe

0 stars 0 forks source link

Bug for adding name with numbers #2

Open Tsenrae opened 7 months ago

Tsenrae commented 7 months ago

Steps to reproduce:

  1. add n/12345678 p/98765432 e/johnd@example.com a/John street, block 123, #01-01

Expected: Error message saying that you can't add a name with numbers

Actual: Person added with the name 12345678

Screenshot 2024-04-19 at 4.20.18 PM.png

soc-se-bot commented 6 months ago

Team's Response

image.png

Our app accepts names with any characters.

Our team do not want to impose too many constraints on the user when inputting contact names.

There also exists people containing numbers in their names. E.g. https://en.wikipedia.org/wiki/Jennifer_8._Lee

Furthermore, the user might want to use numbers in the name for nicknames.

Thus our app is behaving as expected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Firstly, based on the screenshot that your team provided, and after looking at your UG again, the only point that you gave for the Name field is that it cannot be blank. You did not specify exactly what you are accepting/rejecting in the Name field, hence it is definitely a bug that I am able to add a Name consisting of just numbers as names do not normally even have any numbers in them, which may lead to confusion and hence minor inconveniences for an average user when they type in such a name.

Moreover, for the link that you provided, the name in question, Jennifer 8. Lee is a name consisting of one number. However, the example that I gave, 12345678, is a name consisting of only numbers. Correct me if I am wrong, but I am unable to search for a person that has a name consisting of only numbers, hence, my example should still be considered an invalid input as there is no such example that is valid in the real world, and thus your example cannot be used to refute mine. One way you could fix this would be to disallow a name consisting of only numbers, and give the relevant error message, as it is clearly not a valid input.

As for your point about people using numbers in nicknames, as said above, this is totally not specified in the UG. Furthermore, since your team's target user profile is small family restaurant owners, as specified in the DG, I would argue that full names would be important when it comes to customer's reservations as there will be times where you need their full names for verification purposes (e.g. owners frequently engage with various stakeholders such as suppliers, government bodies, customer information, supplier contacts, employee records, and financial institutions where the use of full legal names is mandatory. These interactions often require documentation that adheres to legal standards—standards that typically do not recognise special characters as valid components of personal names.). Allowing numbers in names could lead to inconsistencies that diminish the professional appearance of business documents, such as invoices or customer reservations, which are typically generated from this data. Thus, I believe that this is actually a Feature Flaw in your implementation of adding a Person if you were to argue that nicknames could be used instead. Therefore, I unfortunately cannot accept your argument for this point either.

## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]