a) meeting request arriving per mail via felamimail_activesync::GetMessage(List)
b) EGw internal meeting requests via calendar_activesync::GetMeetingRequest(s)
EGw backend returns both via INBOX to the client device (b) with negative id's to not conflict with mail uid's)
MettingResponse method in EGw backend calls calendar or fmail depending on id
Unfortunately this is NOT yet completly working:
- could not test with fmail, as I have no permanent internet access
- MeetingResponse method of calendar get never called, in fact client never sends one :-(
- meeting requests via calendar a now displayed double:
a) via calendar_activesync::GetMessage(List), which could be switched off easily
b) via calendar_activesync::GetMeetingRequest(s)
client sends no MeetingResponse on either of them, for a) it displays buttons to accept, tentative or decline, but only calls SendMail and ChangeMessage (without status)
--> do NOT update if you already use AS!!!!!!!!!!!!!!!!!!!!!!!!!!
- adding better support for non strict protocol implementations to improve device compatibility
- fixing an issue of iOS Mail App crashing, due to server reporting changes not requested by client during message fetch.
- adding support for multiple profiles(with different usernames) on one device to one server. (iOS)
- Protocol Version 14.1 is now offered to the client
- general improvements to request handling
Updated egw backend and all plugins to be compatible with latest changes to sync engine.
ATTENTION: profiles need to be recreated on the devices.
- fixed fatal error if participant is no account
- if participant has no email use a pseudo one: noreply-$uid-uid@egroupware.org
- do not add account of calendar as participant (readd it in ChangeMessage)
- use calendar_boupdate::update() instead of ::save() to get notifications
- fixed fatal error call to member function ->format(), if event has an exception
- ChangeMessage now searched contacts for participants and always re-adds resources (everything but accounts, contacts and email)
- some more timezone specific fixes
>>> none of the above is tested, as my iPhone charges no more and battery is now flat :-(
- direction back is implemented (and tested) but not yet used, as storing events is not yet implemented
- timestamps are passed to zpush now in servertime, which it converts internal to UTC times
- recurring event information is now correctly supplied (thought we do NOT yet deal with virtual exceptions!)
--> next step would be storing events synced in from the client
