nus-se-script
commented
10 months ago Team's Response
We believe that this is a duplicate as once we fix issue #1406, this issue will be fixed too.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Identical Person in Group
From my understanding, you guys check index using email. However, I was still able to add the same email into a group:
You can try replicating this bug by:
- editing the original AlexYeoh's email to something else
- Create a new person with alexyeoh's old email
- Join said person to the same tut group.
[original: nus-cs2103-AY2324S1/pe-interim#1167] [original labels: type.FeatureFlaw severity.Medium]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
It is a functionality bug as this bug should not be allowed, but it worked in his/her case. We labelled it a low severity as we believe that it is not common for users to do the action(what the tester tested) or change their email(we intended email changes in the case of typos, not for deliberate changes).
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 indicated duplicate bug is for adding an identical person
This bug is about the inability to delete an old person object from the group.
Since the nature of the bugs are different, they cannot be considered as a duplicate bug, as the team has claimed.
Referring back to the screenshot, they input: "In the PE, we have to keep independently fixable things as separate bugs, to avoid complications in grading."
The logic for adding and removing an edited person is fundamentally different. Hence, although the edit person doesn't update the existing person object, the remove function should still be able to handle the removal of feral inputs.
## :question: Issue type Team chose [`type.FunctionalityBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** While this can be a grey area... If theres a function named `leave`, but it cant remove a ghost object (i.e ghost cant leave), it feels like the `leave` command is not doing what it should be doing. Hence a feature flaw, as it is incomplete. 
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Being unable to undo/ delete erroneous data brings complications to the users, as they wont have the correct data. This would hinder their ability to use the product. (i.e being unable to remove a ghost object causes the product to be unusable to the user, which is a major problem). Referring to the CS2103T website:  This bug should not be classified as low. It should be High. Assuming that this is infact a duplicated bug, this issue spreads far and wide, affecting the user's ability to join/exit groups. Moreover, a ghost person object results in a group to be unusable, and users would have to make a new group and transfer the data. If there are any edits to any email in the app, this issue will reappear... Hence, it will be unusable for users. (They might just stop using this app due to how buggy it is)
** Please refer to issue 3, issue 4, issue 5, as this is a follow up.
Due to the object referencing bug. Even if I want to remove the "ghost" person from my group, I am unable to do so. This is frustrating, as users wont be able to properly track the students to connect.
As such, I will put this as high severity, as this seems to conflict with your app's main purpose, which is to allow users to have a seamless, hassle-free team formation solution.