none
App for Outlook: Get CustomProperties with EWS RRS feed

  • Question

  • Hello

    I am wondering if it is possible to retrive CustomProperties on mailbox item, that are set with JS API. I am trying to filter items with FindItem EWS call  .

    Is there a list of all extended field uris where i could see which property to check for?

    If this is not possible is the recomended workaround to store everything in roamingSettings?

    Thank you


    Anze Javornik

    Wednesday, February 27, 2013 3:22 PM

Answers

  • Anze,

    The ExtendedFieldURI is the mechanism to get general MAPI properties, both regular and named. While the list of regular MAPI properties (IE, those accessed using PropertyTag) is by definition finite, there is no exhaustive list of all possible MAPI properties tags. Named properties (using either PropertyName or PropertyId) can be declared/defined by anyone, so there is no list of those.

    What you can look for is the list of properties which have been documented for use by Outlook and Exchange. The Exchange Protocol Doc [MS-OXPROPS] is a good place to start: http://msdn.microsoft.com/en-us/library/cc433490(v=EXCHG.80).aspx

    Additionally, the Outlook 2013 MAPI Properties documentation contains a good list of properties, many also documented in [MS-OXPROPS] but some used only by Outlook and hence not documented in the protocol docs. You'll find that here: http://msdn.microsoft.com/en-us/library/office/cc815517.aspx.

    Finally, if you're approaching this from the view of "I'm pretty sure there's a property for X, but I don't know what it is", I suggest using MFCMAPI (http://mfcmapi.codeplex.com) or EWSEditor (http://ewseditor.codeplex.com) for exploration.

    As for workaround, it's not clear the problem you're proposing to work around.

    Friday, March 1, 2013 8:36 PM
  • Hi Anze,

    it is possible, but not recommended. Are you using EWS from the app instead of from a backend service, because of auth issues?

    For your scenario, since you're already using EWS and FindItem, why not just use UpdateItem and set a exchange custom property (named prop), instead of using JS custom props API? Then you know the name of your prop, so it's much easier to search.

    -Andrew

    Wednesday, March 6, 2013 1:30 AM

All replies

  • Hi Anze,

    Thank you for posting in the MSDN Forum.

    I'll consult your issue with my colleague. You'll be informed if there's any update.

    Thank you for your patience and understanding.

    Best regards,


    Quist Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, March 1, 2013 7:23 AM
    Moderator
  • Anze,

    The ExtendedFieldURI is the mechanism to get general MAPI properties, both regular and named. While the list of regular MAPI properties (IE, those accessed using PropertyTag) is by definition finite, there is no exhaustive list of all possible MAPI properties tags. Named properties (using either PropertyName or PropertyId) can be declared/defined by anyone, so there is no list of those.

    What you can look for is the list of properties which have been documented for use by Outlook and Exchange. The Exchange Protocol Doc [MS-OXPROPS] is a good place to start: http://msdn.microsoft.com/en-us/library/cc433490(v=EXCHG.80).aspx

    Additionally, the Outlook 2013 MAPI Properties documentation contains a good list of properties, many also documented in [MS-OXPROPS] but some used only by Outlook and hence not documented in the protocol docs. You'll find that here: http://msdn.microsoft.com/en-us/library/office/cc815517.aspx.

    Finally, if you're approaching this from the view of "I'm pretty sure there's a property for X, but I don't know what it is", I suggest using MFCMAPI (http://mfcmapi.codeplex.com) or EWSEditor (http://ewseditor.codeplex.com) for exploration.

    As for workaround, it's not clear the problem you're proposing to work around.

    Friday, March 1, 2013 8:36 PM
  • Will check the links you posted and update this post.

    As workaround goes i am hoping i wont even need one. Roaming Settings for a mail app get saved into Exchange mailbox. Also settings per mail per app get saved into Exchange mailbox. My post was if it is possible to retrive thise per mail per app settings with EWS call (and i think this might be like a catagory list retrival).

    If the above is not possible (getting custom properties sved with JS API saveAsync function ) then imagine this scenario:

    • in an mail app one can mark a message with a specific app owned property
    • now i would like to make a search for all messages that have this property set (FindItem ews method)

    If above scenario is possible i could call ews method FindItem with AdditionalProperties with "per item per app" property id that Contains "some value".

    If the above scenario is not possible then the question was if a proposed workaround is to store all the items you set this app specific property to in romaingSettings?

    I hope i explained it a bit better now.

    I could use UpdateItem to set aditional properties, just i would like to use built-in properties before adding anything custom. So reading "per item per app" and filtering on it would be for me a preferred solution.

    For maybe a more specific example:

    • app activates on email
    • app offers to link an email with specific property proposed by app (this is the app specific property)
    • now in app i would like to find all emails that were linked to this app property (if it is possible to restrict FindItem result that conatins some value in "per item per app" so i can save the property in item custom setting (JS API) instead of creating a new custom property via UpdateItem)

    Anze Javornik

    Friday, March 1, 2013 10:23 PM
  • Hi Anze,

    it is possible, but not recommended. Are you using EWS from the app instead of from a backend service, because of auth issues?

    For your scenario, since you're already using EWS and FindItem, why not just use UpdateItem and set a exchange custom property (named prop), instead of using JS custom props API? Then you know the name of your prop, so it's much easier to search.

    -Andrew

    Wednesday, March 6, 2013 1:30 AM
  • I dont prefer to use UpdateItem with custom property becouse  then i would always need to call GetItem in Office.initialize to get the value of that property. I know it is more or less the same as getting custom properties via js api, but it is atleast using already existing resources instead of creating new ones.

    However i am begining to think, that custom properties on mail are beeing saved in base64 anyway, so i dont think it is possible to actaully filter on them (as it is not always in same format).

    But also to comment on what you say is not recomended: you are recomending that one should not use js api to store custom properties if you want to use it as a filter restriction in FindItem operation? That, in my oppinion, is a lack of the apps for office framework, since js api custom properties can then be accessed only when app is activated on this message and they, in global view, have no meaning...how many times does one circle back to an old email?...they are ideal for custom "flagging" of messages or appointments to be lateron "worked on"...or to maybe find all that have not been "worked on" yet in the app.

    I know this arhitecture probably can not be changed so i will go into ews custom property. But i do think there is a lot more that can be done if even js api would support "FindItem" operation with filter on js api custom properties.

    Thank you for all the anwsers and pointers.


    Anze Javornik

    Thursday, March 7, 2013 1:40 PM