I'm using the Google Calendar API and nodejs. I have an app that allows patients to book appointments with doctors. But first, I check the doctor's calendar to make sure they do not have appointments at this time. How can I tell if an event is recurring? Does it show up multiple times when I make a list API call or only once?
Does it show up multiple times when I made a list API call or only once?
By default, it'll come up only once. You'll need to include the singleEvents parameter and set it to true for the reoccurring events that are reoccurring to show up in the API response (otherwise only the first time the reoccurring event was scheduled will be included).
calendar.events.list({ calendarId: theCalendarId, singleEvents: true })
When you have a recurrent event the ID changes a lot. For example, a regular event ID would look like 3qoortuglk75k7fjhgmd9k2enn, but the event ID from a recurrent event would be like 3qoortuglk75k7fjhgmd9k2enn_20220217T160000Z. If you see it has additional information related to the date and time. You could try to use something like that to recognize if the event is recurrent or not.
When listing events with the API you also have the request parameter singleEvents. You could use it to list only single events and compare them to the full list of events to see which ones are recurrent events.
Related
I'm looking for a way (using SuiteScript 2.0) to handle real-time persistent (stored) field updates, where a field might have changed in NetSuite (for example a lead time was just updated), and it doesn't matter if a user saved the change, or some other automated process changed that field. I just want to be able to pick up on that change:
The moment that it's done, and
Without regard for who or what kicked it off (e.g. it could be a person, but it could also be an automated change from a workflow, or a formula on the field itself which pulls values from another field)
Doing some research I found some options that looked somewhat promising at first. One being the afterSubmit event in a client script, and the other being the fieldChanged event. My issue however is, from what I understood those only really seem to be triggered by a user manually going in and making those changes, but this is only one part of the puzzle and doesn't seem to cover changes made outside of the scope of the user making those changes. Is that correct however? Or would one of those events still be able to capture changes done to that field regardless of who (or what) initiated or triggered the change, and right at the moment the change was saved/ persisted to the database?
UserEvents are basically triggers. In their deployment records you can set the context in which they fire so you can get them to fire in all circumstances (called contexts in Netsuite) but one.
That circumstance is User Events are not fired for record saves made in User Event scripts. i.e., if an AfterSubmit UserEvent script loads, changes and saves your record a fresh user event will not be fired.
I have a Flutter app that lets users rent items from eachother with Firestore RTDB. In my rental document, I have a field status that determines the status of the rental (think of it like shipping an item, where items can have status of 'ordered', 'shipped', 'delivered' etc). My status variable is a number between 0 and 5, and each number represents a different phase. When the status variable changes, I want to notify the other user in the rental with a push notification. But I don't know which of the following methods is best.
The first way is to use a cloud function that triggers every time the rental document is updated. But I only check for the status field. It would look something like this:
exports.notify = functions.firestore.document('rentals/{rentalId}')
.onUpdate(async (snapshot, context) => {
const oldSnap = snapshot.before.data(); // previous document
const newSnap = snapshot.after.data(); // current document
// status changes from 0 to 1
if (oldSnap.status === 0 && newSnap.status === 1) {
// do something
}
})
The one downside I can think of is I would have to do another read to get the device push token of the other user. Also, for every rental document update this cloud function will trigger, and ultimately may not even need to execute in the first place
The other way would be to have a notifications collection that stores notifications, and have a cloud function that triggers when a new notification document is added. Then, on the client side, when the user taps a button, update the status in the rental as well as create a new notification document.
Firestore.instance
.collection('rentals')
.document(rentalId)
.updateData({'status': newStatus});
Firestore.instance.collection('notifications').add({
'title': title,
'body': body,
'pushToken': <TOKEN HERE>,
});
In comparison to method 1, this does an extra write instead of a read.
Which method is better?
Both approaches can technically work and are valid. Which one you choose is depending on the use-case, and (given that both can work here) on personal preference. That's why I'll simply highlight a few key differences below, and explain when I personally choose to use which one.
The first approach you describe is treating your database like a state machine, where each state and state transition has specific meaning. You then use Cloud Functions to trigger code in the state transition.
The second approach treats the database as a queue, where the presence of data indicates what needs to happen. So Cloud Functions then triggers on the simple presence of the document.
I typically use a queue based approach for production work, since it makes it very easy to see how much work is left to be done. Anything in your notifications collection is a notification that needs to be sent.
In the state-transition data model it is much harder to see this information easily. In fact, you'll need to add extra fields to the document in order to be able to get this list of "pending notifications". For example: rentals with a pending notification are rentals where the timestamp that the status changed from 0 to 1 (a field you'll need to add, e.g. status_1_timestamp) is smaller than the timestamp the last notification was sent (a field like notification_timestamp).
But I sometimes use the state transition approach too. Usually when I want to transform the existing document, or because it's just a cool use-case to show (as in most cases the Firebase/Firestore SDKs would not expose both the old and new state).
I'd probably pick the queue based approach here, but as said before: that's a personal preference for me based on the reasoning above. If those reasons don't apply to you, or you have different reasons, that can be fine too.
I am working on a demo project where I need to fetch all events from the google calendar and show it in the home page.I am using gapi to fetch the events.
The properties for fetching has singleEvents as true and showDeleted as true.
I get all the events and instances of the recurring events as well.However the instances of a multiday event, for example an event that starts at Jan 1st and ends at Jan5th doesn't get replicated and I get only one event that has start date as Jan 1st. Could anyone suggest why the event instances of multi-day events are not being fetched?
That is how Google Calendar works. A single event has a start datetime and an end datetime. There is only one event even though it occurs over several days.
If you want to retrieve multiple events you will need to insert an event for each time frame you are looking for.
Google is not going to spawn events for you it will only return the data it has.
The documentation (https://msdn.microsoft.com/en-us/office/office365/howto/sync-calendar-view) for getting a calendarview implies that the SeriesMaster event will be returned in the result, along with the individual occurrences and exceptions.
The documentation states (and shows by example):
Here's the information you need to know about how recurring events are handled for calendar view synchronization.
The service performs meeting expansion and sends the series master event and all of the event instances within the time window.
The series master event contains the recurrence pattern and the time window for the series.
The event instances contain their start and end time information as well as information about event occurrence exception.
However in actually using this endpoint, we're only receiving back the Occurrences/Exceptions and not the recurrence "master". The Occurences are full models, unlike slimmer models containing only the start/end like the documentation states.
It's important for us to be able to get sync SeriesMaster events along with the exceptions for the series (as is possible with GCal singleEvents=false) such that we can store this information and perform recurrence expansion on the client-side.
What am I doing wrong here?
Request (decoded for readability):
GET https://outlook.office365.com/api/v1.0/Users(...)/calendarview?$sort=startDateTime desc&$top=100&startDateTime=2016-01-01T22:12:34+0000&endDateTime=2016-03-10T23:12:34+0000
There is a similar issue when we try to get the CalendarView in EWS.
The Outlook calendar sync REST API works well as the description for me. Did the API works for you when you remove the $top query parameters?
Because the Outlook calendar sync REST API doesn't support $filter, $count, $select, $skip, $top, and $search query parameters.
Here is the link for the sync API for your reference:
https://msdn.microsoft.com/office/office365/api/calendar-rest-operations#Syncevents
Here is the response from calendar sync for your reference:
I'm trying to create some sort of reservation system in SharePoint using a calendar list. It's been recommend to me to create events and add a column which allows a user to claim it. From there, claimed events would change color and only those who've claimed the event would have permission to unclaim the event.
This is what it would look like (see alternative option):
What I'd like to be able to do though, is instead of having to create three events like shown in the alternative option, creating 1 event (see original) and have that be broken down into 3 events or more, maybe using some form of drop down asking for intervals (ie. 15m, 30m, 1h). Based on the selected interval, it'd break the event accordingly.
A possible solution is in your main event you add another field named Interval.
The you design a workflow when you create the event that creates new events according to the interval specified using a while loop while incrementing the start time with your interval.
Those new events have a content type with a field named UserClaimed. you then associate another workflow to those new events that checks for that field and changes permissions on the event to only allow modifications of that event to the user specified.
This is the general idea, the implementation should not be that hard
just a thought -
I mean, the reason i think you want the events to pre-exist is so that users can easily create them in the correct time slot (rather than clicking the new item menu, which throws them away from the calendar view/context). Is that right?
If so, allow me to offer you this scenario:
If you are using KWizCom's Calendar Plus web part (yeah, I work for KWizCom...) it allows you to type in the event in the calendar itself directly.
Something simple like: "1pm-2:30pm Training meeting with Josh"
check the demo video here: http://www.kwizcom.com/sharepoint-add-ons/sharepoint-calendar-plus-web-part/overview/
Also, drag and drop events in the calendar to move them easily, and it also supports color coding events based on categories (meta data, views, sources, etc.).
The one thing you will need to develop is the unique meeting logic, and owner permissions.
meaning, an event handler that does not accept 2 meetings at the same time for the same room (define the unique resource field, if any), and the logic that allows only the person who created an event to edit or delete it.
ping me, I can help with the event handler - perhaps we can add this to our product, this is actually a cool idea. my work mail is shai at kwizcom dot com