Able to input staff input timing from a later to earlier time

[crmlatte]

Able to add shift timings that are backwards eg from a later time to an earlier time
Significance: user may have input PM as AM accidentally, but its accepted as a valid input

Steps to reproduce:
sa sid/S46 n/Jane p/1234 e/jane@example.com a/123, Tampines West Ave 7, #9-121 role/Barista shift/5am-4am hours/30 rating/3

(although under planned enhancements, a lot of key features that make the app usable are under planned enhancements, although they are ranked with high importance under the user stories)

[nus-pe-bot]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

We have discussed this under planned enhancements. The bug report also agrees that it is under planned enhancements.

"a lot of key features that make the app usable are under planned enhancements, although they are ranked with high importance under the user stories"

The tester's wording is not very clear. The key features that are of high importance under user stories have been implemented well already. Our planned enhancements covers areas of improvements for these key features, because we hope to make our existing key features stronger.

It is not the case that our key features have not been implemented and are left as planned enhancements.

---

We stated

Planned enhancement: We plan to implement a more structured approach to staff roles and shift timing by:
Defining a set of standard roles (e.g., "Barista", "Manager", "Cashier") through an enumeration
Implementing a proper shift timing format using Java's datetime, with clear start and end times
Adding validation to ensure meaningful values are entered
Potentially offering preset options like "Morning Shift (5am-1pm)" or "Evening Shift (2pm-10pm)"

This bug report takes issue at how we allow for "5am-4am", precisely because there is not validation for these fields.

--

At best this is a severity.Low issue, because we can still edit the field using staffedit to modify and polish incorrectly typed in fields. Due to the scope of all these field validations, we had deemed in OutOfScope during v1.6 and left it as a Planned Enhancement instead.

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: Thank you for the clarification!
I suppose that if the enhancement of the Shift feature will be added in future iterations, then it is okay, as basic functionality is still there as you mentioned.
However, the bug I reported is still valid as it highlights a key feature of the shift timing that is missing (ie ability to accurately input shift timings according to DateTime), and it is a valid feature that you mentioned will be implemented in future iterations. Hence, it should be categorised as response.NotInScope, as you have also mentioned in the quote below.

Due to the scope of all these field validations, we had deemed in OutOfScope during v1.6

---

❓ Issue severity

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

• I disagree

Reason for disagreement: [replace this with your explanation]

---