Able to create module with nonsensical AY/sem

[immanuelhume]

Command: add n/foobar e/foo@bar.baz y/1 c/13 m/0001S1 cs1101s

Expected: reject the module (NUS wasn't even established)

Actual: the person is created with that module

In this case, there is a very clear lower bound - whenever NUS was established and/or started using the AY/sem system, thus it would be good to include it. However, it does not intefere with most app functionality, thus I gave it a Low severity.

[nus-se-script]

Team's Response

Thanks for raising this up! To be clear, AY2223S2 refers to AY 2022/2023 Sem 2, so in your case AY0001S1 would mean AY 2000/2001 Sem 1, and not AY with the year 0001. So our current module format is valid. See below screenshot (AY0001 exists). We did this to reduce the need for our users to type the first 2 digits of each year, to speed up the typing process. We also feel that our current module format is intuitive enough for NUS students to easily recognise, so there is no need to change it.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---