The existing manifest was not exposing the add-in tools when
creating a meeting in a shared calendar. Amend the manifest with the
missing instructions so the add-in shows up in that context as well.
Manifest changes generated with Claude's assistance.
Add the possibility to display a feedback form link in the footer to
help collect feedback from the first users of the plugin.
Once the plugin is in production at scale, this will be replaced
with a link to the support page.
Offer the possibility to append a query parameter at the end of the
meeting URL to flag links created from the Outlook plugin, inspired
by Zoom.
The behavior is toggled via an environment variable.
From the task panel, change the "add" button to "remove" when a
meeting link is already present.
This will be updated to "update" once the external API supports
updating an existing room.
Detect whether a meeting link is already present in the calendar
event item or its body, and prevent generating a new link if one is
found.
Detection is based on the presence of the app URL in the text. This
is imperfect but covers the most naive scenarios.
Refactor the plugin to support internationalization and ship it in
three languages.
Internationalizing requires updating the manifest, which involves
touching the Helm chart and releasing a new version. Ship a beta
version of the plugin once the i18n work is done to bundle these
changes together.
In the ribbon, the "create a meeting link" action was displayed with
the generic add icon, which is fitting in the context of a menu but
not explicit enough on its own.
Following feedback from the social ministries, replace the add icon
with the app logo to make it clear that this button creates a
videoconference link.
Instead of appending the meeting link at the end of the email, insert
it where the user's cursor is. This ensures the link is not placed
after the email signature, or below the quoted thread in a reply.
Refactor the message builder so that rendered messages are displayed
in a nicer way. Based on user feedback from the social ministries.
Go for a hybrid approach: on the desktop client, insert plain text so
it picks up the default font configured by the client theme; on the
web client, insert HTML, as the editor there is rendered using HTML.
The dialog window does not close itself on Outlook Desktop, which
opens links in a webview that behaves like a different browser.
Calling window.close() fails because, for security reasons, JS is
prevented from closing the window. The browser considers that the JS
script is not the one that opened the dialog.
The dialog also loses its reference to the opener due to the
redirection, so there is no way to message the parent to trigger a
close.
Keeping the dialog reference on the parent side does not help either:
since the opener is lost, the parent cannot call close on the dialog.
After investigation, go with a temporary solution that shows an
explicit message hinting the user to close the dialog manually if it
does not close automatically.
Provide the minimal components required to support an Outlook
add-in: user authentication, JWT retrieval, and API calls to
generate meeting links.
This implementation is an early alpha: developer experience is
limited, documentation is incomplete, and the solution is not
white-labeled.
It's too early to consider these parts ready to ship into
production.
As a result, it is currently only available within the DINUM
frontend image.
snyk-bot