Concert name validation has same restriction to person name

[yixianggg]

As seen from the screenshot, the validation check for concert name seems to be the same as for person name, only allowing alphanumeric characters and spaces. This may have been something that was overlooked.

In reality, concert names differ greatly from person names, and can take many different ways of naming. Just search upcoming concerts in Singapore and one can view the upcoming concerts, where many (most in fact) are named with some special characters.

Here are a list of a few, whose names would have been disallowed: Fiji Blue: The "Glide" Tour Asia DAY6 3RD WORLD TOUR in SINGAPORE Porter Robinson SMILE! :D World Tour Charlie Puth Presents "Something New" MAYDAY #5525 LIVE TOUR IN SINGAPORE

The team could explore implementing a different validation check for concert names.

[soc-pe-bot]

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Names of concert can have nonalphanumeric characters in real life but application does not allow

Many concerts have nonalphanumeric characters as their concert name due to creative/aesthetics reason. However, the application does not allow that to be reflected which I believe is a Feature Flaw since it does not allow the app to capture the name of concert as intended.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#3352] [original labels: severity.Medium type.FeatureFlaw]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Hi, thanks for the feedback! We understand that the application not capturing the name of concert as intended is indeed a FeatureFlaw.

We believe that this can be considered Response.NotInScope for 3 different reasons.

• Concert Organisers do not need the exact name of the concert to identify a concert. For instance, Fiji Blue: The "Glide" Tour Asia can still be recognised even when its name is modified to Fiji Blue The Glide Tour Asia. Since concerts can still be added without the use of special characters and without lost of information, we believe that users will still be able to use our App and we left it as such for the current iteration.

• Due to time constraints for the TP, fixing the name to be in an OOP manner was of a lower priority and we stuck to using the same constraints.

• Lastly, we mentioned that this is something that will be worked on and improved in the next iteration.

  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.NotInScope`] - [x] I disagree **Reason for disagreement:** Hi! Unfortunately, I disagree with it being NotInScope. As mentioned in the PE instructions for response NotInScope, it is for "a valid issue, but fixing it is less important than the work done in the current version of the product". Again, I feel that fixing this issue is extremely important. As I have shown in my bug report, majority of concerts do in fact use special characters in their naming. With this being said, although it is true that the user could just skip these special characters when adding the concert to the application, it is in fact a feature flaw given that a user would not be able to add the name of majority of concerts, as it should be. I would accept it being NotInScope if most concerts do not have special characters in their name. However, as I have mentioned, the prevalence of special characters in concert names make this a real flaw that should have been spotted earlier. The failure to spot this flaw shows that the team overlooked doing research to truly cater to their target audience. Furthermore, point 3 states that the team has already mentioned this as a future improvement. However, I did not find any planned enhancements in their Developer Guide, which we were instructed to add in given that we had any future planned improvements that could render this NotInScope. All I could find was the following paragraph in the User Guide:  In this paragraph, it mentioned that what was to be fixed was the fact that concert names allowed strings like "s/o" and "d/o", and they would fix that in future iterations. This planned fix is not specific, and seems to suggest the removal of allowing the aforementioned strings, instead of allowing special characters in general, which is the issue here. I feel that there was a massive oversight by the team as they decided to use the `name` class for both person name and concert name out of convenience, which gave rise to this issue. Given that this issue impacts majority of inputs and there is a quick fix, I feel that it is definitely not of low priority or importance and should not be NotInScope.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Again, I disagree with this downgrade. As I have mentioned, the prevalence of concert names with special characters is extremely high, and the fact that concert managers are unable to input majority of concert names as they should be is indeed an issue deserving of a higher severity. With that being said, upon hindsight, I do feel that the severity should be Medium instead of High, as I can understand and relate to the team's first point in their reasoning, given that it does not cause a huge issue if the concert manager simply modifies the name to leave out special characters - the names are still identifiable and distinguishable. However, I feel that it should be Medium instead of Low as I have mentioned, although this provides a small inconvenience, its regularity makes this flaw one of higher than Low severity as concert managers can see this as a turn off (multiple small inconveniences can add up to a substantially large flaw).

---