nus-pe-bot
commented
1 year ago Team's Response
The intended behaviour is that there should never be two members with the same email. In this case it is only possible for two members to have the same email because of a bug with the edit command. This bug is addressed in another issue, so marking as duplicate.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Able to edit a member's email to that of an existing member even though it is restricted when adding a member
To reproduce: Edit a member's email to that of an existing member as shown in the screenshot. In the screenshot above, member 8's email is edited to the same as that of member 7.
[original: nus-cs2103-AY2223S1/pe-interim#4722] [original labels: severity.Medium type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
No details provided by team.
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: The fact that this bug happened is due to a lack of defensive coding techniques used to account for a possibility of there being multiple contacts with the same email when editTask pe/ is executed. Even if the "original" bug is fixed, this only means that no contact can be edited with an email being the same as that of an existing contact via the CLI. This still does not prevent multiple contacts having the same email possibly through modifying the data file, which I imagine would be not that uncommon given that the app is intended for hackathon leaders. Hence this bug could still occur even if "original" bug is fixed.
In addition, this bug can be independently fixed by employing defensive coding to check if there exists more than one match is found with the given email when editTask pe/ is executed. Subsequently, an error message along the lines of "Specified task cannot be assigned as there are multiple people with given email. Ensure that very contact has a unique email." could be returned.
In conclusion, the two bugs can be independently fixed and so I disagree with this issue being duplicate-flagged.
To reproduce: In the screenshots above, members 7 and 8 have the same email. Even though a user might intend to assign task 8 to member 8, using command editTask8 pe/roy@we.com assigns task 8 to member 7. In fact, there is no way to assign task 8 to member 8 unless member 7 is deleted.