soc-se-bot
commented
4 months ago Team's Response
This comes under our planned enhancements which we hope to implement in the near future. As shown above we hope to add special character handling for names in our planned enhancements, hence, we shall reject this bug.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Names overly restrictive
Only allowing alpha numeric characters in names is overly restrictive, many legal names exist where '/' are needed. some non alphanumeric characters should be accepted.
Steps to reproduct:
- Run in CLI ' add n/John s/o Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 k/Joe s/o Doe d/Has a history of memory loss t/mentalIllness t/owesMoney'
Expected output: User added
Actual output: Error non alphanumeric names
[original: nus-cs2103-AY2324S2/pe-interim#1534] [original labels: type.FunctionalityBug severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
In our DG, we mentioned that this is a known issue and we are planning to implement this functionality in future iterations. Hence, we would like to reject this bug.
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)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
Description: Add command doesn't allow . as input in the NAME field
Steps to reproduce:
Screenshots:
Expected behaviour: Adam H. Powell should be accepted as a valid name
Actual behaviour: The name is not accepted
Notes: Since names (especially middle names) can include . as shorthand form, I allowing the period (.) to be accepted as part of the name inputs is reasonable.