search

1szheng / pe

0 stars 0 forks source link

Return command returning random non-chronological borrows #7

Open 1szheng opened 2 years ago

1szheng commented 2 years ago

The return command does not prioritize returning longest overdue borrow. It is unknown to the user which items will be returned if the return command is issued.

This will cause many issues to the user using the product as it would feel like the return command is returning borrowed items at random.

image.png

image.png

nus-se-script commented 2 years ago

Team's Response

No details provided by team.

The 'Original' Bug

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

Unintuitive return feature

The return command is unintuitive and does not allow user to control which borrowed entry is returned. For the picture below, if BETA was the borrower who returned the item, the user is unable to let BETA's borrow be marked as returned without affecting the previous borrow.

This means that John Smith's borrow would need to be returned if BETA returns his borrow.

image.png

[original: nus-cs2113-AY2122S2/pe-interim#1154] [original labels: type.FeatureFlaw severity.High]

Their Response to the 'Original' Bug

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

This bug was created as a result of the "Return" command being designed with the thought that there would only be 1 quantity of each item. For items with only 1 item quantity, this bug would not be an issue as there would only be 1 overdue/outstanding borrowing at any point in time, and the relevant overdue/outstanding borrow record would be marked as returned.

However, with that being said, it is true that this bug would be a problem whenever an item consists of quantity greater than 1 and partial quantities of an item are borrowed at the same time. The command would return the borrow record that was entered into the system first. However, we do not think that this warrants a severity high as this bug would not affect ALL items in the inventory (only items with quantity greater than 1). Plus, this error would only pop up when there are borrow records with overlapping durations on the same item. Without overlapping borrow records, this bug would not show up. It would also not render the entire application entirely unusable (In the worst case, the user can still list individual items and borrow them individually).

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]