soc-pe-bot
commented
4 days ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Use of "/" not allowed for name field
Users are not allowed to enter "/" for name field even though it is possible for names to use "/". Disallowing s/o in a person name because / is used as a command delimiter can cause a major problem if the input is expected to match the legal name of the person. Therefore, it would be better if "/" was allowed
[original: nus-cs2103-AY2425S1/pe-interim#1786] [original labels: type.FeatureFlaw severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
The application was not designed with the legal names of each resident being used by the dorm manager in mind, given that it is unlikely that records from the app will be used for legal purposes. Specifically, we expected the dorm manager to use this to informally keep track of their residents, and expected them to name the students however they wanted in the application.
Accordingly, we allowed characters like commas, apostrophes, dashes and even numbers to make it easier for the user to format the names but did not implement inclusion of the slash character to prevent errors that may arise when parsing the command and its parameters.
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 bug that this was marked as a duplicate of disagreed with the product's decision to disallow slashes in a contact's name. This is a design decision, which I respect and accept that it simplifies the process of parsing. The most straightforward way to fix this bug would be to change the validation regex for names to permit slashes.
However, the bug that I am raising is not that slashes aren't allowed, but rather that the keying in of some names with slashes leads to incorrect contact creation. In the given example, a name such as "Prathy a/p Bhaskar" should be rejected by the system, in the event that a user who has not read the User Guide starts using the app based on the commands listed in help. However, the command is accepted and an incorrect contact is created, leading to wrong data about an address being present, as well as an incomplete name. This may make the find command less useful in the future too, when a user is attempting to search up the contact details of a person but their name has been saved incomplete.
The fix for my bug would likely be more complicated, and so I agree that this is out of the project scope, but it is unlikely that changing the validation regex would be sufficient to fix it. Therefore, I do not think that this is a duplicate of the given issue, and the team's response to the given issue does not address the issue that I have raised.
## :question: Issue response Team chose [`response.NotInScope`] - [ ] 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:** As per the course website, a severity.Low bug only appears in very rare situations and causes a minor inconvenience only. However, one would expect that slashes in a person's name would occur more commonly than that. In Singapore, the Indian community comprises ~9% of all residents. 9%, or any integer, hardly seems like a "very rare" situation for a dorm manager who has to manage many rooms and many students. Even with a measly 20 students, the likelihood of not having a single Indian student whose name would pose a problem for this product (assuming random selection) is under 16%. Any country where `a/p` or `a/l` is used to indicate parental lineage in a child's name would hence be even more likely to run into issues with this bug. Furthermore, the inconvenience is not so minor. This bug does not show an error to the user, so an unsuspecting user may have many incorrectly saved contacts before eventually identifying that they were saved wrongly, hindering the user's attempt to locate contacts and identify their names. Therefore, it would be more accurate to say that this flaw causes occasional inconvenience to some users (such as those operating in regions with high Indian population) that they would have to work around. In my opinion, this is better reflected by severity.Medium.
The name constraints only allow for 3 non-alphanumeric characters: hyphens, commas, and apostrophes.
However, conventional naming for Hindu and Sikh individuals can include
a/landa/pto represent "son of" and "daughter of" respectively, and these naming constraints result in unexpected contact creation.The below image shows the contact created when adding a new contact
add n/Prathy a/p Bhaskar p/90011234 e/prathy@example.com.