search

rexkoh425 / pe

0 stars 0 forks source link

UG not clear parameters are not case sensitive #7

Open rexkoh425 opened 2 weeks ago

rexkoh425 commented 2 weeks ago

image.png

The UG did not mention the parameters to filter by category is not case-sensitive and this might also cause problems if the user have tons of category which just differ by case.

to reproduce 1)add-expense ChiCha a/ 18 d/ 0001-01-03 2359 c/ FNB 2) add-expense ChiCha a/ 18 d/ 0001-01-03 2359 c/ FnB 3) view-expense

nus-pe-bot commented 1 week ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Allows me to add a new expense of a category without having to create it

image.png

image.png

image.png

stepes to reproduce

1)add-expense a/ 6 d/ 2024-09-09 c/ FnB 2)add-expense a/ 6 d/ 2024-09-09 c/ FNB

For the first command , it prompted me to create the FnB category which is correct but for the second commmand it did not prompt me to create "FNB" category which is different from "FnB". Instead it just accepted it. It is mentioned in the UG that the category is unique as well. It is not mentioned in the UG that it is case-insensitive thus it would be assumed it is case-sensitive at the time of testing.

[original: nus-cs2113-AY2425S1/pe-interim#471] [original labels: severity.Medium type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Thanks for raising this. The entry is case-insensitive, not addressed in the UG. It does not affect normal operation as for most cases, difference in case should be imply the categories are different.

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: The 'Original' bug is about the difference in design of the different commands , allowing 'FnB' and 'FNB' to exist although only 'FnB' is shown in the list of categories.

However, my bug is regarding the lack of documentation for the view-expense command specifically. Although the feature is case-insensitive and is usable by the user, it is not included in the user guide, resulting it to be lesser useful than intended. E.g. the reader could have typed "fnb" to filter but thought that it was case-insensitive since it is not documented. The user continues to use the product thinking that it was case-sensitive and spend more time matching letter case. This is independently fixable simply by telling the users that all categories that match will be shown regardless of case so users know this is indeed the expected behaviour and increase the convience of using the command.

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.DocumentationBug`] - [x] I disagree **Reason for disagreement:** For the view-expense specifically mentioned in my bug report , inconvience to the user/reader stems from the lack of documentation, making user not know other functionality of the feature.