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.Support 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.
Implement Office.context.mailbox.item.getAsFileAsync for draft messages
We have a requirement in an Office.js add-in to do the following: Automatically send a message Save the sent message The functionality was previously implemented using EWS and Office.context.mailbox.getCallbackTokenAsync. However, both are being phased out. Office.auth.getAccessToken is supposed to replace Office.context.mailbox.getCallbackTokenAsync, but we did not manage to get it to work in my add-in. To send the mail, Office.context.mailbox.item.sendAsync is now available, but it currently does not allow to execute code after sending. So we want to collect the draft before sending and process it in the back-end of our web app. We are hindered here by the fact that Office.context.mailbox.item.getAsFileAsync cannot be used on a draft. The function is currently not available for a draft message, we get the error message `Office.context.mailbox.item.getAsFileAsync is not a function` when trying to use it. The same works fine for messages in other Outlook folders like Inbox or Sent Items. To assemble eml-like text for the draft message so that we can save it in the back end of our add-in requires quite a lot of code. Also, img nodes reference external content, e.g., they have a src like `src="https://attachments.office.net/owa/.../service.svc/s/GetAttachmentThumbnail?id=` with id being a base64 string, where an eml should have `src="cid:` with cid referencing to a short id of a mime part in the same eml. There is no straightforward way to resolve all images when building an eml client-side.
Find all installed JS add-ins via the Office JS API
Currently the only way to determine the JavaScript add-ins installed in Excel, Word, or PowerPoint is to navigate to either of the following menu items: File > Get Add-ins > Office Add-ins Home > Add-ins > More Add-ins > Office Add-ins Under 'Office Add-ins' you can select 'My Add-ins', 'My Organization', and/or 'Admin Managed' to find the JavaScript add-ins installed, and how they were deployed. It would also be helpful to enhance the Office JavaScript API so you can: Get back a list of all installed JavaScript add-ins Get back a list of all installed JavaScript add-ins categorized/bucketed by 'My Add-ins', 'My Organization', and/or 'Admin Managed' We have seen instances where a JavaScript add-in exist under 'My Add-ins' and 'Admin Managed' as the user initially installs the add-in, but then the IT deploys the add-in. Get back any metadata like the version, install/update date, etc. Provide a specific add-in name get back if installed, how it was installed: 'My Add-ins', 'My Organization', and/or 'Admin Managed', and any metadata that can be included like version, install/update date, etc. Offering this feature via the Office JavaScript API would allow for installed applications and troubleshooting tools to be able to quickly and easily gather this information to determine if the JavaScript add-in has already been installed notify the user when the JavaScript add-in is already installed vs when it still needs to be installed debug issues or other vendor add-in conflicts identify equivalent add-ins that may both be installed (COM/XLL/Automations vs. JavaScript add-ins) Microsoft could potentially leverage this Office JavaScript API enhancement to display JavaScript add-ins within Desktop Office apps under File > Options > Add-ins. This would allow users to see their legacy and JavaScript add-ins in one single location.
Update channels for Office Add-ins
We would like for users to be able to decide which update channel to use. We have some internal users who need production stability and others who need to test the upcoming features, and some need to switch between the two. Right now, we need separate add-ins, each with its own distinct app ID, manifest and Azure registration What we tried: (1) All versions deployed at the same time. Cons: * Add-in behavior may conflict. E.g. our Outlook add-in is triggered "on compose" and set the email signature. When multiple versions coexist, all of them will set the signature in a non-predictable order. * Multiple versions clutter the toolbar, notifications from each version stack up on top of each other. * The user cannot disable a admin-deployed add-in so those problems cannot be avoided. (2) Max one add-in installed at the same time. Cons: * Switching versions through Microsoft 365 admin center requires upwards of 24 hours for the change to be in effect. * The different versions might still be overlapping during the transition period. We feel that update channels are a good solution to remedy those problems, as they're also used in Microsoft product to ease development and testing
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.
How 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.Pinned add-ins shouldn't be pushed out of view when sender address is long enough
(This was originally posted as a bug to https://github.com/OfficeDev/office-js/issues/4954) In New Outlook and Outlook on the Web, pinned add-ins are pushed out of view when sender address is long enough. All items on the message surface are pushed to the overflow (...) menu - Reply, Reply All, Forward, add-ins, Apps. The last one standing that won't be dropped is the Emoji button. Currently, sender address doesn't even have to be as long as in the screenshot above for the items to be pushed out of view. Current behavior All items on the message surface are pushed to the overflow (...) menu - Reply, Reply All, Forward, add-ins, Apps. The last one standing that won't be dropped is the Emoji button. This makes it really hard to increase the adoption of critical add-ins in a company. If both the Apps and web add-ins are pushed to the overflow menu, the Apps item appears as its own item in the overflow menu. However, it's actually a sub-menu that contains all the user's add-ins. The Apps menu item doesn't indicate it's a sub-menu which you can open, so end users fail to find their add-ins. Expected behavior Sender address should be wrapped in such manner that items on the message surface are not moved - there's no reason for the sender address to take over their space. Steps to reproduce Use either New Outlook for Windows or Outlook on the Web. Locate an email that has longish sender address. See how items on the message surface start to disappear. To increase the effect, decrease the width of your window - more items are dropped out of view.
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).
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-in
