Cannot add multiple events

[NeoHW]

Reason for severity: In the real world, there can be many meetings with clients on different days to discuss the same project details. On large projects, there can be up to 100 meetings in a month. It does not make sense to only allow one such meeting which leads to not being able to use the scheduler

Steps to reproduce:

schedule add h/Meeting with Client t/4/15/2024 0930 d/Discuss project details n/John Doe

schedule add h/Meeting with Client t/2/30/2024 0930 d/Discuss project details n/John Doe

[soc-se-bot]

Team's Response

No details provided by team.

The 'Original' Bug

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

Schedule restrictive naming validation

Details

We are not allowed to add schedules of the same title, however, it is common for us to have multiple same appointments at a different time, for e.g I visit the dermatologist every 3 months, but I can only have 1 Visit Dermatologist schedule for tomorrow and not in 3 months time because they are the same event

Steps to Reproduce

1. schedule add h/Visit Dermatologist t/5/14/2024 0930 d/Discuss project details n/John Doe
2. schedule add h/Visit Dermatologist t/9/14/2024 0930 d/Discuss project details n/John Doe (Error here)

---

_{[original: nus-cs2103-AY2324S2/pe-interim#3668] [original labels: severity.Medium type.FeatureFlaw]}

Their Response to the 'Original' Bug

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

Since this app is catered to social workers we see that it might be rare for them to have the same appointment headings. Moreover, since they are aware that unique headings are required they can create simple workarounds like adding a number to their appointment, eg: meet alex1 and meet alex2, therefore this seems like not a huge issue, thus we recommend reducing the severity to Low.

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** The developer's response to reduce the severity of the issue to Low fails to address the significant impact of the limitation on users' ability to effectively utilize the scheduling functionality. While they argue that it might be rare for social workers to have the same appointment headings, this overlooks the reality of professional environments where multiple meetings or activities with the same event name are common occurrences. For instance, in the scenario of discussing project details with different stakeholders involved in the social help community, it's plausible to have multiple meetings (>100) with the same heading but different dates and times. > they can create simple workarounds like adding a number to their appointment, eg: meet alex1 and meet alex2, therefore this seems like not a huge issue, Furthermore, the suggestion to add numbers to appointment headings as a workaround introduces its own set of problems, such as potential confusion if there are multiple individuals with the same name or if the numbers represent different events or clients. This workaround adds unnecessary complexity and ambiguity to the scheduling process, detracting from the usability and user experience of the application. Additionally, the developer's reasoning that the issue is not a huge problem lacks sufficient justification. They fail to provide clear explanations or reasoning behind why the severity should be lowered, aside from seeming like not a significant issue to them. However, for users of the application, particularly social workers with high workloads, the inability to add multiple events with the same heading significantly hampers their productivity and efficiency in managing their schedules. The failure to provide adequate explanation and evidence did not help to explain anything. The issue that this is a flaw that affects most users and causes major problems for users still stands due to the high caseload (as stated in the UG) 

---