What I'm doing is creating a calendar event in M365 via the EWS API. I want to set isOnlineMeeting and onlineMeetingProvider, but those properties are not writable in EWS. So my idea was to take the itemId of the new event, and use Microsoft Graph to update just those two properties. I had to alter the itemId a bit to get Graph to accept it (changed / to -) but it appears to "work" in the sense that the PATCH command comes back with response 200. But the properties do not get modified. Here is the json that I give to the PATCH command:
{
"isOnlineMeeting": true,
"onlineMeetingProvider": "teamsForBusiness"
}
Here is the URL (shortened for brevity):
PATCH /v1.0/users/me/calendars/AQMkAG.../events/AAMkAG...
As I said, the http response code is 200. The output from the PATCH is a listing of all of the event properties. The ones I am trying to modify are unchanged. The funny thing is, I could have sworn I had this working last week, but my tests this week all fail. Any ideas?
Related
Current using Microsoft Graph API v1.0 to create onlineMeetings via POST /me/events. Reason being, if you create an onlineMeeting directly and add a user in the meeting, it doesn't create a calendar event.
The params I use for that call is:
:isOnlineMeeting => true,
:onlineMeetingProvider => "teamsForBusiness"
Which works great and returns a joinUrl under onlineMeetings.
However, I'd like to pull attendance data from the GET onlineMeeting route to get attendance information since the attendees section of the event only seems to return users that were added to the actual event, not who attended the actual onlineMeeting.
I have tried doing a get request like such:
/v1.0/me/onlineMeetings?$filter=joinWebUrl%20eq%20'https://whateverthejoinurlis'
but the response says it's not a valid filter.
Any guidance would be appreciated.
Posting the Answer for better knowledge
Copying from #Shiva Keshav Varma comments
Try it in beta version
/beta/me/onlineMeetings?$filter=joinWebUrl%20eq%20'https://whateverthejoinurlis
You can also get the attendeereport using beta/users/{userId}/onlineMeetings/{meetingId}/attendeeReport as specified in the document.
I'm syncing calendar events using the #microsoft/microsoft-graph-client npm package with the base url /me/calendarview/delta. It's been working fine until a few days ago. For some reason whenever I create a new calendar event in outlook.office.com and my app syncs, the newly created calendar event has the #removed: {reason: "deleted"} field set.
However when I lookup that same calendar event using the Microsoft Graph Explorer that same event does NOT have the #removed field set. Is there any reason a newly created calendar event would look like it's being deleted during a sync?
I'm using #microsoft/microsoft-graph-client v1.3.0
Steps to recreate:
Create an event using the node graph client by POSTing to /me/calendar/events
Grab a delta of calendar events using /me/calendarview/delta with appropriate deltaLink and access token.
I receive 1 calendar event that has 3 fields, #odata.type, id and #removed. The id field matches the id of the created event in step 1.
If you need more information, let me know. This is affecting some of our users.
Update: I tried a workaround for this issue by calling /me/events/<id> for each #removed calendar entry I receive on a delta sync to verify if the event was truly deleted. However when I call that API via the microsoft-graph-client it returns null. If I make the same GET call via MSFT Graph Explorer then the event is returned.
I left an answer on another question here: https://stackoverflow.com/a/65348721/6806302
In short, I went off yesterday on a hunch inspired by #mattlaabs's comment on the question above, that the startDateTime..endDateTime range of the events delta was to blame.
And in practice, that is exactly the problem. The answer is two part:
Changes to events not in the window always show up in the delta stream as #removed.
The events delta parameters are captured in a "closure", meaning subsequent requests (with a $deltatoken) ignore the startDateTime..endDateTime query parameter.
Understanding both of the above, it seems that the answer is to:
Create wide enough initial startDateTime..endDateTime windows to suite your application's needs
Start new events delta streams (by not providing a $deltatoken) at some defined interval instead of reusing the same one indefinitely
I'm currently using the Microsoft Graph API to sync calendar events to my local application. It seems to be working fine, except I don't seem to be able to retrieve deleted events. I'm following the instructions for the delta query as laid out by Microsoft here. Those instructions specifically say "By using delta query, you can get new, updated, or deleted events in a calendar view," and in the examples there is an event in the sample response that is deleted.
In my testing, however, I am never able to receive any deleted events. I create an event and call /me/calendarView/delta?startDateTime={start_datetime}&endDateTime={end_datetime} and I can see the event. Then I delete the event, make the same call, and the response is empty. I've tried using the deltaToken call, just to be sure I'm getting the events that have changed since my last call, and it does return the deleted event as expected. But I would prefer not to use that, as it requires that my start/end dates always be the same.
Am I just completely missing the point of the delta call, or am I doing something wrong in calling it?
I am using the services as shown here
https://learn.microsoft.com/en-us/graph/delta-query-events
GET /me/calendarView/delta?startDateTime={start_datetime}&endDateTime={end_datetime}
And I am not getting the deleted events when running it using the delta token as shown in the example
https://learn.microsoft.com/en-us/graph/delta-query-events#the-next-round-sample-first-request
...
{
"#odata.type": "#microsoft.graph.event",
"id": "AAMkADk0MGFkODE3LWE4MmYtNDRhOS04OGQLkRkXbBznTvAADb6ytyAAA=",
"#removed": {
"reason": "deleted"
}
},
...
I always get an empty delta response
eg
https://graph.microsoft.com/v1.0/me/calendarView/delta?$deltatoken=R0usmcdvmMuZCBYV0hguCFHvWbSXF
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(event)",
"#odata.deltaLink": "https://graph.microsoft.com/v1.0/me/calendarView/delta?$deltatoken=R0usmcdvmMuZCBYV0hguCFHvWbSXF-PYk6UEH7m4ZdZmSbEIlouKElB10k31BdGZZJ1Os2i",
"value": []
}
You can only obtain deleted items using /delta queries. When calling /calendarView it will give you only the current calendar, not previous iterations of that calendar.
when we create projects via API the newly created project is immediately returned in both the webApp and in the API.
But a tag created using API "https://app.asana.com/api/1.0/tags" is often returned only after two or three GET requests. Also in the webApp it needs a refresh, online application sync does not update new tags like Projects.
This late returns really affects the user interaction. I follow the same workflow thats used for creating and adding project, but tags feels a bit laggy. Am I missing anything?
The answer is that tags which aren't associated with any tasks are - unfortunately - hidden in the app, and consequently also in the API. As you discovered, you can get the ID back from the POST to create and then associate it with a task from there (since there's little purpose in creating a tag if you're not associating it with something that shouldn't typically be a problem, but it is clunky). We are looking at changing our data model for tags to be a bit more intuitive in future, but that's still a ways off, so this is the reality for the foreseeable future.
the newly created tag is missed in the GET /tags API from time to time. But the http response returned after creation of the new tag by POST /tags, will contain the id, name and other properties of the newly created tag. So we can add the new tag from this response.
POST-> https://app.asana.com/api/1.0/tags \
-u "name=fluffy" \
-u "workspace=14916"
# Response
HTTP/1.1 201
{
"data": {
"id": 1771,
"name": "fluffy",
...
}
}
Is it possible to update the worklog for an issue when transitioning (i.e. POST to /rest/api/latest/issue/{issueid}/transitions) via the REST API for JIRA (API version is 2.0.alpha1 of JIRA v4.4.1)? I'm posting a worklog as part of the request and looking for the minimum information I need to send (currently just minutesSpent and started time as these seem to be the only mandatory ones via the UI).
i.e.
worklog:
{
name: "worklog",
type: "worklog",
value: [
{
started: "2012-10-01T10:28:00.000+1000",
minutesSpent: 480
}
]
},
Currently the post to the URL seems to just ignore this additional data although the transition does take effect with a desired 204 response.
From the JIRA REST API Docs:
The fields that can be set on transtion, in either the fields parameter or the update parameter can be determined using the /rest/api/2/issue/{issueIdOrKey}/transitions?expand=transitions.fields resource. If a field is not configured to appear on the transition screen, then it will not be in the transition metadata, and a field validation error will occur if it is submitted.
If, in the response you get from the expansion, you don't see worklog, then I don't think it is possible.