dedsecrattle / pe

0 stars 0 forks source link

Tags are Case sensitive #9

Open dedsecrattle opened 2 months ago

dedsecrattle commented 2 months ago

image.png

Both tags allowed i.e Assignment1 and assignment1 which are essentially the same and refers the same information in terms of Functionality as a tag

Suggestion - Tags can be made case insensitive

mark 1 /t assignment1 /ts cg followed my mark 1 /t Assignment1 /ts cg

soc-pe-bot commented 2 months ago

Team's Response

No details provided by team.

The 'Original' Bug

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

The assignment name is case insensitive, so new assignment is created when trying to mark the assignment with different case

image.png

  1. Make sure that the person has Assignment1.
  2. mark 1 /t assignment1 /ts cg The Assignment1 should be marked because we don't usually distinguish them as separate assignment in real world. However, new one called "assingment1 is re-created. This might confuse user.

[original: nus-cs2103-AY2324S2/pe-interim#5538] [original labels: severity.Medium type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Quoting the text book

"Overzealous input validation: It is better to warn rather than to block when inputs are not compliant with the expected format, unless accepting such inputs can hinder the operations of the software. Allowing such flexibility can in turn allow the user to use the software in ways you didn't even anticipate while overzealous rejection of inputs can annoy the user."

While the suggested change does bring a higher level of convenience, it is conflicting with the current set of constraints we set for the tags. Currently, we are allowing the users to create tags with the same name but different capitalisation. Following this, making the mark command case-insensitive will lead to ambiguous situations where the app does not know specifically which tag to mark.

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)

Reason for disagreement: [replace this with your explanation]


## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** ![Screenshot 2024-04-24 041415.png](https://raw.githubusercontent.com/dedsecrattle/pe/main/files/141ad548-53fa-47ac-8657-062b76b5928f.png) command Executed - `find /t ASSIGNMENT1` ![image.png](https://raw.githubusercontent.com/dedsecrattle/pe/main/files/300fedcb-d4b7-4b37-86f6-5b93b4f414e2.png) > Currently, we are allowing the users to create tags with the same name but different capitalization. Following this, making the mark command case-insensitive will lead to ambiguous situations where the app does not know specifically which tag to mark. Quoting from team response , according to response tags are purposefully made case sensitive to allow user use same tag name with different Capitalization but `find` feature is case insensitive which is counter intuitive to the expected behavior and can cause confusion for users. So, this clearly suggests that the `tag` has this featureflaw and validation for inputs such as `Tags` are not overzealous as it align the users expectation for tags or labels i.e. assignment1 and Assignment1 are same from a users perspective Either the `find` should have been case sensitive tooo or else `tags` must be case insensitive to make this feature make sense to the user Suggestions - - It goes against common conventions and user expectations. In most applications and systems, tags or labels are typically case-insensitive, meaning "Assignment1" and "assignment1" would be treated as the same tag. - It increases the cognitive load on users. Users have to remember the exact casing of every tag they create, which can be error-prone and frustrating, especially when dealing with a large number of tags.
## :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.Medium`] Originally [`severity.Low`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]