How to get the full list of deleted and/or modified instances of recurring meeting using Google Calendar API v3?
You can check the showDeleted and singleEvents properties of Events.list.
showDeleted includes deleted events in the result of Events.list.
showDeleted - boolean
Whether to include deleted events (with status equals "cancelled") in
the result. Cancelled instances of recurring events (but not the
underlying recurring event) will still be included if showDeleted and
singleEvents are both False. If showDeleted and singleEvents are both
True, only single instances of deleted events (but not the underlying
recurring events) are returned. Optional. The default is False.
singleEvents determines if the events to show are recurring or not.
singleEvents - boolean
Whether to expand recurring events into instances and only return
single one-off events and instances of recurring events, but not the
underlying recurring events themselves. Optional. The default is
False.
You can try it here.
Related
In our organizational G Suite service, we defined rooms in "Building and Resources".
We schedule meetings in these rooms through Google Calendar.
Is it possible to get an organized report, that shows room usage per user? We would like to know which user used which room and for how many hours per time unit (month). Is there a way to get this information? An organized report? Any form of raw data?
We could only find general high-level data about the usage of each room, but no specific user data.
Issue:
There's no built-in method to retrieve this information.
If you think this feature could be useful, I'd suggest you to file a feature request on this Issue Tracker component.
Workaround:
Even though there's currently no direct method to retrieve an organized report for this, you could retrieve the information about how much a resource is being used by the different users, using Calendar API.
You could do the following:
A Calendar is created for each resource. This Calendar contains all events in which the resource is present (a resource can be added as an attendee for the event, or the event can be directly created on the resource calendar; either way, all events will be present in the resource calendar). Find the corresponding calendar ID by clicking Settings and sharing for the calendar, and scrolling to the section Integrate calendar.
Call Events: list, setting the calendarId property to the ID you retrieved in previous step. This will return all events in which this resource has been used. You could also retrieve the events between a specific time interval, by specifying the properties timeMin and timeMax.
Each event in this retrieved list will have information about: (1) the event attendees, including its organizer (check the attendees property on the Events resource), and (2) the event start and end time (check the properties start and end). With this information, you can know which users used each resource and for how much time. You'd just need to filter the events according to the attendees, and calculate the event durations using the start and end dates.
Repeat steps 1 to 3 for each resource.
Update:
Feature request reported on Issue Tracker:
Report resources usage information per user
I am using the Outlook Calendar REST API to retrieve calendar events.
When I call the url https://outlook.office365.com/api/v2.0/users/#{email}/calendarview?endDateTime=2016-09-01T10:00&startDateTime=2016-08-10T10:00
I get only the single event instances returned. How can I include the occurrences of repeating events too?
The calendar view REST gets the occurrences, exceptions, and single instances of events in a calendar view defined by a time range. It works well for me. Please check whether the time range is correct to filter the view.
In addition, you can check the type of event type in the response. It should be Occurrence in this scenario.
Update: test with Microsoft Account
When fetching a list of Google Calendar Events (v3) using a syncToken, most properties of the returned event are empty when its status is 'cancelled'.
For my synchronisation programme, I need to be able to get my unique key from the ExtendedProperties collection. This property seems to be missing from the Event. I could, of course, use the ICalUID to match both records, but that means rewriting the whole thing.
Is there a way to get all the properties the Event once had when its status is now Cancelled?
You should get all the properties by setting showDeleted=true on the list request.
Using the Google Calendar API, and for a weekly recurring event on every Friday that never ends, I have cancelled one of the instances and modified the starting time for another instance several weeks later. On fetching this event from the calendar, it does not contain any EXDATE as specified on http://www.ietf.org/rfc/rfc2445, referenced by https://developers.google.com/google-apps/calendar/concepts
Why not? How does Google handle the modification of instances within a recurring rule? In fact, I only ever see RRULE in the recurrence field of the response. When do the other types of recurrence types appear such as EXDATE, EXRULE, RDATE, etc..?
You will get an instance of a recurring event with status=CANCELLED instead of an EXDATE if you cancel the instance through the Calendar API. EXDATEs however are an alternative that results in the same effect of the event being deleted.
EXRULEs are now deprecated as per RFC 5545 (https://www.rfc-editor.org/rfc/rfc5545), RDATEs should work.
I have a question regarding the dequeue mechanism during discrete event simulation.
Most of the implementations use some kind of priority queue which can be used to quickly retrieve the event with the earliest timestamp. What happens when such an event cannot be scheduled because, say, it needs a resource to be able to run.
There may be another event in the queue whose timestamp is greater than the timestamp of the event that is blocked on a resource.
For example, let us assume we are modelling a grocery-store with separate checkout lines and a cashier per line. A shopper entering a checkout line is an event. We enqueue this event based on the time the shopper entered the checkout line. However, the order in which our simulation should execute two such events in not necessarily the time order in which they entered the checkout line because the cashiers might free up in a different order.
In such a scenario how does using a priority queue solely based on timestamp --- and independent of resource availability --- work out?
You need a queue for each cashier, or at least a count of waiting customers if customer identity is not important in your simulation ( e.g. I would join a queue of three people with one item each over a queue with one person with a full trolley, so just a queue length may not capture the information needed to incorporate that heuristic ).
When a customer joins the queue, the number of queuing customers is incremented or the customer is pushed onto the cashier's queue.
When the cashier is ready to serve, the first customer is popped of the cashier's queue. So the customer service event is dependent not on the time the customer arrives, but when the cashier is ready.
These queues or counters are independent of the scheduling mechanism for events - the events scheduled manipulate these queues, they aren't dependent on them for scheduling.
As Pete Kirkham pointed out, it's important to be aware that the lines (queues) that customers wait in are completely separate things from the priority queue that's used to determine event ordering.
In discrete-event simulation an event is a point in time at which the system state changes. When an event occurs you figure out what to do next based on the state. Joining the line of customers is an event, but so is becoming eligible for service. Once a customer becomes eligible for service, the logic of that event has to check whether service is possible or not. If so, schedule a new event for when the service will end. If there are resource constraints, then nothing gets scheduled and that customer is on hold. However, at some point in the future the required resource will become available. That's an event too, and that event's logic should check to see if there are customers on hold due to lack of the resource. If not, there's no need to schedule anything, but if so, you can now schedule the actual service for the customer. You can see that customer delays in the queue will increase with resource constraints.
For a much fuller explanation of how discrete-event simulations work, please look at this introductory tutorial paper.