My client complains that disabling a custom onsend web add-in for Outlook takes about 2 hours.
How they can do that more quick?
Related
We have a site used by Outlook addin hosted on sharepoint, when a user tried to access it they had a browser window open on the Sharepoint Online site, our front end is hosted there but it doesn't bring us to site location it just brings to Sharepoint home page.
We resolved this for a lot of users by adding runtimes in our manifest (this will force Outlook to use IE, whereas before browser is determined on a combination of 365 and windows versions). Still for some users it will bring us to a new browser, we have checked they are on the same Windows and Office 365 version as others who have the plugin working in Outlook task pane.
Also to note there is no issue with anyone using the plugin from OWA (web mail in a browser) and the redirect from desktop outlook looks like it for SSO then verifies user in browser and brings us to Sharepoint.
anyone have any idea what could be causing this?
The problem was caused by any sites or domains trying to be accessed by outlook addin need to be added to app domains in the manifest file. We ran a fiddler trace on the users machine and took a list of the domains that were being hit (for SSO) once we added them this issue was resolved.
We have setup and are hosting a centrally deployed Add-in for Excel developed with the OfficeJS API. We have had success in building, hosting, and testing the Add-in, but are now seeing a very strange issue that we are having trouble debugging. For context, the Add-in is developed with React, the OfficeJS API, and is intended to be loaded within Excel and primarily interacted with via the taskpane window.
Now that we have a working Add-in, we have deployed the Add-in to our first client using Centralized Deployment (https://learn.microsoft.com/en-us/office/dev/add-ins/publish/centralized-deployment) for the Client's associated Office 365 account. When deploying, we originally only deployed to a certain subset of users while finalizing testing, but since we have updated the "Assign Users" setting to "Everyone". We are now running into a strange issue where some of our users in the account are able to access the add-in, and some are not. It should also be noted that all of the users who originally had access still have access; it seems only a subset of the newly authorized users are unable to access the add-in.
So far, we have tried a number of things to re-create and/or resolve the issue, but have had no success:
Setting up new accounts - when setting up a new account, the new account seems to have access to the Add-in as expected. We are unable to re-create the bad state some users are experiencing.
Clearing Excel Cache - we have had users clear their Excel application and web cache, but nether has resulted in changes to access.
Logging in/out - we have worked with users to sign-out, clear cache, and sign-in again but this does not update any access settings for the Add-in.
Attempting to Manually "Insert" the Add-in - when opening the "Insert" tab and selecting "My Add-ins" menu from Excel, the user does not have the Add-in listed under the "Admin Managed" tab. If the user attempts to "Refresh" it still does not change anything.
We are starting to meet with some of the users who are experiencing the issue to further investigate, so any advice or further debugging tips would be greatly appreciated!
I am investigating how to convert an existing outlook add-in to authenticate to one of our APIs via Azure Active Directory. The way the add-in works, it would severely limit the user experience if they were constantly prompted with a dialog. If I were to base my solution off this sample project, how often could we expect the user to have to interact with a dialog or login?
I submitted an office 365 SharePoint add-in app for certification in the Office Store, and was told that one of the changes required is that I remove the 'Full Control' permission for the app, as it is not supported in the store. My app enables the user to create a new web site based on certain criteria. The add-in works correctly with 'Full Control' permission, but does not work with lower levels such as 'Manage'.
If the store does not allow me to use 'Full Control', what permissions or options can I use in order to still be able to create sites on behalf of the user?
Is there a different way to go about having the add-in app create sites in an existing site collection? The trigger can be user initiated, or event based.
I would love to get any ideas or solutions for this - Thanks!
The only option I can think of is to create a web service that is external to SharePoint and create the site in the service.
Here are a couple of resources that may help you:
Walkthrough: Building a Custom Web API for use with SharePoint Online
PnP Webcast - Calling external APIs securely from SharePoint Framework
The company I work for is using SharePoint as a CMS for it's public facing website. I recently enabled FBA (Forms Based Authentication) for the site in order to provide some user specific functionality, but this has caused a side effect with Word / Excel files when opened from the site using Office 2007 / 2010.
Some users are challenged for authentication when opening a Word / Excel document from IE (but not when they're select "save file" instead of "open file"). A window pops up behind IE / Word / Excel (so you often don't realise it's there) showing the sites login page. If the window is dismissed then the document continues to open normally.
It seems to be environmental. Most Office 2007 / 2010 users internally experience this and we've had one report externally of this happening.
Anyone know how to prevent this behaviour?
In case it's relevant: The company also has an internal SharePoint site using NTML authentication allowing internal users to edit the same content visible externally.
I originally suspected the SharePoint header added to responses may be alerting Office to check for authentication to allow extended functionality, but I remove the response header in IIS and it didn't make any difference.
In the Authentication Provider for the FBA enabled site, do you have Enable Client Integration? set to Yes?
Central Administration > Application Management > Authentication Providers > Edit Authentication