ZhangAnli / pe

0 stars 0 forks source link

Similar items with same name but different details not allowed, expected user scenario in real life. #3

Open ZhangAnli opened 3 years ago

ZhangAnli commented 3 years ago

No details provided. Screenshot 2021-04-16 at 2.31.40 PM.png

Steps to reproduce: add n/Melville Park a/22 Simei Street 1, #10-02, S529948 add n/Melville Park a/000000000, #10-02, S123456

The second duplicate is not allowed, supposedly because the name is similar to the first Melville Park. This duplicate checking does not make sense as there could be muliple places with the same name but different address. I believe this use case was not accounted for!

One such instance could be when you want to add "Clementi HDB" into the list. There could be multiple Clementi HDBs with different addresses. I checked the UG but there seems to be no indication why this is not accepted.

nus-pe-bot commented 3 years ago

Team's Response

While there could indeed be multiple places with the same name, the user would assign them different names to easily identify which is which. Perhaps this scenario could have been specified in the User Guide hence the change to DocumentationBug and Low severity.

It seemed intuitive that the user would be able to create personalised residence names and not be restricted to the actual name of the residence(s) if they wish to keep track of many residences easily / at a glance. This should be clear from the example of HDB or Condo which is obviously not the real name of the residence (should be Block XXX, Apartment #XX-XX) but rather an easy way for the user to identify that residence (e.g. a shorter nickname which saves time typing).

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: As stated by the dev team themselves: "Perhaps this scenario could have been specified in the User Guide hence the change to DocumentationBug and Low severity".

No idea why this was rejected since they themselves have admitted that this was a case not fully accounted for. On a more serious note, while this may not be a common user behavior, it can still definitely happen in certain cases/circumstances The team should either clearly state this in the UGDG or find other means to improve this duplicate checking.


:question: Issue type

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

Reason for disagreement: [replace this with your explanation]


:question: Issue severity

Team chose [severity.Low] Originally [severity.Medium]

Reason for disagreement: [replace this with your explanation]