Open rjkoh opened 2 years ago
Similar to the other issue, the edit function does work on duplicates, but the index of the edited food changed in this case because the two foods were recorded at the same time in the data file. While we acknowledge that this could potentially be confusing, it does not violate the intended behaviour of our food list, which sorts food items by their meal type. Additionally, this only happens in very rare cases, which is when the user deliberately sets the timing of two foods to be the same in the data file. However, for normal usage, we believe it is quite difficult to use the CLI to add two foods at the exact same time.
[The team marked this bug as a duplicate of the following bug]
Edit does not work on duplicates
Duplicates are allowed, which is good since a user might eat multiple of the same food.
However, if a user decides to edit the data file (since that is one of the functions of AB3 and your application's target as well), and puts the same default timing, edit function jumbles up the indexing.
Here, edit 3 ends up editing the calorie for index 4 instead.
[original: nus-cs2103-AY2223S1/pe-interim#4878] [original labels: type.FunctionalityBug severity.Low]
[This is the team's response to the above 'original' bug]
The 3rd food is actually edited and swapped indexes with the 4th food in the list. The list is sorted based on meal type only, hence the swapping of the two indexes does not violate the intended order of our list. Additionally, this issue only happens when two meals have the same timestamp, and it is unlikely for the user to be able to key in two meals at the exact same time using the CLI. However, you made a good point that the change in indexing could potentially be confusing, so we would consider addressing this issue in the future!
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]
Team chose [response.NotInScope
]
Reason for disagreement: Does not satisfy the conditions for not in scope as explained in the duplicate issue.
Team chose [severity.Low
]
Originally [severity.VeryLow
]
Reason for disagreement: [replace this with your explanation]
As mentioned in the previous report, edit's index does not work on duplicates.
However, after one is edited such that they are no longer duplicates,
e.g. changing calories
running the next edit command works properly but the indexing jumps.
here, after running edit 3 c/2, 4 is edited instead.
however, edit 4 c/3 now works fine, which might be confusing to users.