Bug: Wrong parameters used for Equality Check

[ShenyiCui]

Current Behaviour

• Equality is being determined only by name.
• Its Very very very common for multiple people to have the same name
• At it's current implementation If two people named john smith cannot check into your hotel at the same time despite them being different people holding different phone numbers, and email addresses

Expected Behaviour

• Equality should be determined by the combination of name, email and phone number, creating a more reliable "primary key".

Screenshots

[soc-se-bot]

Team's Response

While we believe that this is a bug, considering that we are targeting small hotels, the chance of having 2 people with the same full name is very very very uncommon. Additionally, names can be differentiated using custom suffixes as a workaround. As such, we decided to prioritise implementing other features over making the duplicate check more extensible.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: Recall the definition of a Not In Scope Bug

a known bug can be considered NotInScope if rectifying it is less important (based on the value/effort considerations) than the work that has been done already

• This bug can be fixed with very Low Effort. It takes 5 seconds for you to change the equality check to be a combination of name and email making it unique.

• Fixing this bug is also of very High Value. Changing this will eliminate the issue of possibly turning away a guest just because they have the same name. This will earn more revenue for the hotel, giving it value.

• Because changing this is Low Effort and provides High Value relative to the rest of the work being done in the program, it's clear that this is NOT a NotInScope bug and that the dev team has forgotten about it.

---

:question: Issue severity

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

• [x] I disagree

Reason for disagreement: Recall the definition of a High Severity Issue:

A flaw that affects most users and causes major problems for users. i.e., only problems that make the product almost unusable for most users should have this label.

• Since this bug will make it so that users will have to turn away hotel guests simply because they have the same name, which is common, it's rightfully so that it should be labelled high severity.

Recall the definition of a low-severity bug:

A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.

• It is not an unlikely problem and will affect the operations of the product by a lot as even if you choose to let the guest stay, you won't be able to track the expenses/stay of a guest, causing data loss.
• It causes a significant inconvenience to the guest or the hotel in all cases; it's more than a minor inconvenience.
• Hotels, in some countries, have to record names as is from their passport, so using suffixes or different variations of the name is not only disrespectful but also not possible in some countries.

---