I am using Microsoft Graph. When I use
GET /me/messages/{messageId}/attachments
If there is an attachment shared through OneDrive or SharePoint, the #odata.type will be #microsoft.graph.referenceAttachment. And the size is very small because it is not real file.
{
"#odata.type": "#microsoft.graph.referenceAttachment",
"id": "AAMkADBlZTUwNTkxLWVmODgtNDVhNC1iZjhlLTdjNjA1ODZlMDI5MgBGAAAAAACUbnk-iwQZRbXMgkfKtmYhBwCpTc-InBsuTYwTUBb_VIb4AAAAAAEMAACpTc-InBsuTYwTUBb_VIb4AAEBiQutAAABEgAQAMqgyfrokPFCrRfUa2mrxxM=",
"name": "word.docx",
"contentType": null,
"size": 4601,
"isInline": false
}
Is there any way to get the actual url of this attachment that can be opened in the browser? Thanks
The v1.0 edition has very limited support for referenceAttachment. And by that I mean, there isn't much you can do with them beyond acknowledging one exists.
The beta edition however supports a much richer referenceAttachment object. When I come across a referenceAttachment, I make the call to retrieve the attachment using the beta endpoint which does have links to the actual file:
{
"contentType": "string",
"id": "string (identifier)",
"isFolder": true,
"isInline": true,
"lastModifiedDateTime": "String (timestamp)",
"name": "string",
"permission": "string",
"previewUrl": "string",
"providerType": "string",
"size": 1024,
"sourceUrl": "string",
"thumbnailUrl": "string"
}
What you are after is sourceUrl property of referenceAttachment resource:
URL to get the attachment content. If this is a URL to a folder, then
for the folder to be displayed correctly in Outlook or Outlook on the
web, set isFolder to true. Required.
but this property is not available for v1.0 API version, beta endpoint needs to be utilized instead:
https://graph.microsoft.com/beta/me/messages/{message-id}/attachments/{arrachement-id}
Related
I have created a series of Power Automate Flows that connect with Microsoft Forms; many of them have multiple attachment requirements. When the form is submitted, the files are successfully parsed into the correct folders in the form's Sharepoint directory/directories, and the files work properly there. On the Power Automate side, however, only the first attachment goes through successfully; the others throw error messages like this:
Adobe Acrobat Failure alert: Acrobat could not open file because it is either not a supported file type or because the file has been damaged
As the form is organizational, I'm grabbing the user profile to populate some of the areas.
The schema for the JSON parse is:
{
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"link": {
"type": "string"
},
"id": {
"type": "string"
},
"type": {},
"size": {
"type": "integer"
},
"referenceId": {
"type": "string"
},
"driveId": {
"type": "string"
},
"status": {
"type": "integer"
},
"uploadSessionUrl": {}
},
"required": []
}
}
Here's the full automation with sensitive information redacted:
Power Automate Flow 1
Power Automate Flow 2
It would be much appreciated if someone could clarify why this is happening and how to correct it. We have people who work with the emails to process the paperwork and do/should not have access to Sharepoint, so other staff are supply the files by downloading them from their site.
I would very much like to mention a tag when creating a teams message. I read the tag ID from Microsoft graph (I've also tried fetching tag id from an incoming message).
I can do this as my self using Microsoft Graph api with the following payload
{
"body": {
"contentType": "html",
"content": "<div>New incident ##### assigned to <at id=\"0\">App operations</at></div>"
},
"mentions": [
{
"id": 0,
"mentionText": "Operations",
"mentioned": {
"application": null,
"device": null,
"user": null,
"conversation": null,
"tag": {
"id": "my tag Id which I got using graph lookup",
"displayName": "App operations"
}
}
}
]}
Is this at all possible using the bot framework? Can the payload be manipulated to do this?
Right now, it is not supported to mention a tag using bot. The possible workaround is to use Graph API in the bot. To do that you can refer to this sample. Follow this to Add authentication to a bot. You will need to add the required permission and call the required API in sample.
I have a Google Doc that I am testing the Comments API with. I've created, then deleted or resolved many comments. It currently shows no comments in the UI. However, when I search Comments.Get API on a specific Comment ID for the file, I am returned one that is both unresolved and not deleted. See API response below:
{
"kind": "drive#comment",
"commentId": "commentID",
"createdDate": "2020-10-21T12:29:27.941Z",
"modifiedDate": "2020-10-21T12:29:27.941Z",
"author": {
"kind": "drive#user",
"displayName": "My Name",
"picture": {
"url": "My Picture"
},
"isAuthenticatedUser": true
},
"htmlContent": "Comment",
"content": "Comment",
"deleted": false,
"status": "open",
"context": {
"type": "text/html",
"value": "some text in my file"
},
"anchor": "kix.bj5cxfssg70z",
"fileId": "FileID",
"fileTitle": "My File",
"replies": []
}
Does anyone know why this might be happening. It's not a propagation issue (I hope) because I made all these changes to doc over an hour ago and still this is what I receive
This can happen if you create a comment via API, especially if you do it for a file that does not support programmatic anchoring
So the comment is somewhere, you can see that it was created if you browse the Drive Activity (both prgramamtically and form the UI), but you cannot see the comment itself because it was wrongly anchored somewhere outside of the visible range of the document.
I assume it is related to this bug. Comment on it to see if it gets reopened, or "star" the feature request to increase visibility.
I'm setting up a workflow that takes in a text variable I'd like to use in a later link.
For example, I ask for "Api Name", and then want to send a message that both references the api name as well as constructs a url (e.g. http://swagger.io/docs/"Api Name")
The problem I encounter is the links come up in plaintext if I just try to include that url as plaintext example as above. If I use the editor to try and add a link, the variable is not available.
My next thought was to try and edit the workflow json to supply some markdown in there, but it looks like the richtext is constructed from a series of elements.
A link looks like this:
{
"type": "link",
"url": "https://swagger.io/collections/",
"text": "(Link)"
},
And a token looks like this:
{
"type": "workflowtoken",
"id": "<some uuid>==user",
"property": "",
"data_type": "user",
"style": null
},
If I merely make the link plaintext and try to append the variable after the prefix I get something like this:
{
"type": "text",
"text": "https://swagger.io/thing/",
"style": {
"unlink": true
}
},
{
"type": "workflowtoken",
"id": "<uuid>==text",
"property": "",
"data_type": "text",
"style": null
},
So maybe if we knew all the values "type" could be that would help?
Not sure where to go from here. Anyone have any suggestions?
Here is an answer from Slack Support Service:
We don't yet support Workflow variables outputted in links, I'm
afraid.
This is feedback we hear quite a bit so hopefully it's the something
the team will consider implementing in the future.
{
"location": {
"lat": -33.8669710,
"lng": 151.1958750
},
"accuracy": 50,
"name": "Google Shoes!",
"phone_number": "(02) 9374 4000",
"address": "48 Pirrama Road, Pyrmont, NSW 2009, Australia",
"types": ["shoe_store"],
"website": "http://www.google.com.au/",
"language": "en-AU"
}
This one I tried and as well as other places without modifying the request structure with Indian places. I'm getting the following response:
{
"html_attributions": [],
"results": [],
"status": "INVALID_REQUEST"
}
I'm not getting exactly what is the Issue, please revert back for the solution.
Since you didn't specify, I'm assuming that you are trying to use the add places endpoint on the Places API described here in the documentation.
The most likely problem is that you neglected to include your API key in the request URL, which should look like this:
https://maps.googleapis.com/maps/api/place/add/json?key=YOUR_API_KEY
Note that this endpoint is deprecated and that Google may remove it altogether at some point in the future.