Outlook, EAS - "mileage" MAPI field
I found this old topic, where the OP had the same problem I also just encountered -
We have a very branch-specific software that pre-fills new emails with recipient, a template body text, attachments and other data with Outlook 2016, so the user in most cases only has to press the “send” button.
The software keeps track of the sent messages by writing an ID in the “mileage” (or “Reisekilometer” in german) field and puts it into its internal DB when it comes across that ID once the message has been sent.
This is no problem for MAPI or EWS connections, since those protocols seem to support all MAPI properties, but with EAS - as used by z-push - this property doesn’t get synced. See also this microsoft page, specifically:
EWS exposes many properties that are not available through Exchange ActiveSync that enable you to achieve a rich Outlook experience. For example, only EWS exposes the following properties on tasks: Actual Work, Assigned Time, Billing Information, Companies, IsTeamTask, Mileage, and Owner, as well as Task delegation fields.
Could this be done by KOE, maybe?
Anyway, just wanted to let you know there is still interest in getting other MAPI (non EAS) properties to the server. It seems some 3rd party software likes to place additional data in weird places…
we have discussed your request internally and do see a technical possibility to do this within KOE.
this is a very limited use case and will probably not be to the benefit of many users.
If you are really interested in this feature I recommend to get in touch with our sales team so we can discuss the possibilities of doing some custom development for you in this regard.
Alright, thank you for looking into it, good to know it would be possible!
I asked the other software vendor if they have a solution for that kind of situation - and indeed, they can put the ID into a different field (they just append it to the name of the recipient). That will work regardless of what mail system we use, but is somewhat visible to the recipient. Still, good enough in this case.
So from my standpoint the problem is solved, as we can resume using both Kopano and the other program without any broken features.