search

ignatiusoey09 / pe

0 stars 0 forks source link

Appointments have no minimum duration #6

Open ignatiusoey09 opened 1 week ago

ignatiusoey09 commented 1 week ago

image.png

Currently, appointments do not have a minimum length, allowing users to set appointments as close as 1 min after each other. This makes it prone to user error as users who mistyped will setup an appointment which is unfeasible

Recommendation:

soc-se-bot commented 1 week ago

Team's Response

Our decision to not include end time/duration for appointments considered the unpredictable nature of the duration of appointments.

Example: appointment ends early and receptionist want to schedule a walk in appointment -> need to edit the end time of the first appointment, otherwise there would be a time clash when adding the new walk in appointment. This would end up creating more work for the receptionist.

Hence it would be easier to just add the new appointment first with a reasonable start time after any previously scheduled appointments (e.g 1h).

Due to this current workaround, we believe the current app can still function normally as intended and that the issue is out of scope for this iteration.

The 'Original' Bug

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

Appointment end time/duration not accepted

Expected: Receptionists would like to know when an appointment will end so they can schedule an appointment with another patient when the doctor is free.

Actual: However, I am not able to specific how long an appointment could take, meaning I can schedule appointments 1 minute away from each other:

image.png

Steps to reproduce:

  1. Assume John Tan is a doctor and John Doe and John Teo are patients.
  2. Enter add-appt pn/John Teo dn/John Tan d/23-04-2024 t/1100
  3. Enter add-appt pn/John hehe dn/John Tan d/23-04-2024 t/1101

Suggestions: Accept the duration of an appointment and block out the doctor's schedule for that time.

[original: nus-cs2103-AY2425S1/pe-interim#1498] [original labels: severity.Medium type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Our decision to not include end time/duration for appointments considered the unpredictable nature of the duration of appointments.

Example: appointment ends early and receptionist want to schedule a walk in appointment -> need to edit the end time of the first appointment, otherwise there would be a time clash when adding the new walk in appointment. This would end up creating more work for the receptionist.

Hence for the situation provided for by the tester, it would be easier to just add the new appointment first with a reasonable start time after any previously scheduled appointments (e.g 1h).

Due to this current workaround, we believe the current app can still function normally as intended and that the issue is out of scope for this iteration.

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.NotInScope`] - [x] I disagree **Reason for disagreement:** The example given by the testing team of "receptionist wants to schedule a walk in appointment" is irrelevant as the app is aimed at helping clinic receptionists manage and organize appointments. As such, spontaneous changes such as walk-ins are outside the scope of the app and do not need to support it. The point still stands that the lack of end times for appointments makes it harder for receptionists to organize schedules as: - It is prone to user error (i.e. receptionist meant to type 1200 but typed 1201, scheduling a 1 minute appointment) - Different types of appointments naturally require different durations. As such, no end times makes it harder for the receptionist as they need to find the type of appointment to properly schedule the next one without a clash.