I am trying to create a system where an administrator creates an event using said application and the following endpoint
POST /users/{id | userPrincipalName}/events
which works fine. The issue comes when users are to be invited to said event which is being done through the following endpoint
POST /users/{id | userPrincipalName}/events/{id}/forward
The request itself works fine but the end result is far from what's intended. The result of the forwarding requests can be seen here and the view when expanding the attached file can be seen here. There is no way for the recipient of the forwarded event to accept the calendar event. Have I misinterpreted the endpoint specification found here https://learn.microsoft.com/en-us/graph/api/event-forward?view=graph-rest-1.0&tabs=http , and if so, what should I do instead? I've previously attempted updating the event using PATCH to the following endpoint
PATCH /users/{id | userPrincipalName}/events/{id}
But it forces you to fetch and/or cache the attendant property as it overwrites on PATCH. Any help is once more appreciated.
Related
recently I ran into a problem where I was using python imap to automate outlook tasks, but microsft changed basic auth to Oauth now, and I have not being able to authenticate ever since, I get an error
imaplib.error: AUTHENTICATE failed.
So I started working with the Microsoft graph API, in which I can get the information that I need but once I need to forward an email I can't setup a custom subject, I can just add a comment and toRecepient custom arguments.
https://learn.microsoft.com/en-us/graph/api/message-forward?view=graph-rest-1.0&tabs=http
any advice here ?
If you use the Create-Forward endpoint https://learn.microsoft.com/en-us/graph/api/message-createforward that will create a draft message of the forward which you can then patch any message property you want to update and then send.
The one thing they don't mention in the documentation is you should set the Prefer: outlook.timezone header to make sure the dates in you response are set the local time of the responder.
How can we "like" or add other reactions to someone else's channel message or comment via the Graph API?
I've not done this myself, but it certainly looks possible. You need to reply to the message, as per https://learn.microsoft.com/en-us/graph/api/channel-post-messagereply?view=graph-rest-1.0&tabs=http and notice that it has a "reactions" collection. That would be populated with a chatMessageReaction type, as per https://learn.microsoft.com/en-us/graph/api/resources/chatmessagereaction?view=graph-rest-beta
Note of warning: chatMessageReaction is a beta type though, so just be aware you need to call the beta endpoint, and it has a risk to use in production code as things might change.
Update: We reached out to MS Support and received the following info: "The API to reply to a message using a POST /replies request is solemnly for issuing a reply to a message, and not to edit the status of the parent message itself. Moreover, the "update chatMessage" API which is a PATCH /messages and which is the only API to edit a parent message only supports updating the policyViolation property of a chatMessage. Essentially, there is currently no documented API / already-present API examples on how to add a reaction, making this purely unsupported."
I'm building an Outlook Add-In and using the Outlook REST API 2.0. When updating a mail message to flag the message for follow-up, the update is accepted and in the Outlook Web client it briefly shows the start and due dates, but within a few seconds the start date goes away. When looking at the message through the API, the start date is completely removed, even though it was successfully added.
The API is PATCH Office.context.mailbox.restUrl + '/v2.0/me/messages/' + messageId ...
EDIT: I confirmed that this same behavior is exhibited in the Graph API as well.
As soon as the API is called, the UI on the message is updated:
Shortly after that (sometimes within a second, sometimes a little longer), the UI changes to:
And once the UI updates, if you query the API for the message and look at the Flag property, the StartDateTime object is completely gone.
Has anyone seen this or know why it might be happening?
Checked it on Graph with the following payload for PATCH-Message call and it seems to be working fine.
{"flag":{"dueDateTime":{"dateTime":"2020-08-20T00:00:00.0000000","timeZone":"Asia/Kolkata"},"flagStatus":"flagged","startDateTime":{"dateTime":"2020-08-14T00:00:00.0000000","timeZone":"Asia/Kolkata"}}}
I suspect that there is another application/outlook add-in that's removing this flag. Can you check once?
Here's my problem: I am using Microsoft Graph API v1.0 and would like to get the details of an instance of a recurring calendar event. All I got is the iCalUId of the instance.
I tried this call:
https://graph.microsoft.com/v1.0/me/events?$filter=iCalUId eq 'the value of the iCalUId'
This was also suggested in Microsoft graph API: finding event by iCalUid.
This works fine for single events.
But it does not work for instances of recurring meetings: then the call returns an empty value. I just verified this in the Graph Explorer https://developer.microsoft.com/en-us/graph/graph-explorer
Am I doing something wrong (even though the iCalUId is unique to the instance)? Is there a different call I could use?
This is happening because instances of recurring meetings don't actually exist on the server. When you use the /me/events endpoint, you are getting only single-instance and series masters events - it does not trigger the server to expand recurring events into individual instances.
To get server-side expansion, you have to use the /me/calendarview endpoint. This does require that you specify a date range though. For example, this works:
GET /me/calendarview?startDateTime=2020-01-31T00:00:00
&endDateTime=2020-02-29T00:00:00&
$filter=iCalUId eq '040000008200E00074C5B7101A82E00807E40204756DC3EEFFE5CC01000000000000000010000000FCE197631C1A2E4C89172A4115BEB7B5'
So I have implemented the Asana Webhooks API as described in their documents. I can pass it a project ID and request a new webhook be created. The API successfully sends a authentication request to my application which returns the Security header as described in the Docs. Asana then returns the expected success response, outlining the newly created Webhooks unique ID.
Now if i take this ID and then query the Asana API to show me all configured webhook's on either the parent Workspace or the project resource directly it returns an empty data JSON Object or reports the resource doesn't exist, suggesting the Webhook Ive just created wasn't actually created, despite giving me the expected success response.
Also If I then make a change to a project it doesn't fire the webhook and I don't receive any events on my application.
Strangely everything was working on Friday but today (Monday) I'm experiencing these issues.
Any pointers would be good, Ive been working as the Docs suggest in terms of my request structure and am authenticating using a PAT, Ive even tried a newly created token.
Thanks,
Our webhooks use the handshake mechanism to make sure that it's possible to call you back, but there's always the possibility that subsequent requests can fail. Additionally (although we don't document this very well - there's an opportunity for us) we should immediately try to deliver a (probably) empty event after the handshake (it looks like {"events":[]}. This is kind of like a "second callback" that contains anything that has changed since you created the webhook.
If this fails - or if any subsequent request fails often enough - the webhook will get trashed. "Failure" in this context means returns HTTP response codes other that 200 or 204.
As for why you're having trouble querying the webhook itself, I wasn't able to repro the issue, so we'd have to dive deeper. It should be fine if you:
Specify the workspace
Optionally specify the resource
I tested this out, and it seemed fine. You also might want to directly query the webhook by id with the /webhooks/:id endpoint - note to use the id of the webhook returned by create, and not the id in the resource field.
If you created the webhook (specifically, your PAT or OAuth app was the one making the create request) you should see the information just fine. If you can get the webhook by id, you should see last_failure_at and last_failure_content fields which would tell you why the webhook was unable to make the delivery.
Finally, if you would like to contact us at api-support#asana.com and let them know more details (for instance, the ID of the webhook you're trying to look at) we can look at those fields from our side to see if we can identify what's going on.