nus-pe-script
commented
6 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]
Add feature does not allow '/' in name
According to the UG, "Names should only contain alphanumeric characters and spaces, and it should not be blank".
In accordance with the CS2103 handbook, the term s/o may be part of somebody's legal name and not being able to include their full legal name could be a significant problem.
[original: nus-cs2103-AY2425S1/pe-interim#1754] [original labels: type.FeatureFlaw severity.Low]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
No details provided by team.
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 severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I do agree that it is a duplicate issue, however I feel that it is of severity `Medium` instead of `low` as it may cause occasional inconvenience to some users, but they can continue to use the product. Firstly, the target user are insurance companies which mainly supports tracking of insurance policies, thus I will assume is for any company around the world. Lets say for instance this product in a company or a group of insurance companies in a country who has a large target audience with people who has legal names what contains `/` . Then unfortunately, this will cause perpetual inconvenience to every use or majority of the users. However I understand this should not be a `High` because this will not be an issue for other demographics of consumers of the product. There are quite a few reasons why the name must be correct in the database is because of a few factors as listed below: - Verification - Fraud detection - Claims verification - Regularity requirements Just to name a few. I also feel that this is the case for many other scenarios as well not just for insurance companies thus I feel that certain particulars of a person not just limited to name, like phone number and email address should be recorded with precision rather than a work around or just rejecting some characters.
Screenshot
How to replicate
add n/John s/o Doe p/98765432 e/johnd@example.com addr/311, Clementi Ave 2, #02-25 b/1990-10-10 appt/2024-12-12 12:00Description
I feel that as client management system some people's names might have special characters like
/. Thus I feel that you should not only accept alpha numeric character only but allow some special character such as/.Even if the intention was to not allow
/then as a insurance company names of clients are important and thus how should 1 go about if their name has a special character.