Enhanced Document Control/Protection APIs in Office.js for Word Add-ins
We are developing a Word add-in using Office.js and JavaScript APIs. Our use case requires advanced document control features, which are currently challenging to achieve within the existing Office.js framework. Here’s our feature request: Proposed Functionality: Based on the defined custom properties on a document via add-ins, provide APIs/commands/hooks to disable or override Word's default 'Save,' 'Save As,' and 'Share' options to prevent users from saving or sharing the document locally. Introduce additional APIs for implementing custom protection mechanisms within the add-in. Current Challenges: Achieving this functionality appears possible through VSTO add-ins, but they are not compatible with Office.js solutions. VSTO/.NET commands require complex workarounds, such as creating a separate .NET server to communicate with Office.js, which adds development complexity and affects efficiency. Request: We would greatly appreciate the introduction of built-in, efficient APIs in Office.js to handle document protection and control scenarios seamlessly without relying on external frameworks or services. This would significantly enhance the capability of modern web-based add-ins and improve the development experience for Word add-in developers.Add Method to Create Hyperlinks in PowerPoint JavaScript API
I am writing to request the addition of a method in the PowerPoint JavaScript API that allows developers to programmatically convert text into hyperlinks. Currently, this functionality is available in the Word JavaScript API, where the Range.hyperlink property can be used to set a hyperlink on a range of text. However, a similar capability does not exist in the PowerPoint JavaScript API. At present, the only ways to create hyperlinks in PowerPoint are through the user interface or by using VSTO add-ins. These methods are not ideal for developers who wish to automate the process within web and Mac add-ins. Implementing a method to set hyperlinks on text within the PowerPoint JavaScript API would greatly enhance its functionality and bring it closer to parity with the Word JavaScript API. This addition would be beneficial for developers seeking to create more robust and feature-rich PowerPoint add-ins. Thank you for considering this feature request. I believe it would be a valuable enhancement to the Office.js library and look forward to any updates on this matter. Sincerely, Simon Breslav[Office.js] [Word] Add functionality to close hidden document (DocumentCreated)
Cloned from https://github.com/OfficeDev/office-js/issues/6339#event-21523882551 Context We use the DocumentCreated object to do some background operation (like converting html to ooxml). And from the name of the requirement set (WordApiHiddenDocument), I believe this API is designed to run without user's action. But there're two problems: The user is asked to save a document which he/she haven't seen, which causes big confusion, especially when there're many DocumentCreated objects. BTW, I remember there was no such prompt in earlier version of Word. From the behavior, we know that the created documents are keeping opened until all Word's processes are terminated. This may cause serious memory leak. We suggest, there should be a close method on DocumentCreated, just like normal Document class, so that we can close the Document manually. Steps to reproduce Open Script Lab Paste and run the code in the "Code Snippet" Section In script lab "Run" page, Click "Run" button several times. Close Word. Note: You need to close all Word windows, not only the current document. On mac, you need also exit Word process by selecting "Quit" on Dock menu. You can see that Word asked several times to save Document5, 4, ..., 2, which are hidden documents. Code Snippet await Word.run(async (context) => { const doc = context.application.createDocument(); await context.sync(); doc.body.insertText('xxxx', 'Start'); await context.sync(); doc.body.clear(); // clear won't change the behavior await context.sync(); doc.untrack(); // untrack won't change the behavior await context.sync(); })
Support getting the timezone of an appointment
Currently the start time and end time of an appointment item is returned in UTC. This is fine. However it is currently not possible to determine in which time zone the user originally placed the appointment. Assume the user is currently located in Copenhagen (UTC+1) and creates and appointment taking place at 10.00 UTC-7. In add-in code I can get the start time as UTC (17.00) and I can most likely also determine in which time zone the user is currently located and/or which time zone the user's calendar is by default using. However, I would like to be able to determine that the user originally created the appointment in UTC-7. If the user creates a recurring appointment it IS possible to get the timezone of the appointment through the recurrence data. I like to be able to determine the same for a non-recurring appointment.Add parameter to OnAppointmentSend event to enable detection of meeting cancellation
Currently it is not possible to detect when a user cancels a meeting. This could be made possible by adding a parameter to the OnAppointmentSend event to allow developers to detect whether the meeting message being send is intended as a cancellation.
Enable displayNewAppointmentForm(Async) in Outlook Compose mode for calendar add-ins
I’m building an Outlook add-in that helps users plan public transport journeys around their meetings and create corresponding calendar entries. The add-in is called "OutlookSwissPT-OfficeJS" and uses the Swiss public transport timetable to propose outbound and return connections for a given appointment. The project is open source on GitHub; you can find it by searching for "OutlookSwissPT-OfficeJS" or for the repository "mbeer/OutlookSwissPT-OfficeJS". Example usage of displayNewAppointmentForm(Async) in this add-in can be found in the file "src/taskpane/taskpane.js". Today, the add-in relies on Office.context.mailbox.displayNewAppointmentForm and displayNewAppointmentFormAsync to open new pre-filled appointments for selected connections, for example an outbound journey to a meeting or a return journey from that meeting. According to the Office JavaScript documentation and the Mailbox requirement set tables, both methods are only available in Read mode, not in Compose mode. In the requirement set tables, the applicable Outlook mode for displayNewAppointmentForm and displayNewAppointmentFormAsync is listed as "Read" only. This has a few practical consequences. In Outlook on the web, calendar events that I own or organize are typically opened directly in Compose mode from the week view, so there is effectively no "pure" Read mode user interface for my own events. In this situation, my add-in can still show its task pane, but it cannot use displayNewAppointmentForm(Async) at all, because those APIs are not exposed in Compose mode. The same limitation applies in other Compose scenarios, for example when creating a new meeting or editing an existing one in Outlook Desktop or the new Outlook. I have implemented a workaround by detecting Compose versus Read mode in my task pane. In Compose mode, the add-in offers a limited mode. The user can still run the timetable search and see the list of suggested connections, but the buttons to insert a connection as a calendar appointment are hidden or disabled. A banner explains that automatic appointment creation is not available in Compose mode and that the user must either manually copy the details or save the appointment, reopen it from the calendar in Read mode in a supported client, and then run the add-in again. While this workaround is functional, it is not ideal from a user experience point of view. The most natural moment to plan journeys is exactly when the user is creating or editing a meeting in Compose mode. REQUESTED CHANGE Please consider extending the contract of displayNewAppointmentForm and displayNewAppointmentFormAsync so that they are also available when an add-in is running in an appointment or message Compose context, not only in Read. An add-in in Compose mode should be able to open a separate new appointment form, for example for a travel connection, in the same way it can today from Read mode. I am not asking to modify the currently edited appointment in place. I am asking to allow an add-in that is active in Compose mode to open additional new appointment forms via the existing APIs, with the same parameters and behavior as in Read mode. WHY THIS MATTERS Travel and logistics helper add-ins, such as a public transport timetable, flight picker, or travel time calculator, are a very natural fit for meeting creation and editing workflows. Restricting displayNewAppointmentForm(Async) to Read mode forces users into an artificial workflow where they first have to create and save the meeting, then close it, reopen it from the calendar in Read mode, and only then can the add-in open new appointments for the journeys around that meeting. In Outlook on the web, where own events are opened directly in Compose, this is particularly confusing, because users do not even see a clear "Read mode" state for their own appointments. Allowing displayNewAppointmentForm(Async) in Compose mode, to open new appointments and not to change the current draft, would make calendar-related add-ins much more intuitive and powerful. It would reduce user confusion and support load for add-ins that currently have to explain why some scenarios are artificially limited. It would also align better with the mental model of a user who is creating or editing a meeting and would like the add-in to create related calendar entries for travel. If there are technical or user experience constraints that make this difficult, it would already help to have an official statement or guidance on whether support for Compose mode is planned or explicitly out of scope.
PowerPoint.ShapeCollection.addFromBase64( base64File, options )
This API closes a large gap in the surface area of creating content in PowerPoint. There is already support for inserting new slides via the PowerPoint.insertSlidesFromBase64( base64File, options ) function. And, there's support for adding various geometric shapes and images via the PowerPoint.ShapeCollection.addGeometric/addLine/addTextBox methods. (Annoyingly, images need to be added with the generic setDataAsync method.) The new API would work similar to the insertSlidesFromBase64, accepting a list of shapeId/drawingElementCreationId of the shapes to insert from the base64 encoded slide.xml, or inserting all of the shapes on that slide. Additional options like specifying where in the z-order of the existing shape collection to insert the new shapes would be useful, too. Add-in developers could get the relevant slide.xml from a pre-generated presentation and extracting it. Or, if simpler, a complete PPTX file that contains only a single slide could be base64 encoded as provided by the new PowerPoint.Slide.exportAsBase64 method. Overall complexity of adding this new feature is fairly low. Use a parallel implementation structure as the insertSlidesFromBase64, but adding one extra depth traversal into the shape collection and then adding shapes to the current slide rather than slides to the current presentation.
Identify multiple embedded instance of the same add-in in a file as one
Summary By default, when a file is opened in Excel with a JS add-in installed and then saved, the JS add-in is automatically embedded in the file. In the current design all embedded add-ins will be attempted to load when the file is opened even if the embedded add-ins are the same. As a result, when these files are shared with other users who already have the same JS add-in installed with a different version or deployment method, Excel displays two instances of the same add-in in the tabs, or occasionally shows an error in the task pane if the version it is embedded is an older one. We first became aware of this issue when a user reported seeing our JS add-in appear twice in the ribbon, which led to confusion. Upon inspecting the affected file’s XML web extensions, we identified two versions of the same add-in embedded: one deployed via OMEX and another via exCatalog. After further investigation and filing a ticket with Microsoft Support, it was confirmed that this behavior is by design under the current implementation. Why This Matters While we understand that this behavior is expected by design, it remains problematic for users—it can cause confusion and potential issues with custom functions or with the add-in itself. Also, it is not clear for As of the moment there are no easy workaround for users to remove the duplicate/additional instance of the same JS add-in embedded in the file, this will also need to be done for every file that is suffering from this issue (has multiple instance of the same add-in embedded in the file w/ different version/deployment method). Proposed Change/s Update current design to be able to identify if the embedded adds-in is the same through checking and comparing a unique id so even if they have different deployment/version tags it will not be loaded/attempted to be loaded in the task pane. Alternatives Considered Provide an option in Officejs API to prevent embedding/referencing add-in in a file Benefits Prevents users from seeing the same add-in appear twice in the file Eliminate propagating errors in the task pane from trying to render the same add-in with the old version tag [Alternative considered] Allow users/dev to be able to control which add-in gets embedded in the file
