search

PallonCX / pe

0 stars 0 forks source link

Disallow certain characters in name #3

Open PallonCX opened 6 months ago

PallonCX commented 6 months ago

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.

Screenshot 2024-04-19 at 5.06.55 PM.png

nus-pe-bot commented 6 months ago

Team's Response

Thanks for raising this. However, this has been addressed under the Known issues section of the UG, where a workaround has been stated:

image.png

Further pointers to add: Having a contact name match exactly to a legal name is not a requirement of our application, as we are not handling any confidential data(that requires strict identification) that will jeopardise any personal identity or property. (For example, handling legal contracts in the purchase of property)

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Thanks for the developer team's response. However, according to the course website and this forum post (https://github.com/nus-cs2103-AY2324S2/forum/issues/898), a known issue in the User Guide (UG) is not the same as a planned enhancement in the Developer Guide (DG). Therefore, testers are still allowed to report such feature flaws.

Furthermore, although I agree with the statement "Having a contact name match exactly to a legal name is not a requirement of our application," considering the nature of the application where users will record professors' and tutors' details, as a token of respect and formality, users may prefer to record the contact's legal full name instead of just a nickname.

Additionally, I believe that the developer team has expected users to record a contact name as a legal name, as they suggested using so or son of to replace s/o in the fourth point of the known issue (refer to the screenshot provided in the team's response above). If the developer team really emphasizes "Having a contact name match exactly to a legal name is not a requirement of our application," it would be more reasonable to suggest users to store a short name or nickname without symbols, instead of just advising to workaround with the symbol and continue storing the full name. Hence, I believe that the application needs to be able to handle contact names that contain symbols.

To conclude, I disagree that this is flagged as response.NotInScope, and suggest that this should be considered a low severity feature flaw, for the following reasons:

  1. The issue is addressed in the Known Issue in UG instead of the Planned Enhancement in DG, which means it has no immunity to feature flaws, especially when this issue is explicitly mentioned to be a feature flaw on the course website.
  2. While the developer team mentioned "Having a contact name match exactly to a legal name is not a requirement of our application," users are not explicitly disallowed to do so, and it's reasonably possible for users to do so due to the nature of the application. Hence, the application needs to be able to handle contact names that contain symbols.