search

jonpwk / pe

0 stars 0 forks source link

Duplicate Transactions not Handled On Deletion of Person #14

Open jonpwk opened 2 months ago

jonpwk commented 2 months ago

Steps to Reproduce:

  1. Delete data file to obtain fresh install
  2. Open programme to obtain sample data
  3. Run this command twice /transaction 240001; 2000; Salary; 30/09/2021 12:00 to add 2 identical transactions to the programme
  4. Run /view 240001 to see both transactions
  5. Run /delete 240001

Expected Result: Both transactions are deleted and they disappear from the GUI

Actual Result: Only one transaction is deleted, resulting in an erroneous transaction.

image.png

Why is this a HIGH Feature Flaw?

Firstly, a transaction managing application should not allow for erroneous transactions to exist, where the person involved is no longer in the application.

Secondly, if the transaction ID were to be the most recently added (for example 240007 in the case of the sample data), then when 240007 is deleted and a new person is added, the "floating" transaction would belong to the new person, resulting in the wrong information.

nus-se-bot commented 2 months ago

Team's Response

Thank you for the feedback, we recognise this as a valid bug. However, we deemed the severity as medium as when a person with ID 240007 is deleted, the ID will never be reused in our system. Keeping the transaction will not actually cause any harm to the company manager. We recognise this bug can cause certain inconvenience but not making our feature completely unusable.

Items for the Tester to Verify

:question: Issue type

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

Reason for disagreement: [replace this with your explanation]

## :question: Issue severity Team chose [`severity.Medium`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** If the ID 240007 is the **LAST** added unique Person, upon deletion the next latest unique ID is 240006. Hence, upon deletion and re-adding, the NEXT new person has unique ID 240007. Therefore, the ID is in fact reused by the system and the erroneous transaction is tagged to the wrong person