Mail App new 1.1 API: Problems, limitations and suggestions RRS feed

  • General discussion

  • Hello

    First a big thanks is in order for new API 1.1 -> most of the wanted features have been supported in it.

    With that said i think there is still some missing to actaully make it usefeull (or am i wrong and is there some undocumented methods out there).

    Main problem is modifying composed item body...i would like to be able to replace a text inside the body wihtout user selecting it (for example if a mail app is building a table it needs to be able to modify it). For now this seems again only possible with backend changing the item via EWS calls. Why not allow to also get and set the whole body (or part) with Read/Write mailbox permission in API 1.1 .

    Or another solution would be to add a method in API with which you could force the composed item (or even item opened in read form - default OWA click action) to reload content from Exchange (thus allowing changes to be made via EWS and also presented to user instantly...but this would make user made changes get lost since read whole body is not supported in API 1.1 even with Read/Write Mailbox) .

    I have also been trying to find out why an app made to activate on appointment is now no longer activating in Outlook? Did any changes happen here aswell? (before an app activating on appointment in Outlook would open no matter what - compose mode or not, now it does not...how would one restore such behaviour since this was one of the features taht actaully made our app more usefull - now it appers it only opens if you are not appointment owner)

    Is it possible to now add an attachment to an item via EWS call?

    And some minor issues worth thinking about:

    • having an app to start with two clicks in composed mode is a bit much...is there a way to make an app bar visible like in read mode?
    • the design of composed apps docked on side...why not let it be on top?

    Thank you

    Anze Javornik

    Monday, May 19, 2014 12:04 AM

All replies

  • Hi Anze,
    Thank you for your detailed input and feedback! Of the few things you mentioned, I'd like to confirm the current support and your requests so that our product teams can better understand your needs:

    Currently supported:
    (1) In compose and read mode:
    Use ReadWriteMailbox permission, makeEwsRequestAsync and EWS operations GetItem and UpdateItem to get, modify or replace item body.
    (2) In compose mode:
    Use ReadWriteItem permission, prependAsync to prepend data, or setSelectedDataAsync to insert data at cursor location, or replace user-selected portion, of the item body.
    (3) In read mode:
    Use ReadItem permission, use getCallbackTokenAsync and EWS operation GetItem to get the full item body.
    (4) In compose mode:
    Use ReadWriteItem permission, addFileAttachmentAsync and addItemAttachmentAsync to add attachments to an item.

    Questions for you:
    (a) You asked about adding attachments via EWS. There is no support through makeEwsRequestAsync, as it doesn't support the EWS operation CreateAttachment. Would (4) be a good solution for you though?
    (b) Would you like to share the manifest (including activation rules) of your mail app, and test appointment item where you were able to but can no longer have the mail app activated? At the moment, I can't think of what's been changed with respect to activating mail apps in appointments such that it used to work but not anymore. Let's see if anybody else can identify the issues you're having.

    Your requests:
    (A) With respect to (2), in compose mode, allow replacing portions of item body without prior user selection.
    (B) Expose compose apps in an app bar rather than an app selection pane which requires 2 clicks to start a compose app.
    (C) Flexibility in placing the app pane of a compose app as a horizontal pane as opposed to always a vertical task pane.


    MSFT Content Developer

    Tuesday, May 20, 2014 2:54 AM
  • Thanks for the reply.

    I can confirm currently supported functionalities.

    As questions goes:

    (a) It is a bit limited. Our example is that app activates on read mail item and allows you to "link" the mail with appointment at which time we would not like to only change content of the appointment via EWS call but maybe also add this mail as attachment. (to add exchnage item attachment not file). Also i have not yet tried, but i have a felling that attachments made with API call cannot be palced inline (since in EWS you need to specify that attachment is inline -> i may be wrong here and Will know more tommorow)

    (b) These are the activation rules our app used (cannot post the whole manifest on forum, but i think we can do that via some other method like email)

    <Rule xsi:type="RuleCollection" Mode="Or">
      <Rule xsi:type="ItemIs" ItemType="Message"/>
      <Rule xsi:type="ItemIs" ItemType="Appointment"/>

    Before (dont know how long ago, but i think that it is linked with API 1.1 release) our app was activating if we in Outlook client did:

    1. in calendar create appointment and save it
    2. open appointment again and app would activate (here you could also change appointments body - so it was opened in compose mode)

    About my requests:

    (A) Yes...if an app requires ReadWriteMailbox permissions it already has Access to full body content. So allowing an API call to repalce text would not be such a security issue since it can do taht already via EWS call (what we are doing now). But the problem with our approach is that we cannot force the item form to refresh its content from Exchange after EWS request. So either allowing an API method to set whole body text (or replace a portion) or allowing an app to force form to reload from exchange would solve the issue (ofcourse API solution would be much better)

    (B) Yes. Two clicks to activate an app is too much and i dont think users Will ever use it...specailly becosue one is Quite well hidden in the ribbon.

    (C) Yes. That would make the app look and fell the same on all modes. Also am not sure why if docked to right there is no option to choose requested width as it is with height when docked on top.

    Thank you again

    Anze Javornik

    Tuesday, May 20, 2014 3:26 AM
  • Another surpising fact: In compose mode of an item which already exists (editing it) you cannot get its id. In our app we are setting some ExtendedProperties via EWS calls. We cannot save this data with APIs custom properties, since you cannot use EWS FindItem method to filter on those.

    Anze Javornik

    Wednesday, May 21, 2014 12:36 AM
  • After a hard effor to work around the limitations here are my thoughts, requests and suggestions:

    • If an app requires ReadWriteMailbox permission API should allow to get and set whole body content
    • Two clicks to activate an app in compose mode makes app more or less useles (activation in my oppinion should be same as in read mode - app bar)
    • unable to get item id in compose-edit mode for items really surprised me...if in read mode is available it definitly should be in write mode aswell (this is solvable by using FindItem EWS call with a lot of constraints -> not 100% though)
    • for compose mode item which is beeing newly created add function saveItem to API which would save this item in SaveOnly mode and return itemId -> thus allowing more comples EWS calls to modify it (set extended properties, ...) -> an app could then have "In order to use this app you need to save it by clicking here" or having an app activation saving it on startup
    • since attachments can be added via API it should be possible to add them with EWS which even requries higher permission model (allowing to attach exchnage items only would already be a big step)
    • missing API call to reload item form from Exchange if a change is made via EWS UpdateItem call.

    Upper requests are serious limitations for app we are making (or made since it already is on market but sometime ago started to behave differently - not activating in Outlook for appointments anymore). Goal of our app was to provide interaction between messages <-> calendar <-> tasks . So if our app is opened on one item it can produce changes (attendees, subject, body, attachments, ...) on another item. (Ofcourse not all is possible yet (attachments), but its really close now...i hope you Will think about allowing EWS calls for creating attachments and creating an API function to force reload of opened item form -compose or read mode - to reload its content from exchange - also an API call saveItem which would couse a newly creating item to be saved and as return value provide its id which can be used to further manipulate item via EWS).

    Anze Javornik

    Wednesday, May 21, 2014 2:31 AM
  • Hi Anze,

    I really appreciate you spending the time to describe your scenario and requests. I will make sure our product team takes note of this, if they haven't already.

    About (b) your difficulty getting the mail app activated for an appointment in compose mode:

    Since compose mode is supported only starting in version 1.1 of the apps for Office schema, I assume you have included the appropriate namespace for v1.1 of the schema at the beginning of your manifest?

    In particular, in version 1.1 the ItemIs rule takes on a new, required attribute FormType, regardless of whether you're activating in read or compose mode. Have you included that attribute? An example:

    <Rule xsi:type="ItemIs" ItemType="Appointment" FormType="ReadOrEdit"/>

    Since we're at it, just want to mention that there are a couple other new elements in version 1.1 of the schema, also required for read or compose mode:

    • The Requirements element to specify the Mailbox requirement set
    • The FormSettings element to specify the source files for read mode and/or compose mode

    You can see the details for the manifest changes here: Create mail apps for compose forms in Outlook

    Hope that helps?


    Wednesday, May 21, 2014 3:42 AM
  • Thanks for reply

    In schema 1.1 and API 1.1 the activation is not a problem.

    Our app (a year+ ago on 1.0) was activating in Outlook when you opened an appointment in compose mode (defualt double click). Recently it stopped doing so...i assume it is becouse of some change that happened with 1.1 release.

    Anze Javornik

    Wednesday, May 21, 2014 3:47 AM
  • Found another app activation problem in API and schema 1.1 .

    The app does not activate in OWA when opening an appointment in read mode (either opened via API displayAppointmentForm or by clicking the button to open it in window in OWA). If clicking edit and entering compose mode, then you can activate the app.

    If the appointment is opened with default double click action (opened in a right docked frame), then app activates fine.

    Anze Javornik

    Wednesday, May 21, 2014 10:04 AM
  • Anze, this problem you described:

    "Our app (a year+ ago on 1.0) was activating in Outlook when you opened an appointment in compose mode (defualt double click). Recently it stopped doing so...i assume it is becouse of some change that happened with 1.1 release."

    Since you said it's on v1.0, that's a read app, not a compose app, that you're trying to activate, correct?

    Thursday, May 22, 2014 12:55 AM
  • Yes, but in Outlook appointment always opens in write mode (if you are the owner). I guess this is the reason why app was activating, else appointment activation in Outlook would never happen (in 1.0). In 1.1 app is activating fine with ReadOrEdit (except for the problem described two posts up -> not activating in OWA if message is opened in popup).

    In other words: if you have app on schema 1.0 and rule set to activate on appointment the app no longer activates on appointment in Outlook, while it was activating a year+ ago (dont know when exactly it stopped, but i assume something in Outlook changed with API 1.1 and ReadOrEdit activation release).

    We have rewriten our app to API and schema 1.1, so we dont have a problem anymore...however this change is affecting all other apps which are still on 1.0 and want to activate on appointment - they simply will not activate anymore in Outlook unless rewritten to 1.1 .

    Anze Javornik

    Thursday, May 22, 2014 5:53 AM
  • Anze, thanks for the confirmation of the problem. We'll follow up and get back to you on that. And yes, that problem you described on OWA too.


    Thursday, May 22, 2014 6:48 AM
  • We've made a slight modification to appointment activation. As of 1.1, mail apps set to activate on appointments will only do so on meetings where the user is NOT the organizer. For meetings where the user IS the organizer, only apps in compose mode will activate. This is because Outlook client uses a single form for both, reading an appointment and editing it.

    We felt that showing both, read and compose apps would be very confusing to users (imagine an app that activates in read and compose - so which version do you use on the appointment? In some cases, one version won't work at all, or will be the inappropriate one to use and will mess the entire appointment up). Additionally, we felt that on appointments where the user IS the organizer, it's the app that helped the user compose the appointment to begin with (ie compose app) that would be most useful, not a read app. Thus, we decided to simplify everything.

    Hope that explains things.

    Wednesday, May 28, 2014 3:42 PM
  • I understand. Just want to point out, that apps on API 1.0 no longer work as they were before and that the change made in Outlook is not backward compatible....i think such change should only apply for apps on API 1.1 and remain working as before on API 1.0, or atleast make a big post that apps on API 1.0 will nolonger work in Outlook if they use appointment activation. Am surprised becouse of this change, becouse it was more of a coincidence that we found this new behaviour this soon...specially since app we belived worked fine is available on office store. Ther are still a lot of apps on store which use appointment activation and have not been updated since API 1.1 release and i assume it is becouse they dont know.

    Anze Javornik

    Wednesday, May 28, 2014 3:53 PM