search

dreammac3816547290 / pe

0 stars 0 forks source link

Item duplicate detection is case sensitive when it should not be #1

Open dreammac3816547290 opened 2 years ago

dreammac3816547290 commented 2 years ago

image.png

Using the sample data, when I run the command new n/milk it adds the item and does not detect that Milk and milk is the same item (realistically, it should).

nus-pe-script commented 2 years ago

Team's Response

During the development of FoodRem, we were debating whether item names should be unique and case-sensitive (“Potatoes” and “potatoes” are different) or case-insensitive (“Potatoes” and “potatoes” are the same).

We have come to the decision that item names and tag names should be case-sensitive. This is clearly stated in the user guide in more than one place.

image.png image.png

Reasons:

  1. Some usages (e.g. using brand names in item names) are affected by case-sensitivity. Thus, it is better to have case-sensitivity than to not have them and eliminate these potential use cases.
  2. We expect to have several items. When a user needs to find an item they will likely use the find command instead of scrolling. The find command is case-insensitive. This implies users will immediately be able to detect this error. This complements the above point as to why it's better for FoodRem names to be case sensitive. (The screenshot below shows the result of find n/milk).

image.png

Thus we have decided that this is not a bug, it is intentional as stated in the UG and the explanation above.

The 'Original' Bug

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

Items of the "same" name can be added

I understand that in the User Guide it's mentioned that items are unique by name and case-sensitive and that I "cannot add two or more items of the same name."

However, I would say that 'potato' and 'Potato' are the same name.

To reproduce: add 2 items named 'potato' and 'Potato' respectively

I would say its good to differentiate products with names which are case sensitive but trivial items like potato, carrot etc probably wouldnt need this validation.

image.png

[original: nus-cs2103-AY2223S1/pe-interim#5665] [original labels: severity.Medium type.FunctionalityBug]

Their Response to the 'Original' Bug

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

Either way, this is not a functionality bug as FoodRem behaves as expected and stated in the User Guide. In terms of whether it is a feature flaw:

During the development of FoodRem, we were debating whether item names should be unique and case-sensitive (“Potatoes” and “potatoes” are different) or case-insensitive (“Potatoes” and “potatoes” are the same).

We have come to the decision that item names and tag names should be case-sensitive. This is clearly stated in the user guide in more than one place.

image.png image.png

Reasons:

  1. Some usages (e.g. using brand names in item names) are affected by case-sensitivity. Thus, it is better to have case-sensitivity than to not have them and eliminate these potential use cases.
  2. We expect to have several items. When a user needs to find an item they will likely use the find command instead of scrolling. The find command is case-insensitive. This implies users will immediately be able to detect this error. This complements the above point as to why it's better for FoodRem names to be case sensitive. (The screenshot below shows the result of find n/milk).

image.png

Thus we have decided that this is not a bug, it is intentional as stated in the UG and the explanation above.

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]

Reason for disagreement: [replace this with your explanation]

:question: Issue type

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

Reason for disagreement: [replace this with your explanation]