Azure admins should be informed if client secret is about to expire for apps
When creating the microsoft add-in we have to set the client secret which is being used by our apps to provide contextual information in the add-in. This secret is set to expire at max every 24 months. Administrators are not informed when this expiry will happen. Once once the add-in stops working they get to know that it has expired. Solution - Alerts to be sent to azure admins to inform they of the client secret for any app or add-ins created. They should be able to configure these alerts based on the importance of the app or add-inSupport for nested security groups in Centralized Deployment
ASK: support nested security groups in M365 Centralized Deployment Most organizations have already set up security groups before deploying Add-ins. Using those existing groups would be an efficient way to determine what add-ins should get deployed to what users. But because of Centralized Deployment not supporting nested security groups, organizations are forced to create new dedicated flat security groups for Add-in deployment. They also need to adjust their talent onboarding and leave processes, removing and adding users from and too those new groups. This is an extra effort that many organizations need to organize and fund only because nested groups are not supported in Centralized Deployment.
Option to disable QUIC in WebView2 used by Office Add-ins
Some of our customers block QUIC traffic from their end users' machines. This is often because their firewall is unable to inspect TLS traffic when sent over QUIC, or they block all UDP traffic by default. Web browsers like Edge offer a way to disable the QUIC protocol through a group policy. However, these group policies intentionally https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/enterprise#browser-policies to WebView2 applications. We would like to offer our users an option to disable QUIC in the WebView2 used by our add-in. We have found that trying to use QUIC when UDP traffic is blocked may result in degraded performance or even prevent the add-in from making HTTP requests to servers that support HTTP/3.Load add-in automatically for all documents when deployed from admin.microsoft.com
Currently, VSTO/COM add-ins are loaded and started automatically when an Office host starts. It allows adding capabilities or trigger actions without the user having to do anything. However, office-js add-ins are only loaded in the document after the user triggers the loading the runtime, for instance by clicking on the add-in ribbon command. Setting Office.addin.setStartupBehavior(Office.StartupBehavior.load) is an effective way to load the add-in every time the document starts but it only applies to the current document. There doesn't seem to a way to apply it to all new and future documents. Ideally, there would be a way in admin.microsoft.com to specify that an add-in must be loaded every time a new document starts (or an option in the manifest).
Add-ins deployed before April 21, 2021 should be auto-pinned in Web Outlook when re-deployed
(Full story: https://github.com/OfficeDev/office-js/issues/2358 Problem: Back in Office add-ins Community call March 09, 2021, Microsoft revealed that admin-deployed add-ins would be automatically pinned to the ribbon in Web Outlook starting 21 April, 2021. We have many customers who already had deployed our add-in via Centralized Deployment before that date, but would now like to have it auto-pinned in Web Outlook. However, in our internal testing and testing done by our customers, re-deployed (remove+add) add-ins are not automatically pinned in Web Outlook. In addition to lack of auto-pinning, we are naturally not seeing the "nudge" notification. Completely new add-ins (not previously centrally deployed) are properly auto-pinned. I suspect the issue is in the design - the auto-pin was probably designed to increase the visibility of completely new add-ins, hence the nudge notification. But the auto-pinning is needed also for previously deployed add-ins. Centralized Deployment probably remembers the add-in was previously deployed (because of the same App ID) so neither auto-pinning nor nudge notification are triggered. Expected behaviour: Add-ins deployed via Centralized Deployment before April 21, 2021 should be auto-pinned in Web Outlook when they are re-deployed or updated. They don't need to have the nudge notification (unless you can track whether the user has ever used the add-in).
AutoOpen Outlook web add-in task pane functionally
We are using OnMessageSend LaunchEvent and we are trying to open web add-in when OnMessageSend Event fired but we are not able to open outlook add-in task pane functionally. AutoOpen feature is still not available in outlook web add-in. Please also check raised git ticket as below- https://github.com/OfficeDev/office-js/issues/3445 Please consider this feature when you go through the planning process. Thanks.Add a custom icon to outlook mailbox items from outlook web add-in
We need to show Green tick icon in mailbox item as we are showing from VSTO Pluging using below code- mailItem.PropertyAccessor.SetProperty("http://schemas.microsoft.com/mapi/proptag/0x10800003", 312) Now we need to set Green tick in mailbox item from web add-in So we tried custom properties as well as single extended value property to set on mailItem but still we are not able to show Green tick. Please check raised git ticket as below- https://github.com/OfficeDev/office-js/issues/3413 Please give support to add custom icons to outlook mailbox items from web add-in. Please consider this feature request when we go through your planning process. ThanksHow to get current page number and the total page count of a document using Word Add-in office.js
I would like to inquire if there is a method or feature available in Office.js for programmatically obtaining the current page number and the total page count of a document. Specifically, I am interested in accessing this information within the Microsoft Word application. Additionally, if such a feature is not currently available, do you have any plans or information regarding the potential release of this feature in the future? It's worth noting that our organization does not use OneDrive for any operations. Here are the details of my environment: Platform: PC desktop Host Application: Microsoft Word Office Version: Microsoft Word for Microsoft 365 MSO (Version 2304 Build 16.0.16327.20200) 64-bit Operating System: Windows 10 Pro Thank you for your assistance.
Allow code in custom functions add-in to limit the function list at runtime
We use Excel's JavaScript custom functions add-ins for various "sets" of custom functions that user may or may not have access to depending on their job role. Unfortunately, that means we have to have five different add-ins (one for each set of functions) that we enable/disable via AD membership. This is complicated to maintain, cumbersome to administer, and cluttered -- the add-ins also need a toolbar button, and of course there ends up having to be one for each add-in. Instead, we'd much rather be able to have code that runs when the add-in loads that tailors the list of functions available to the current user based on that user's identity. Then we could have a simple add-in and not have to deal with cross add-in messaging, multiple toolbar buttons To minimize the implementation effort to support, one approach would be to continue to have the functions defined by a JSON file as they are now, but add a hook of some kind during the loading process that the add-in can use to remove functions from the list. TIA
Add-in Manifest: allow wildcards for app domains
Currently all trusted app domains must be listed fully qualified in the manifest, e.g. <AppDomain>https://customer1.acme-eu.com</AppDomain> <AppDomain>https://customer2.acme-eu.com</AppDomain> <AppDomain>https://customer3.acme-us.com</AppDomain> <AppDomain>https://customer4.acme-us.com</AppDomain> Our company has several root domains for their customer tenants. In the example above acme-eu.com and acme-us.com. But as these customer tenant URLs (e.g. https://customer2.acme-eu.com) are sensitive data we can not put them in our delivered add-in manifest because all other customers would have the chance to see them. Currently our customers need to use the O365CentralizedAddInDeployment PowerShell command to configure additional domains before using our add-in which is extremely error prone and sometimes just not working. Many hours of support needs to be invested to get the configuration fixed. For example after every change in the configuration all users needs to manually clear their add-in cache in Excel. Having wildcards in the manifest would enormously help us and our customers: <AppDomain>https://*.acme-eu.com</AppDomain> <AppDomain>https://*.acme-us.com</AppDomain> During add-in submission Microsoft can validate that the used domains are trustful.
