1.This is the behavior I am observing when I use Update DriveItem graph API to update my file name.https://learn.microsoft.com/en-us/graph/api/driveitem-update?view=graph-rest-1.0&tabs=http.
2.If the file is open in my office desktop document it throws locked exception. If i close the file renaming works fine.
3.I tested same in sharepoint their UI ,I am able to rename the file.But through graph API it throws locked exception if file is open.
Is this error expected ?. How can I get around this
https://learn.microsoft.com/en-us/graph/api/driveitem-update?view=graph-rest-1.0&tabs=http.
PATCH https://graph.microsoft.com/v1.0/drives/b!qnfox2pppU-AeWEPhWpRhNiB9gIq_ANJq5NFCiklU2Y5F3fDc7fsaQvB/items/014UHAXWYO5LX2RTA6YZE37E4XTG45PTTW
SdkVersion : graph-java/v1.6.0
Authorization : Bearer
{"name":"V-blah (1) (113_0_4_26).docx"}
423 : Locked
Strict-Transport-Security : max-age=31536000
Cache-Control : private
x-ms-ags-diagnostic : {"ServerInfo":{"DataCenter":"West US","Slice":"SliceC","Ring":"5","ScaleUnit":"000","RoleInstance":"AGSFE_IN_57"}}
client-request-id : 33f16bde-55d1-XXXX
request-id : XXXXXXX
Content-Length : 251
Date : Sat, 02 May 2020 04:05:23 GMT
Content-Type : application/json
{
"error": {
"code": "resourceLocked",
"message": "The resource you are attempting to access is locked",
"innerError": {
"request-id": "d1bfa1f2-cXXXXX",
"date": "2020-05-02T04:05:23"
}
}
}
Ensure that the document library does not have "check-in required" enabled.
Assuming check-in is not required, I received the same HTTP 423 "resourceLocked" response for both scenarios: file opened in the browser (SharePoint Online UI) and file opened in desktop client. I believe this is working by design that you can't update a file's name when it is currently opened by another user or yourself in another instance.
Please see this reference about files locked for editing.
Try adding the HeaderOption that bypasses the shared lock, to the request.
new Microsoft.Graph.HeaderOption("Prefer", "bypass-shared-lock")
If you are using the graphServiceClient, add it to a List and pass it directly in your Request.
I was able to get the mail object with attachment using following API Call
https://graph.microsoft.com/v1.0/me/messages/${messageId}?$expand=attachments
I need to save raw MIME for the mail (i.e. .eml) which will be uploaded to our internal CRM.
I understand that one can make a simple .eml file in below fashion but I want to know if there is a simpler alternative to get this from the API directly.
To: Demo-Recipient <demo#demo.example.com>
Subject: EML with attachments
X-Unsent: 0
Content-Type: multipart/mixed; boundary=--boundary_text_string
----boundary_text_string
Content-Type: text/html; charset=UTF-8
<html>
<body>
<p>Example</p>
</body>
</html>
----boundary_text_string
Content-Type: application/octet-stream; name=demo.txt
Content-Transfer-Encoding: base64
Content-Disposition: attachment
ZXhhbXBsZQ==
----boundary_text_string
Content-Type: application/octet-stream; name=demo.log
Content-Transfer-Encoding: base64
Content-Disposition: attachment
ZXhhbXBsZQ==
----boundary_text_string--
There are two ways one can get a message in raw format (MIME), and both are now available in v1.0 of the Microsoft Graph API:
Append a $value to a get message operation.
If a message is attached as a file or item to another Outlook item (message or event) or group post, you can get that message attachment by appending $value to the get attachment operation.
Get MIME content of a message describes the two scenarios.
In general, keeping an eye on the Microsoft Graph blog site, the what's new topic, or the changelog topic (if it's API or permissions updates) would help you discover additions and updates you were looking for. In particular, the ability to get the MIME format of a message or message type attachment was introduced in April 2019 in the beta version, and promoted to v1.0 in September a few months later.
I'm trying to download a file from SharePoint Online using an "app only" token. I can obtain file info using this url
https://graph.microsoft.com:443/v1.0/sites/{siteId}/drives/{driveId}/list/items/{itemId}/driveItem
But when I try to download the file with this url
https://graph.microsoft.com:443/v1.0/sites/{siteId}/drives/{driveId}/list/items/{itemId}/driveItem/content
I get the following error
403 FORBIDDEN
Content-Length →13
Content-Type →text/plain; charset=utf-8
Date →Fri, 13 Apr 2018 08:47:12 GMT
MicrosoftSharePointTeamServices →16.0.0.7604
P3P →CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
SPIisLatency →2
SPRequestDuration →53
X-Content-Type-Options →nosniff
X-MS-InvokeApp →1; RequireReadOnly
X-MSDAVEXT_Error →917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.
X-MSEdge-Ref →Ref A: B9E0C567B0CC4E60AEE93EEB8DC06AF1 Ref B: VIEEDGE0813 Ref C: 2018-04-13T08:47:12Z
X-Powered-By →ASP.NET
X-SharePointHealthScore →0
what is wrong?
it seems that internally it generates a download link (.../_layouts/15/download.aspx?UniqueId=...) that works with username / pwd token, but does not work with "app only" token
I have another office 365 subscription that works with "app only" token. The other subscription have a custom domain, but I can not see other configuration differences (both have LegacyAuthProtocolsEnabled property set to true, same sharing options...)
EDIT: It seems that the example I was testing on friday now works!!
This bug appeared wednesday last week, and is spreading to more and more of our tenants. It appears that temporary tokens generated by the Graph API/Sharepoint API are invalid. This affects:
Chunked file upload, as you receice an url to upload to with a temporary token
#microsoft.graph.downloadUrl as it contains a temporary token
Content download, as it uses the excact same url as #microsoft.graph.downloadUrl
Please fix this ASAP, as my application is cripled and the customers are angry
I created a post here too, but no response: Temporary tokens issued by graph api is invalid since wednesday
Also this bug appeared wednesday: Unable to set fileSystemInfo.lastModifiedDateTime on files on Sharepoint Online for some users since wednesday
Did you find anything on this Mark LeFleur?
You should use the #microsoft.graph.downloadUrl property obtained from the /v1.0/me/drive/list/items/x/driveItem response to get an app-only url to the file.
A GET request wil allow you to download the file.
See https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/driveitem#instance-attributes
I have executed the same example that initially failed and now works, at least in the two tenants that I have.
I have not changed any configuration or source code, so it seems that it was a temporary problem that has been fixed.
I'm using DocuSign's API in an iOS application to sign documents. Everything is going fine, except for the Carbon Copy experience.
I have two signers, with routing orders 1 and 2. Then, I have several CC recipients, all with routing order 3.
When the document is signed, the CC recipients receive an email alerting them that the document was signed, but they don't receive the note they should be getting. I know I'm setting this property well: when the CC recipients have a routing order of 1 or 2, they receive an email with the note, and then they receive an email when the document is signed.
How can I get my CC recipients to receive their email at the right point in time, with the note I want them to see?
Here's the log from DocuSign:
POST https://na2.docusign.net:8822/restapi/v2/accounts/6580857/envelopes
Content-Length: 284777
Content-Type: application/json
Connection: keep-alive
Accept: application/json
Accept-Language: en-US; q=1.0
Host: na2.docusign.net
User-Agent: Sales/1.0(iPhone; iOS 9.3.2; Scale/2.00)
X-DocuSign-Authentication: {"Username":"[email1]","Password":"[omitted]","IntegratorKey":"[omitted]"}
X-DocuSign-SDK: Obj-C
X-Forwarded-For: 69.74.21.33
X-SecurityProtocol-Version: TLSv1.2
X-SecurityProtocol-CipherSuite: ECDHE-RSA-AES256-GCM-SHA384
{"status":"sent","documents":[{"documentId":"1","documentBase64":"[omitted]","name":"Test Name"}],"emailSubject":"Subject","emailBlurb":"","recipients":{"signers":[{"email":"[email1]","routingOrder":"1","clientUserId":"1001","tabs":"[omitted]", recipientId":"1","name":"John Doe"},{"note":"This is a note that appears during the signing experience","tabs":"[omitted]","email":"[email2]","clientUserId":"1002","routingOrder":"2","recipientId":"2","name":"Jane Doe"}],"carbonCopies":[{"roleName":"Carbon Copy","routingOrder":"3","email":"[email3]","recipientId":"3","note":"This note does not appear in the email sent to the address.","name":"John Smith"}]}}
201 Created
Content-Type: application/json; charset=utf-8
{
"envelopeId": "f3421750-6884-4f84-a318-d4637151222c",
"uri": "/envelopes/f3421750-6884-4f84-a318-d4637151222c",
"statusDateTime": "2016-07-12T12:51:24.4870000Z",
"status": "sent"
}
I notice that I'm leaving the email blurb section empty. Could this be a potential solution, or does that field's content get displayed to all parties involved in the signing? In practice, I need to be able to have several different notes for several CC recipients. As far as I know, this can be achieved on DocuSign's website, so I don't see why it couldn't be done through the API.
In fact, it seems my problem was caused by a misunderstanding of DocuSign's API. The note field is designed to provide a note that only appears during the signing experience, while the "emailNotification":{"emailSubject":"TEST","emailBody":"TEST"} field is designed to do what I was trying to achieve.
So, I have a ruby on rails project, I'm using the google-api gem and I'm trying to download a file from an account that I previously gave permission to my project to access and manage my google drive files. I have the refresh token and the access token and for some time, the download works fine. For some reason, after the access_token expires, even after I request a new one from the API using the refresh (which does work), the download request returns a 403 error with no information whatsoever about what 403 error it is.
First: why, after refreshing the access_token, am I still getting the 403 error?
Second: why is the response not returning any information about the error?
Fyi, if I go to my account, de-authorize the app and then authorize it again through my app, the download works fine again.
I really need help, since this kinda breaks my whole project if it doesn't work.
Edit: Tried again to see if the problem was still happening. I deleted my account yesterday, gave permission again to manage files and it worked until the access_token expired. After that it gives the 403 error message, even after using the refresh token to update the access one. Below is what I get from client.execute (with the client key and secret edited):
Response from Google API: #"16653014193614665626", "e"=>"download", "gd"=>"true"}, #headers={"User-Agent"=>"google-api-ruby-client/0.7.1 Linux/3.13.0-24-generic\n (gzip)", "Accept-Encoding"=>"gzip", "Content-Type"=>""}, #api_method=nil, #authenticated=nil, #authorization=#https://accounts.google.com/o/oauth2/auth>, #token_credential_uri=#https://accounts.google.com/o/oauth2/token>, #expiry=60, #extension_parameters={}, #additional_parameters={}, #client_id="***.apps.googleusercontent.com", #client_secret="***", #scope=["https://www.googleapis.com/auth/drive", "https://www.googleapis.com/auth/userinfo.email"], #access_token="***", #refresh_token="***">, #body="", #http_method=:get, #uri=#>, #response=# #request=# #request_headers={"User-Agent"=>"google-api-ruby-client/0.7.1 Linux/3.13.0-24-generic\n (gzip)", "Accept-Encoding"=>"gzip", "Content-Type"=>"", "Authorization"=>"Bearer *", "Cache-Control"=>"no-store"} #ssl=# #response_headers={"access-control-allow-origin"=>"*", "access-control-allow-credentials"=>"false", "access-control-allow-headers"=>"Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, GData-Version, Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, Range, Slug, Transfer-Encoding, X-ClientDetails, X-GData-Client, X-GData-Key, X-Goog-AuthUser, X-Goog-PageId, X-Goog-Encode-Response-If-Executable, X-Goog-Correlation-Id, X-Goog-Request-Info, X-Goog-Experiments, x-goog-iam-role, x-goog-iam-authorization-token, X-Goog-Spatula, X-Goog-Upload-Command, X-Goog-Upload-Content-Disposition, X-Goog-Upload-Content-Length, X-Goog-Upload-Content-Type, X-Goog-Upload-File-Name, X-Goog-Upload-Offset, X-Goog-Upload-Protocol, X-Goog-Visitor-Id, X-HTTP-Method-Override, X-JavaScript-User-Agent, X-Pan-Versionid, X-Origin, X-Referer, X-Upload-Content-Length, X-Upload-Content-Type, X-Use-HTTP-Status-Code-Override, X-YouTube-VVT, X-YouTube-Page-CL, X-YouTube-Page-Timestamp", "access-control-allow-methods"=>"GET,OPTIONS", "date"=>"Wed, 20 Aug 2014 13:13:22 GMT", "expires"=>"Wed, 20 Aug 2014 13:13:22 GMT", "cache-control"=>"private, max-age=0", "server"=>"UploadServer (\"Built on Aug 12 2014 13:30:28 (1407875428)\")", "content-length"=>"0", "content-type"=>"text/html; charset=UTF-8", "alternate-protocol"=>"443:quic", "connection"=>"close"} #status=403>>>
After analysing the response while looking for things to hide (like the access_token), is it possible that the "access-control-allow-methods" paramater having the date and expires date the same is the issue here?
It seems the downloadUrl is directly connected to the access token. By storing the downloadUrl with the first access to the file's metadata and using the same downloadUrl with a new access token, the API was returning a 403 error. By requesting a new downloadUrl everytime a new token is requested as well, it works perfectly.
The 403 error means that you don't have the required rights, in this case, you are trying to use an expired token, this sounds like you have a problem with your cookie policy, change your cookie policy to none and let us know if the problem goes away.
Happy coding