Team's Response

This bug is a duplicate because it is still referring to the case sensitivity validation in class names (which is actually a feature decided by our team). We have made this case-sensitive for a reason and that is because when teachers want to export the information for admin work, the office might be particular about the case sensitivity.

The 'Original' Bug

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

Case sensitivity of select command

Steps to reproduce bug:

type select 4e2

Expected output: details of all students from the class 4E2

Actual output: error message saying class does not exist

Reason for bug report : Although it is mentioned in the user guide that the select command is case sensitive, for all practical purposes this is overzealous input validation. In a real life scenario one may enter 4e2 in a hurry and be met with an error message saying that the class doesn't exist. This issue becomes worse if the class names are longer.

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

Their Response to the 'Original' Bug

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

Thanks for the issue. Firstly, our team don’t think this is an overzealous input validation because we have designed the class names to be case sensitive when they are added into TeachBook, and we would like to use capital and lowercase letters to differentiate the two classes. Furthermore, if you really want to consider this as a feature flaw, we think it is of low severity because this is unlikely to affect teachers’ normal use of the app and only appears in rare situations: 1) under normal situations, teachers can be very familiar with class names, and it is not easy to type wrongly 2) if a user finds a class name is too long/strange to type out, he/she can always edit it to become a simpler one.

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.Rejected]

[x] I disagree

Reason for disagreement: Thank you for the response. However, I'd like to disagree with this bug being rejected for the same reasons of not modelling a real world scenario accurately. As a teacher, I should not be able to create a new class that differs solely by case in the first place.

:question: Issue type

Team chose [type.FeatureFlaw] Originally [type.FunctionalityBug]

[ ] 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: The reason this is of medium severity is the potential data inconsistency that can arise due to the existence of the 2 copies of the same data. The user may go and edit details in one version of the class but not for the other (which only differs by case and actually refers to the same one), resulting in data integrity issues, although the user may still be able to continue using the product.

In response to this : "the office might be particular about the case sensitivity", this is regarding the export aspect, in which case the exported information can be formatted according to the specifications. However, the user should not have to bear in mind the case they must type in during every usage. If in any case this "office specification" were to be reflected in the app (like say all names in all caps), then regardless of the case the user enters, the class name in the display list should be displayed in all caps (which won't take much changes to implement), but taking the stakeholders' needs into account will be impractical for generalization purposes.

aishh12 / pe

Possible to add duplicate classes if only case differs #5