soc-se-bot
commented
11 months ago Team's Response
We have re-assigned this to FeatureFlaw because it was intended that we check duplicates (phone number) within members and applicants only, and not across. Users might accidentally add a member when they intended to add an applicant instead, and want to easily see the member details to correct their mistake by adding an applicant before deleting the member. Another use case might be an applicant becomes accepted into the CCA and is a member, and the user wants to add a member into the system while referring to the applicant's details in the list.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I believe it should be `Medium` for the following reasons: 1) In this application, you are using phone number to check for duplicates. Meaning if 2 people have the same phone number, by your logic, they are the same person. 2) The same person cannot be both a member and an applicant. 3) In the interim, if there is a transfer of data (lets say someone is transferring from an applicant to a member), and the user does not remember to delete the applicant details, then the app does not stop this, and the data would be wrong. Overall, since there isnt a case where a person is both a member and an applicant, it would make sense to check across this, and make sure there arent duplicates across members and applicants.
As the title suggests, in the screenshot above, I am referring to member 4 and applicant 7.
Given that your duplicate check is for phone numbers, Does it make sense for the member to also be an applicant?