nus-se-bot
commented
1 week ago Team's Response
Thank you for your bug report. As we feel that there are 2 different bugs in your report. We have decided to respond to “Student different name but same phone number, email and address are allowed”, which is a duplicate of #3102, another bug we have received as it is how we decided to differentiate duplicate persons.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Weak duplicate Person check
So long as the name is different, it is treated as a different person. This check is rather weak as it is highly unlikely that two different contacts with the same email and number (and possibly address) are two different person.
The severity given is medium as there could be scenarios where the private tutor could be copying contacts into the program and might have misread and result in the program having two different names but with every other details being the same (such as email, phone number, etc). In instances like this, the tutor would only be able to reliably have contact to one.
[original: nus-cs2103-AY2425S1/pe-interim#1704] [original labels: severity.Medium type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thank you for your bug report. We decided that this issue is not in scope however if it was in scope, it should be
severity.Lowinstead ofseverity.Mediumas users are able to edit the contact in case they misread, which rarely happens and at most causes a minor inconvenience and we believe it is atype.FeatureFlawinstead of atype.FunctionalityBugas this was what we have designed in the first place. You have reported a valid issue and we have considered this issue of duplicate person checking during our design and implementation phases, however we still decided to stick with our current implementation as we believe it is a form of overzealous input validation.
One example that we have encountered in real life is that siblings living in the same address could share only 1 phone and 1 email address as this is a decision made by the parents. If we had restricted users such that each contact had to have different phone, address, or email addresses, the user would not be able to input a contact such as the example we have provided. We did not want to restrict users from inputting such inputs so that more users can find our app useful in their tutoring needs.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [x] I disagree
Reason for disagreement: I think you have misunderstood my issue. As stated in the title, "Students with the same name cannot be added." Then, in the elaboration part, I mentioned that students with different names but the same phone number, email, and address are allowed. This is to explain the implementation of the program that not allowed students with the same name, but it allows students with the same phone number, email, and address. Next, I clarified that it is possible to have students with the same name (e.g. Alex Tan, John Lee), but it is unlikely for the same phone number and email. Hence, I suggest that differentiating students by phone number and email address would be more useful and reasonable. This is about preventing users from adding contacts with identical names even when other fields (phone number, email, address) differ. This restriction unnecessarily limits users' ability to manage their contacts effectively.
But the other issue refers to cases where two persons with the same phone number, email, or address but different names are allowed to exist in the system. This bug addresses overlapping data fields to check whether a person is duplicated.
## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** According to the UG and DG, the application is designed to simplify contact management for private tutors. The UG explicitly mentions that the app is optimized for tutors to manage their students' data efficiently. Tutors often encounter students with the same names, such as "John Lee" or "Alex Tan." Restricting the addition of such students contradicts the core purpose of simplifying data management by introducing unnecessary friction into the workflow. The DG highlights the app's value proposition: to enhance efficiency and usability by simplifying contact management. Enforcing duplicate name restrictions forces users to create workarounds (e.g., appending suffixes such as "John Lee one" or "John Lee class A"), increasing the cognitive load and defeating the app's purpose of reducing administrative tasks. Alternatively, allowing students with the same name and differentiating them by using the tags (but it only allows alphanumeric without space, and it could be less informative) will also be a better way than the current implementation. This directly violates the stated goals of improving the user experience for its primary audience. The system already allows duplicate values for other fields (e.g., phone numbers, emails, or addresses). Restricting names while permitting duplicates in other fields is inconsistent and arbitrary, creating a confusing user experience. This inconsistency points to an oversight in the design, not an intentional feature. While the team might argue this is a subjective design choice, it is more appropriately classified as a usability flaw. It limits functionality by unnecessarily restricting legitimate use cases. In addition, it contradicts the typical use cases of the target audience (e.g., managing students who share common names). The term "Not in Scope" applies to features or issues outside the defined project boundaries. This issue is not outside the scope—it directly pertains to the app's core functionality of managing contacts efficiently. Enabling users to add students with the same name is a fundamental feature for a contact management system, especially for the app’s intended audience. Therefore, labeling this as "Not in Scope" is factually inaccurate.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Medium severity is defined as an issue that affects a core feature or function but has a workaround. While a workaround (e.g., appending suffixes like "John Doe one") exists for this bug, it is cumbersome and unintuitive, particularly for the app's intended users. The repetitive need for workarounds disrupts the efficiency and simplicity that the app promises to deliver. Adding students with the same name is core functionality for a contact management app targeted at private tutors managing multiple students or classes. By restricting duplicate names, tutors are forced to manually create artificial identifiers, adding unnecessary effort and increasing cognitive load. Moreover, the added complexity contradicts the app's value proposition of enhancing efficiency and simplifying data management tasks. The inability to add contacts with the same name, despite differences in other fields (e.g., phone, email, address), introduces a significant usability problem, affecting the app's primary use case. Private tutors are likely to encounter students with the same names (e.g., “John Tan,” “Alex Tan”) across different classes or sessions. Preventing them from adding these names disrupts their workflow. This increases frustration and could deter users from adopting the app, as the workaround deviates significantly from expected behavior in contact management systems. A low-severity bug is one that causes minor inconvenience but does not affect the overall functionality of the system. However, this bug impacts core functionality (adding and managing contacts effectively), forces users to implement workarounds that are neither minor nor intuitive and creates a significant usability issue that directly contradicts the app's stated purpose of improving efficiency. In short, this issue meets the definition of medium severity because it directly impacts a core functionality (adding students with the same name), has a workaround that is time-consuming and counterintuitive, and introduces a significant usability issue for the app’s primary audience. Labeling it as low severity underestimates its impact on the user experience and contradicts the app’s value proposition. Therefore, it should be reconsidered as a medium-severity bug.
Student different name but same phone number, email and address are allowed. It is possible to have two persons with exactly the same name and address but not for email or phone number.
Hence, can consider to differentiate person by phone number or email address.