Forum Discussion
Editing non-Office files directly from SharePoint Server?
I have some questions about opening non-Office files from SharePoint Server, while keeping an active connection" to the SharePoint list so that you can easily save the file from within your application.
Using Internet Explorer (or an Edge tab in IE mode), you could easily do this: you check out the file manually, click on the file and IE opens the file in your 3rd party application. When you're done, you save in your 3rd part application which – crucially – saves the file to SharePoint and then you manually check-in the file in SharePoint. All done.
Using Edge, it seems no longer possible. All non-Office files are automatically downloaded, and Edge simply asks "Open" or "Save as". If you Open, you edit a file from your local computer cache, with no SharePoint connection.
My questions:
- Is it still possible to via Edge open up non-Office files in a 3rd party application, while keeping an active "connection" to the SharePoint list?
- If yes, what governs if it works or not for a given file type? I thought it might be the old parameter AllowedInlineDownloadedMimeTypes, but I believe it's IE only.
Thanks for any insights!
3 Replies
1. Keep active connection
No, this is not possible. This is only possible for Office files such as docx, xlsx, pptx, ...
See https://docs.microsoft.com/en-us/office/client-developer/office-uri-schemes for a full list with supported file types.Changes made in the local application (e.g., Word) are automatically saved to SharePoint. This is great functionality.
2. Having control over which client application is opened simplifies support and training.
See Microsoft documentation on using Edge policies (https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#autoopenallowedforurls).We actually use a different approach to simplify the editing of non-Office files (e.g., PDF).
The user is informed about the different steps and it is very easy to upload the locally modified file. Plus the user is reminded (up to 30 days) if one or more documents are being edited.Please note that a temporary version of the file remains in the download folder on the local computer. The security and compliance folks may have an opinion on that. However, the approach is very flexible and can be used for different file types such as pdf, dwg, txt, ... and works for SharePoint Online and on-premise.
Hi Paul and thank you for your reply!
Ah, so it's the URI Scheme linking concept that enables there to be an active connection between SharePoint (On-prem in this case) and Office applications?
Editing with 3rd party apps straight from SharePoint
But 3rd party applications can also have an active edit connection to SharePoint, when you open their associated files from a SharePoint list.
For example, I have a drawing application called XMind 8 here, and if I click an .xmind file in a SharePoint 2016 list in IE or Edge in IE mode, then it opens the XMind application in Windows and I can save my changes straight to SharePoint. Note that check-in/out, if required, is not automatically done though, but that's easily manually done by users.
Questions
This leads to my nerd-curious questions/reflections: firstly, why does it work with XMind in IE? Do you think it's using a URI scheme? And secondly, why does it NOT work in Edge? Maybe it's the tighter security in Edge?
The local file problem
And as you say, the temporary local files that are generated if you don't have an active "edit link" to SharePoint is a problem, since many users don't even realize that the file was downloaded and then opened. And then they wonder why their changes aren't saved to SharePoint... 😞
Workaround
Anyway, a pretty good workaround for all 3rd party applications is to open the SharePoint sites in Explorer View; from there you can easily open the files in the 3rd party apps, while still saving directly to SharePoint. (Even with IE removed, you can just paste the SharePoint URL in a Windows Explorer window to get the WebDAV connection to an On-prem SharePoint.)
- Can anyone shed any light on why editing with 3rd party apps straight from SharePoint Server works via IE but not via Edge? I'm very curious about the technical causes for this behaviour.
