Open cbj252 opened 11 months ago
We very intentionally made event names contain only alphanumeric and white space characters. We made this very clear in the user guide as well. We did this to keep event names simple and also to allow for better search results with the find command. Users can still do @nus by naming it more intentionally like "my nus event" and it provides better search results as well. This is an intentional design choice and not a feature flaw.
Team chose [response.NotInScope
]
Reason for disagreement: Stating the problem clearly in your UG and "Intentional design" does not prevent feature flaws. If I decided to make my font sizes in my program unreadable but said it was intentional because I like the style, putting it in my UG, should that prevent me from receiving feature flaws from the fact that my users can't see anything in my program?
"We did this to keep event names simple and also to allow for better search results with the find command."
In general, the group's response does not provide a convincing value proposition for prohibiting special characters.
This issue falls under overzealous input validation because blocking special characters does not add any value but allowing it does, as can be seen by the "@Nus" example in the original bug report, and other potential special characters, like chinese characters or the ! sign.
From the UG:
Event name can only use Use a-z , A-Z , 0-9 and whitespaces only. However, there's plenty of events that use special characters in their event names (most commonly @, as part of "@Nus") and blocking this can annoy users that are part of events using these special characters.