Существует множество случаев, когда это уместно:
Я полагаю, что целью многих надстроек является увеличение элемента (например, встреча / собрание или электронная почта), пользователь в данный момент читает илисочинял.Обычно это делается в сторонней системе, связывая собрание в Exchange с «записью» в отдельной системе.Чтобы выяснить, связано ли текущее собрание с «записью» (и, возможно, отобразить ее содержимое), вам нужен способ, чтобы явно идентифицировать собрание.Если это новое собрание, вы знаете, что «записи» нет, однако, если это уже существующее собрание, вы должны иметь возможность идентифицировать его.Предоставление itemId в режиме компоновки удовлетворит эту потребность.И, кстати, функция уже запрошена в User Voice!
Я могу только догадываться, почему Microsoft еще не добавила эту функцию, но я думаю, что Office JS начал с поддержки электронной почты.Режим составления для электронных писем почти исключительно предназначен для создания новых (неотправленных) электронных писем, поэтому у них никогда не будет itemId.
Однако это не относится к встречам и встречам.Они часто редактируются после их создания, так как собрания часто переносятся по расписанию, дополняются более детальной повесткой дня и т. Д.
К сожалению, обходной путь использования saveAsync для получения itemId имеет несколько недостатков, о которых вы уже упоминали: это очень навязчиво, поскольку оставляет за собой «призрачные» собрания (поскольку пользователь теперь не может сожалеть о сохранении встречи / собрания) и вызывает отправку ложных обновлений для участников и т. д.это не работает в Outlook для Mac!- одно из главных преимуществ этой технологии надстроек по сравнению с надстройками VSTO / COM.
В моей компании мы несколько раз пытались перенести существующую надстройку VSTO на Office JS, нокаждый раз, когда мы останавливаемся на этом точном вопросе, поскольку недостатки просто для многих!
Тем не менее, подход - помимо, возможно, использования некоторой грубой эвристики - у нас мысль о, выглядит так:
1) Через EWS (или MS Graph), увеличениекаждое собрание (!) каждого пользователя (!) с настраиваемым свойством надстройки, содержащим itemId.См. https://stackoverflow.com/a/43140644/10752973 о том, как устанавливать пользовательские свойства "извне".
2) Когда надстройка открыта, проверьте, присутствует ли пользовательское свойство.Если там есть пользовательское свойство, то это уже существующая встреча / собрание (и вы будете знать его itemId).Если его там нет, это новое назначение.
Как я уже сказал, мы его не реализовали, но в теории это может сработать.Но это такая огромная проблема (и обременительная как для сервера Exchange, так и для самого приложения) из-за чего-то такого простого.Нам также необходимо отслеживать каждый почтовый ящик в Exchange, чтобы обнаруживать вновь создаваемые встречи / собрания, чтобы дополнить их пользовательским свойством, которое излишне сложно.
Но я надеюсь, что этот ответ может убедить Команда надстроек Outlook пересмотрит возможность добавления поддержки для получения itemId в режиме составления для встреч / собраний.