I have a problem with Outlook 365 add-in we are developing. The add-in should accept files dragged from user desktop. The web page is working fine with Drag&Drop in any browser: IE, Edge, Opera.
Same web page in add-in accepts only files dragged from Office 365 Application and doesn't accept anything from Outlook, user desktop, any other website or app.
So in fact add-in is droppable and working fine, but only for files dragged from Office 365 App.
Is there any special security setting in place?
The web browser which hosts your web add-in doesn't recognize and understand the format which is used for dragged items from Outlook. On the page Upload fails when user drags and drops attachment from email client you may find the following explanation:
All browsers are only expecting the actual file drag/drop format (CF_HDROP), but when dragging from Outlook, there is no file on the filesystem. What you get is the CF_FILEDESCRIPTOR and CF_FILECONTENTS formats. No browser that I know of (not even IE), knows how to handle that.
Related
As the name of the question states, I'm working with my company on a project in UiPath that is responsible for scraping a slurry of excel files from a SharePoint server. Unfortunately a decent portion of it is proprietary so I don't know how much of the actual code I can justifiably put here.
I have inside of UiPath (which is essentially a shell for vb.net and C# specifically tailored for automation) functionality to input a website url into the file explorer and have it navigate to the OneDrive folder for that SharePoint site.
This was working as expected until yesterday in the morning when it decided to brick itself and instead pull up the SharePoint site on the web browser.
Is there any way to ensure or otherwise understand why it won't open the folder path? I had it working before and I don't know why it doesn't work anymore.
Regards,
Jadda
I have a published/certified MS Outlook Add-In on the Microsoft Store:
https://appsource.microsoft.com/en-us/product/office/WA104381281?src=office&tab=Overview
It shows Product Supported: OfficeProductForAndroid and OfficeProductForIOS. However, the Add-In only appears on IOS devices (as well as Desktop, OWA, etc).
How can I get support to know why the Add-in does not appear on Android devices?
PS - it does work by adding our XML staging manifest directly. And other public store Add-Ins are working.
In mobile(iOS and Android) add-in need to be whitelisted to show on Add-in Management Screen if it is not installed manually or not installed at all.
Whitelisting of Add-in is done by our team on request. I think franConnect has been whitelisted. Soon it will start coming on Addin Management Screen.
when i am trying to view files from my TFS document library it's download the file instead of opening it automatic with excel OR word that are already installed on my pc, does someone know how to fix it?
i am using office365 and TFS2015 as you can see at the screenshot that attached this is how it's look like in PC that working fine.
This kind of issue may related to your IE security setting, try to add the related sharepoint site in trust site and try again:
Close your browser (if you don't and you have your SharePoint site up you'll get a bunch of script errors because of the change to access
levels).
Go to your Control Panel
Open Internet Properties
Select the Security tab.
Select Trusted Sites
Click Sites, and add the URL for your SharePoint site.
More details please refer this similar issue: "Some files can harm your computer" dialog when I open a file from the document library
If the warning dialog is disappear, but when you open file still download. Then that behavior maybe defined by your browser. Try some other browser such as IE/Chrome/FireFox. Double check the integration/link of your browser and Word,Excel.
I developed an add-in with a MessageComposeCommandSurface extension point.
It appears, is activated and works on outlook.office.com but with windows desktop client, Outlook 2016 (version 16.0.8625.2121), the button appears in compose mode but stays gray and it is not clickable.
I tested the command-demo-addin mentioned in Microsoft Docs and published on Github with the same result. Similarly, as shown on screenshot, it is impossible to click and launch the add-in which seems unactivated.
The COMPOSE buttons are disabled in the following instances:
1) The Item is in a public folder.
2) The Item is in Junk, Outbox (not drafts), or Sync Issues.
3) The item is "secure". DRM, or S-MIME encrypted. (older versions of Outlook also do not support S-MIME signed)
4) Outlook is offline.
In the situation where Read Mode add-ins are working, but Compose does NOT it is almost always #3. Usually the user will have on the option to always DRM / S-MIME their outgoing messages.
Update with image of security settings:
If Com Add-ins load a Custom Form this can also affect add-ins:
Checking Com Add-ins:
Note that outlook actually ships with some add-ins and a lot of com-addins work fine with Web Add-ins. It's only when Com Add-ins override the default new mail form (or other forms) that they can interfere with Web Add-ins.
Some COM add-ins will NOT use Custom Form, but will access the parent folder (item.Parent) and there is currently a bug that disable's Web Add-ins when a COM Add-in or VBA script does this.
File->Options->Add-Ins-> "Go" (next to manage add-ins)
If you have an antivirus instaled like avast, try to disable the addin of this and then try to open your compose mail window.
I installed Office Web Apps SP2 on our SharePoint 2010 farm this past weekend. I've observed that the service applications have been created and I've activated the feature at the site collection level. The word viewing service is started on all my WFE machines. When I access word documents from a library by clicking them or saying "view in browser", the site brings me to a blank document. No errors. I just get a blank document with a very basic ribbon that belongs to Word with buttons on it for 'file', 'open in word' and 'edit in browser'. However, if I hit "Edit in Browser", the site displays the document.
I'm not finding much interesting in the Sharepoint logs, even with OWA logging turned up to verbose. Excel documents come up fine in the browser without such a procedure.
I had no such issue when I installed office web apps in our TEST SP2010 farm.
Any ideas what I can look at next?
The powerpoint and word reader service applications had not been created as expected by the setup. Creating these solved our problem immediately.