soc-se-bot
commented
1 week ago Team's Response
Thank you for your bug report!
We acknowledge that certain naming conventions, such as "Xavier e/o Charles," while exceedingly rare, still has a possibility of occurring in real-world scenarios. However, we are classifying this issue as not in scope for the following reasons:
Rarity of "e/o" in Names Names containing "e/o" are exceedingly uncommon. This makes the likelihood of encountering this issue in real-world usage extremely low. The application’s focus is on supporting standard naming conventions that cover the vast majority of cases. Therefore, common special phrases like "s/o" and "d/o" are supported.
Technical Constraint The prefix "e/" is reserved as a parameter identifier for email for commands in the application, creating a conflict when used within a name. Allowing "e/o" as part of a name would require significant changes to how the application parses commands, potentially introducing complexity and unintended side effects, making this improvement out of scope for the current version and an issue for future versions to resolve the clash.
Project Scope and Priority The application's primary objective is to support efficient and reliable patient management for typical use cases. Adjusting for such rare edge cases falls outside the current project scope and is more appropriate as a potential enhancement for a future version.
Suggested Workaround Users can replace "e/o" with an alternative representation, such as "e_o" or "EO," to avoid the conflict while preserving the intended meaning.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
I cant add patient named Xavier e/o Charles even though it is a completely possible name. It is especially crucial for a medical app to work with all possible naming, since the patients are diverse and could be from everywhere.