ABE General Overview of Events
For information on endpoints visit Events API.
The frontend makes a GET request to ABE's EventAPI. If no event_id or rec_id is given, ABE returns all events in the date range specified by the frontend. If an event_id or rec_id is given, the frontend is requesting information about a single event. Depending on what is given, a regular event, "dummy" recurring event, or sub_event is returned.
* For more information on sub_events and "dummy" events go to recurring events
To create an event and add it to ABE, a POST request is made. To make a repeating event, the 'recurrence' field should be filled with the appropriate fields.
To edit an event, a PUT request is made. If the event_id points to a sub_event, then the sub_event will be edited directly. If it points to a parent/regular event, an extra check is implemented to see if the edit being made is to add a sub_event. If that is the case, a sub_event is added to the parent event, if not, the regular event is updated.
To delete an event, a DELETE request is made. If the event_id points to a sub_event, then the "deleted" field in the sub_event is turned to True. This ensures that ABE will skip over the sub_event when answering GET requests. If the event_id points to a regular event, then the event is simply deleted from ABE's database. If the request is for a "dummy" object to be deleted, a sub_event is created with the "deleted" field equal to True.
ABE define events that repeat with the RecurringEventDefinition document. The first event in the series has this document embedded in it. MongoDB stores this first event with the definition. When sending information to the frontend, ABE expands this first event with the definition into every occurrence of the recurrence. These "dummy" events are not saved in mongoDB, simply generated based on the definition stored in the database and created everytime the frontend requests events.
If a "dummy" event is edited on the frontend, the frontend sends ABE a PUT request to change the parent event definition. The fields that were changed on the frontend are saved in a RecurringEventExc document or sub event document. The next time the frontend requests an event, these sub events will replace the ocurrence it was originally edited from.
