yixiann / pe

0 stars 0 forks source link

Ability to create persons with the same telegram username #14

Open yixiann opened 1 year ago

yixiann commented 1 year ago


video:https://raw.githubusercontent.com/yixiann/pe/main/files/b6cb589a-9f77-4af9-b999-d03723fd239c.mov

Telegram usernames are unique and no two individuals should have the same username unless they are the same person.

soc-se-bot commented 1 year ago

Team's Response

Both issues are about the add command allowing the addition of a new person that has the same Telegram handle as an existing person.

Severity adjusted to low as it is unlikely for users to mistakenly input an existing telegram handle while adding a new person, since the details of the added person are displayed after the add command is executed, so they can double check whether their inputs were correct.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Add feature should not allow for multiple handles

Screen Shot 2022-11-11 at 4.49.04 PM.png Screen Shot 2022-11-11 at 4.49.52 PM.png

People usually have their own telegram account and do not share with other people, furthermore this makes managing debts confusing as the debt collector does not know who he or she is contacting.


[original: nus-cs2103-AY2223S1/pe-interim#3488] [original labels: type.FeatureFlaw severity.Low]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

In the current iteration, our app does not check for duplication of fields such as phone number, address or telegram. Our app only checks for duplication of name.

It is unlikely for users to mistakenly input an existing telegram handle while adding a new person, since the details of the added person are displayed after the add command is executed, so they can double check whether their inputs were correct.

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)

Reason for disagreement: [replace this with your explanation]


:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Acceptance of the dev team's decision for duplicate status, issue type, and issue severity

During the initial phase, I selected this as a functionality bug. However, this was wrong, as it was not stated anywhere in your user guide that validation was done to ensure that telegram handles are unique. Thus, I stand with your decision to agree that this is a [type.feature flaw] instead of a [type.functionality bug].

During the initial phase, I selected this as a [severity: medium]. However, this was wrong, as this issue will only arise if a user makes a mistake, which is unlikely, as you alluded to in your response. Thus, I stand with your decision to agree that this is a [severity. low] instead of a [severity. medium].

Additionally, I agree that this is a duplicate of another issue, as suggested by the dev team.

Rejection of the dev team's decision for issue response

However, what I do not agree with is the decision that this is [response.NotInScope].

I believe this is still a feature flaw for the following reasons:

"In the current iteration, our app does not check for duplication of fields such as phone number, address, or telegram. Our app only checks for duplication of name."

I have no issues with not checking the address, as two individuals may potentially stay in the same house. However, I have issues with validation not being done for the phone number and telegram.

Since this bug report was initially for duplicate detection of telegram handles, I will only argue for the case of telegram handles, despite similar arguments that can be put forth for phone numbers. This is despite the fact that a lack of validation for the phone number (which I did not realise) may potentially raise the severity of this incident.

  1. In this application, names are not required to be legal names; thus, unique telegram handles must be validated to prevent the user from making an error. The issue “Name input do not allow s/o which is a valid name. UG do not specify it restricts this constraint as well.”, the development team stated:

This means that the names in the application may consist of several nicknames.

Additionally, in the User Guide, it is suggested that users circumvent issues where two friends have the same name by using different capitalizations, as shown below.

image.png

This shows that telegram handles play an important role in identifying friends, as it is unlikely you remember which friend is "issac" or "issac". Additionally, it is more likely that two individuals have the same nickname or even the same legal name, as telegram handles are strictly unique and you can actually have two friends with the same name.

  1. There is no harm in validating the telegram handle.

Given that names are validated to be unique to prevent duplicate friends stored in the application, there is no harm in validating telegram handles as well. This is because no two individuals will ever have the same telegram handle.

  1. It requires minimal effort to verify that a telegram handle is unique, as there is already logic implemented to check that the person's name is unique. There is no need to push this fix to a future date. Changing one line in the below mentioned code will solve this problem.

image.png

  1. The development team mentioned that  

"It is unlikely for users to mistakenly input an existing telegram handle while adding a new person, since the details of the added person are displayed after the add command is executed, so they can double check whether their inputs were correct."

I believe this is for a different issue. The user may check if the information is correct while keying in the information and viewing the details of the added person; however, the user is not able to easily check if somebody else (who is referring to the same individual) has the same telegram handle. The correctness of information keyed in is not related to validation of uniqueness of telegram handles (which indicated the presence of duplicate individuals).

If the user sees two individuals with different names stored in the application but the same telegram handle, it is obvious to the user that an error has occurred. And the user would only be able to detect this error in later uses of the app, not when creating a person.

  1. AB3 Does not validate if two users have the same phone number. However, this is fine as a user will still be able to achieve their purpose. E.g two people named bobby (referring to the same person) with the same number, would not cause an issue as the user will be able to find any one of them and obtain the information they require. However, when dealing with debt, having the same individual with information about different debts, hidden in two different places due to the lack of detection of uniqueness, would cause some debts to be hidden. A user may inform his friend that the friend owes him $10 but suddenly realised it is $20 due to failing to realise that there are two of the same person located in the application.

  2. [Personal View] I feel that this is an oversight rather than an intended behaviour reserved for future implementation, thus a feature flaw.


:question: Issue type

Team chose [type.FeatureFlaw] Originally [type.FunctionalityBug]

Reason for disagreement: [replace this with your explanation]


:question: Issue severity

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

Reason for disagreement: [replace this with your explanation]