mamayuan / pe

0 stars 0 forks source link

Persons only identified by the id #3

Open mamayuan opened 11 months ago

mamayuan commented 11 months ago

Duplicates in data are only identified via id. This should not be the ideal way. Clearly the id may be accidentally entered wrongly and with all other information being the same, the app should at least check existing people with same names/same phone numbers and issue a warning. So that the user can realise early to perform undo. image.png

nus-se-script commented 11 months ago

Team's Response

Thank you for your response. This is the intended effect of our product.

image.png

Our rationale for this is that we believe that there could be people with the same name, for example, there could be two people with the same name "Ryan Tan". Hence we did not want to block the addition of employees with the same name.

This also carries over to the phone number as we believe people could have the same office extension which results in them having the same phone number. Hence we did not want to block the addition of employees with the same phone number.

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I disagree with team's response. While it is true that people can share names or phone numbers, it is highly improbable for two individuals to have an identical email address. More critically, the current product design allows for the addition of employees with completely identical information across all fields, including name, phone number, email address, and other attribute entries. This scenario is likely to be perceived as an erroneous input by users.

Consider the situation where a user mistakenly inputs the same employee twice with different id (second time a wrong id); under the current system, this would lead to the creation of duplicate entries with no indication of error. To enhance user experience and data integrity, the implementation of checks that issue a warning upon detecting such duplications would be beneficial. These checks would facilitate early detection and correction of mistakes post entry. Therefore, i think it is reasonable to do checks for potential duplicates due to mistakes and issue a warning message.

Given these considerations, it would be more appropriate to classify this issue as 'NotInScope', marking it for the attention of future developers. This classification acknowledges the legitimacy of the concern while recognizing that its resolution may not be immediately feasible within the current development scope.


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]