0

Following this question : Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?

I want to convert from EWS to Graph API ,

in EWS it is under the section below:

https://msdn.microsoft.com/en-us/library/ms527629.aspx

How can I change/ modify mail message flags with REST ?

I saw in beta version is possible somehow...

Part of the REST is here:

https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/mail_api_overview

Any suggestions please ?

VitalyT
  • 1,671
  • 3
  • 21
  • 49
  • Possible duplicate of [Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?](https://stackoverflow.com/questions/49008005/microsoft-graph-api-mail-office-365-is-any-option-create-inbox-message-not-as-d) – Nicolas R Feb 28 '18 at 16:23
  • The flag in the documentation of Graph REST API that you mention are about email flags for follow-up, the ones that you can see in Outlook UI. As already discussed in your other question, those EWS flags are not mentioned in Graph API documentation. – Nicolas R Feb 28 '18 at 16:25
  • Welcome to Stack Overflow! Since you're new here, I recommend reading ["How do I ask a good question?"](https://stackoverflow.com/help/how-to-ask) for some tips. Your question is lacking sufficient detail. It isn't clear what your scenario is or how you doing it today with EWS. – Marc LaFleur Feb 28 '18 at 16:28
  • it stuck all our convert.....Maybe I'll wait for @David Sterling - MSFT answer – VitalyT Feb 28 '18 at 16:30

2 Answers2

1

@Nicolas is correct. Check out Microsoft Graph API mail office 365: Is any option create inbox message NOT as Draft?

In there there is a link to an MSDN article that explains each of the flags, their integer values, etc...

David Sterling - MSFT
  • 580
  • 2
  • 6
  • @ David Sterling , you still didn't answer =[ , Can I do it with Graph API or NOT ? ( I Know that MSDN has an option , but I want use Microsoft REST) – VitalyT Feb 28 '18 at 19:14
  • What is the ID/Value of the property ? Is it . "singleValueExtendedProperties": [ { "id":"Integer {8ECCC264-6880-4EBE-992F-8888D2EEAA1D} Id 0x0E07", "value":"0x00000004" } ] . ????? – VitalyT Mar 01 '18 at 08:12
  • Your using the wrong format. PropTags do not have a namespace. Try "Integer 0x0E07" – David Sterling - MSFT Mar 01 '18 at 22:08
  • Yes ,Thanks It was exactly the reason , but why the "sentDateTime" value is now , and not as I wanted - at specific time example : 2010-03-02T05:21:36Z...I thought that this Flag mark as "sent" with datetime which I configured in the mail body "sentDateTime".. am I right ? – VitalyT Mar 02 '18 at 06:48
  • Basically I want to create a mail not as Draft with specific "sentDateTime"....the Draft issue is working , but the date is not...:( , Am I need create another property ? – VitalyT Mar 02 '18 at 06:50
  • That is a good question. I don't believe through REST you can set the sentTime as that is something that transport stamps when it routes the message. As we chatted about on another thread, MIME would allow you to do this, but REST does not yet support MIME. – David Sterling - MSFT Mar 03 '18 at 20:15
  • For others wanting to know what value you can use for this field. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmsg/a0c52fe2-3014-43a7-942d-f43f6f91c366 – John C Oct 01 '20 at 14:56
  • To set the sent/received time, set these two additional properties in singleValueExtendedProperties. PidTagClientSubmitTime: Id = "SystemTime 0x0039"; PidTagMessageDeliveryTime: Id = "SystemTime 0x0E06". You can pull them from an existing email to see how they should be formatted. – John C Oct 02 '20 at 02:03
0

It's important to remember that while the graph API (for Exchange related foo) looks a lot different than EWS, they actually share a bunch of the same logic underneath and ultimately talk to the exchange Store underneath. What this means is that all of the MAPI goodness (proptags, named props, etc...) can be accessed through the graph API via extended props. Funny bit of trivia - currently the REST API on the server side when it deals with extended props converts them into the EWS internal representation of extended props and calls the server side EWS business logic (in proc) to process them. So not only is it similar, it is exactly the same :)

David Sterling - MSFT
  • 580
  • 2
  • 6