search

cristoforows / pe

0 stars 0 forks source link

Can not add appointment #6

Open cristoforows opened 2 years ago

cristoforows commented 2 years ago

in the example below, John Doe (patient) and John Doe(doctor) do not have an appointment on 2022-04-16, the exception might be wrong, perhaps debug the exceptions a bit

image.png

nus-pe-script commented 2 years ago

Team's Response

The underlying issue is the psuedo-random way in which the appointment id is generated, which has been elaborated and responded to in issue #760.

The 'Original' Bug

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

User is unable to add appointments under specific circumstances

This seems to be a bug with the way the appointment ID is automatically generated. From what I can tell, the default appointment ID is generated as: <first 3 digits of patient NRIC> <last 3 digits of patient NRIC> <MMDD of appointment date> <2nd to 5th digits of doctor NRIC>. Any collision in appointment IDs is immediately rejected by the program as a duplicate appointment, when this is not always the case.

One easy-to-trigger consequence of this is that if the same patient and doctor make 2 appointments exactly one year apart, the user cannot add both appointments to the application at all. There is no function to edit the appointment ID, which means this bug cannot be worked around.

Steps to reproduce:

  1. add patient /info S0001000A, Alice A, 22, M, 10 Baker Street, 1999-12-31, 2021-02-15
  2. add patient /info S0002000B, Bob B, 22, M, 10 Baker Street, 1999-12-31, 2021-02-15
  3. add doctor /info S1234567A, John Doe, 22, M, 10 Baker Street, 1999-12-31, Urinology
  4. add appointment /info S0001000A, S1234567A, 2023-01-01, test
  5. Now, try any of the following inputs (not an exhaustive list):
  • add appointment /info S0001000A, S1234567A, 2024-01-01, test
  • add appointment /info S0002000B, S1234567A, 2023-01-01, test
  • add appointment /info S0002000B, S1234567A, 2024-01-01, test

Expected outcome: all of the inputs should succeed.

Actual outcome: all of the inputs are rejected as duplicates of an existing appointment, even though it is possible that the patient and/or doctor involved is not even the same.

image.png

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

Their Response to the 'Original' Bug

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

The tester is correct regarding the flawed way in which the appointment ID is generated which is pseudo-random, hence allowing for some collisions to occur due to exceptional circumstance. However, the severity is at most medium since it is unlikely that the mentioned numbers align so specifically to cause collision in a real world working environment. This is also demostrated by the tester which deliberately used specific values that are not common in the real world.

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 severity

Team chose [severity.Medium] Originally [severity.High]

Reason for disagreement: [replace this with your explanation]