Recurring appointments are going to have to be redesigned in order to do this with any flexibility.
Overview
Current Approach
As of the creation of this issue, recurring appointments can only be created, not updated or destroyed. When a recurring appointment is POSTed, the server generates each appointment in the series, saves them in the database, and returns them in the POST response.
This approach works fine for creating appointments, but doesn't really work for edit/deleting the appointments with any flexibility. For example, if you want to delete this and future appointments, it's possible, but creates a lot more work than the server to do on a simple DELETE request.
New Approach
The new approach will implement a prototype appointment, which is saved in the database, and virtual appointments, which will be created only on the front-end based on the prototype appointment. Virtual appointments are not saved in the database.
When a recurring appointment is POSTed, the server will create and save only the prototype appointment to the database and return it in the response. The front-end will detect a recurring appointment in the response and generate the appropriate virtual appointments for display.
When the user requests to delete ALL instances, the front-end will send a DELETE request to the server, and the server will delete the prototype appointment.
When the user requests to delete FUTURE instances, the front-end will update the prototype meeting to end on the day before the selected instance and send a PUT request to the server, and the server will update the prototype instance and return it in the response.
When the user requests to delete SINGLE instance, the front-end will add the prototype to add that instance to the "exceptions" of the prototype and send a PUT request to the server, and the server will update the prototype instance and return it in the response.
TODO: Explain how UPDATE will work.
Front-End Tasks
Implement basic virtual appointments
[x] Create virtual appointments on the calendar
[ ] Delete virtual appointments from the calendar
[ ] ALL
[ ] FUTURE
[ ] SINGLE
[ ] Update
[ ] ALL
[ ] FUTURE
[ ] SINGLE
Server Tasks
[x] Remove old recurring data from schema
[x] Add new recurring data to schema
"isSeries" BOOLEAN DEFAULT false,
"seriesId" TEXT,
"seriesRule" TEXT,
"seriesExceptions" TEXT[],
"seriesProtoId" TEXT,
[x] Update createAppointment to no longer create all recurring appointments and only create the prototype one
Recurring appointments are going to have to be redesigned in order to do this with any flexibility.
Overview
Current Approach
As of the creation of this issue, recurring appointments can only be created, not updated or destroyed. When a recurring appointment is POSTed, the server generates each appointment in the series, saves them in the database, and returns them in the POST response.
This approach works fine for creating appointments, but doesn't really work for edit/deleting the appointments with any flexibility. For example, if you want to delete this and future appointments, it's possible, but creates a lot more work than the server to do on a simple DELETE request.
New Approach
The new approach will implement a prototype appointment, which is saved in the database, and virtual appointments, which will be created only on the front-end based on the prototype appointment. Virtual appointments are not saved in the database.
When a recurring appointment is POSTed, the server will create and save only the prototype appointment to the database and return it in the response. The front-end will detect a recurring appointment in the response and generate the appropriate virtual appointments for display.
When the user requests to delete ALL instances, the front-end will send a DELETE request to the server, and the server will delete the prototype appointment.
When the user requests to delete FUTURE instances, the front-end will update the prototype meeting to end on the day before the selected instance and send a PUT request to the server, and the server will update the prototype instance and return it in the response.
When the user requests to delete SINGLE instance, the front-end will add the prototype to add that instance to the "exceptions" of the prototype and send a PUT request to the server, and the server will update the prototype instance and return it in the response.
TODO: Explain how UPDATE will work.
Front-End Tasks
Server Tasks
References