Tickets :: [#12056] New Kronolith appt w/no invitees sync to iOS, result in greyed item in iOS Calendar

6.0.0-beta1

7/14/25

Summary	New Kronolith appt w/no invitees sync to iOS, result in greyed item in iOS Calendar
Queue	Horde Base
Queue Version	5.0.4
Type	Bug
State	Resolved
Priority	1. Low
Owners	mrubinsk (at) horde (dot) org
Requester	simon (at) simonandkate (dot) net
Created	02/19/2013 (4528 days ago)
Due
Updated	02/27/2013 (4520 days ago)
Assigned	02/20/2013 (4527 days ago)
Resolved	02/21/2013 (4526 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

02/27/2013 12:25:49 AM	simon (at) simonandkate (dot) net	Comment #17	Reply to this comment
There was a bug in the code that detected the AS version number (this feature only available in 12.0 and above). It was fixed earlier today by https://github.com/horde/horde/commit/3a1ab8c10ef89b2720ef4886449d344b4846c3a6 WIth that fix, your iOS device should get the notification pop up and tentative calendar entries. I look forward to checking that out and seeing how it all works... it will be much appreciated. I have AS set to 12.1 in Horde configuration at the moment, so no changes required config side? 4. When I accept a meeting is made in iOS, with ORGANIZER and ATTENDEES intact; 5. The new meeting is sync'ed from the iOS calendar to Horde, loses ORGANIZER information, and appears in Kronolith; This is on purpose due to the issues discussed on your other thread. We can't track ORGANIZER since right now in Kronolith, it is tied to a Horde username - this is obviously not always the case with invites. Noted, thank you. (Still on iOS device) Note also that when the event is added, and after, I never see Accept / Decline / Maybe (which I thought was what triggers the EVENTRESPONSE that you mention?) for these Kronolith events. These appear either by clicking on the calendar attachment to the email, or by viewing the tentative event that is (now correctly) created when the invitation is received. Clicking on the .ics attachment of a Horde meeting request on iOS at the moment only gives me an "Add to Calendar", not Decline / etc.. Is this something that is resolved in the change as well? [Show Quoted Text - 10 lines][Hide Quoted Text] The invitation email is not deleted, I don't see a tentative meeting on receipt of an invitation - the sequence you describe sounds like how my work Exchange system works with ActiveSync rather than Horde. Am I missing the meaning of your explanation, or is my Horde not configured properly to provide this far more integrated calendaring than what I am seeing? WIth current Git code, as of a few hours ago this should all work as expected. Fixes will go out with the next bug fix releases of Horde/ActiveSync and Horde/Core. Excellent, thanks Michael.

02/26/2013 11:37:11 PM	Michael Rubinsky	Comment #16	Reply to this comment
I am not certain whether what you are describing here what happens in Exchange or in Horde. Both. [Show Quoted Text - 12 lines][Hide Quoted Text] In our Horde environment, I do not see a lot of these steps when a meeting invite is processed. Using your scenario of dealing with an invite entirely from an iOS ActiveSync'ed device this is what I see in H5: 1. Another user in our Horde system creates a meeting in Kronolith, with me as attendee; 2. I get an email in my iOS device's Horde inbox with a .ics (two actually, but I understand why now, as this is due to Enhancement 9854); 3. There is nothing in my calendar at this point (either on the iOS device or in Kronolith); There was a bug in the code that detected the AS version number (this feature only available in 12.0 and above). It was fixed earlier today by https://github.com/horde/horde/commit/3a1ab8c10ef89b2720ef4886449d344b4846c3a6 WIth that fix, your iOS device should get the notification pop up and tentative calendar entries. 4. When I accept a meeting is made in iOS, with ORGANIZER and ATTENDEES intact; 5. The new meeting is sync'ed from the iOS calendar to Horde, loses ORGANIZER information, and appears in Kronolith; This is on purpose due to the issues discussed on your other thread. We can't track ORGANIZER since right now in Kronolith, it is tied to a Horde username - this is obviously not always the case with invites. 6. Horde pushes the event out to other ActiveSync devices as an appointment, not a meeting. See above. Though I can probably due something with adding the invitee as the only attended on his/her copy of the event so that it is detected as a meeting. Not sure if this breaks any specs or not, I'll have to investigate. (Still on iOS device) Note also that when the event is added, and after, I never see Accept / Decline / Maybe (which I thought was what triggers the EVENTRESPONSE that you mention?) for these Kronolith events. These appear either by clicking on the calendar attachment to the email, or by viewing the tentative event that is (now correctly) created when the invitation is received. [Show Quoted Text - 9 lines][Hide Quoted Text] Work Exchange meetings I do. All I get is Add to Calendar initially, and then if I want to remove it I can only delete. The invitation email is not deleted, I don't see a tentative meeting on receipt of an invitation - the sequence you describe sounds like how my work Exchange system works with ActiveSync rather than Horde. Am I missing the meaning of your explanation, or is my Horde not configured properly to provide this far more integrated calendaring than what I am seeing? WIth current Git code, as of a few hours ago this should all work as expected. Fixes will go out with the next bug fix releases of Horde/ActiveSync and Horde/Core.

02/26/2013 11:08:50 PM	simon (at) simonandkate (dot) net	Comment #15	Reply to this comment
[Show Quoted Text - 22 lines][Hide Quoted Text] I feel like this could benefit from some more explanation. If an invite is received on, AND is dealt with completely from the iOS device, this should work fine. The flow is something like this: 1. Device receives request. 2. Device creates a tentative event locally on the client's calendar. 3. User deals with invitation. 4. Device sends the EVENTRESPONSE request to the server. 5. Server parses the response, adds the new event to the user's calendar and sends the response email to the organizer. 6. The server then deletes the original request email from the INBOX, which triggers a SYNC on the INBOX. THIS IS THE IMPORTANT STEP. This is what causes the client to delete the tentative request. 7. Device requests SYNC for INBOX and Calendar, which causes new event to be added, and tentative event to be removed, along with the original request email. If you keep the original request email, the tentative event will NEVER be removed. This has nothing to do with the ORGANIZER field. The relevant field here is the (optional) MEETING_STATUS field, which we now always send thanks to iOS's broken behavior. Thank you Michael, very comprehensive responses. Can I ask a couple of questions to clarify this please? I am not certain whether what you are describing here what happens in Exchange or in Horde. In our Horde environment, I do not see a lot of these steps when a meeting invite is processed. Using your scenario of dealing with an invite entirely from an iOS ActiveSync'ed device this is what I see in H5: 1. Another user in our Horde system creates a meeting in Kronolith, with me as attendee; 2. I get an email in my iOS device's Horde inbox with a .ics (two actually, but I understand why now, as this is due to ~~Enhancement 9854~~); 3. There is nothing in my calendar at this point (either on the iOS device or in Kronolith); 4. When I accept a meeting is made in iOS, with ORGANIZER and ATTENDEES intact; 5. The new meeting is sync'ed from the iOS calendar to Horde, loses ORGANIZER information, and appears in Kronolith; 6. Horde pushes the event out to other ActiveSync devices as an appointment, not a meeting. (Still on iOS device) Note also that when the event is added, and after, I never see Accept / Decline / Maybe (which I thought was what triggers the EVENTRESPONSE that you mention?) for these Kronolith events. Work Exchange meetings I do. All I get is Add to Calendar initially, and then if I want to remove it I can only delete. The invitation email is not deleted, I don't see a tentative meeting on receipt of an invitation - the sequence you describe sounds like how my work Exchange system works with ActiveSync rather than Horde. Am I missing the meaning of your explanation, or is my Horde not configured properly to provide this far more integrated calendaring than what I am seeing? Simon

02/26/2013 07:50:53 PM	Michael Rubinsky	Comment #14	Reply to this comment
I feel like this could benefit from some more explanation. If an invite is received on, AND is dealt with completely from the iOS device, this should work fine. The flow is something like this: 1. Device receives request. 2. Device creates a tentative event locally on the client's calendar. 3. User deals with invitation. 4. Device sends the EVENTRESPONSE request to the server. 5. Server parses the response, adds the new event to the user's calendar and sends the response email to the organizer. 6. The server then deletes the original request email from the INBOX, which triggers a SYNC on the INBOX. THIS IS THE IMPORTANT STEP. This is what causes the client to delete the tentative request. 7. Device requests SYNC for INBOX and Calendar, which causes new event to be added, and tentative event to be removed, along with the original request email. If you keep the original request email, the tentative event will NEVER be removed. This has nothing to do with the ORGANIZER field. The relevant field here is the (optional) MEETING_STATUS field, which we now always send thanks to iOS's broken behavior.

02/26/2013 07:04:42 PM	Michael Rubinsky	Comment #13	Reply to this comment
This is a known issue with iOS and Exchange accounts. The problem stems from the fact the iOS automatically adds a tentative meeting to the calendar on the client side. Exchange 2007 automatically adds this tentative reqeuest on the server side as well. What is supposed to happen is that the server updates the tentative entry on the server side when the user responds to the request. For reasons I won't go into here, this is a problem with Horde. The result is that when the user accepts the event from the client, a NEW event is added to kronolith and this event is sync'd to the client. You end up having two events (the original, still tentative event and the new accepted event). I'm still working on coming up with a suitable solution for this.

02/26/2013 11:20:04 AM	simon (at) simonandkate (dot) net	Comment #12	Reply to this comment
Following on from below... The second of the two identical appointments from Kronolith test account, I accepted in Horde (by Accept and Add to Calendar in Imp, instead of in iOS. The resultant Kronolith meeting doesn't seem to indicate that it has an Organizer anywhere that I can see (Dynamic view), I've logged a separate ticket http://bugs.horde.org/ticket/12069 for that. and 15 minutes later had not sync'ed with either iOS device, despite what looks like several sync attempts (I'll check AS logs for details later). An event generated in test account Kronolith and accepted in my account Kronolith now syncs. As per ~~Bug 12069~~ though, it has been put into my Kronolith with no Organizer details, so syncs to iOS as an appointment only. [Show Quoted Text - 10 lines][Hide Quoted Text] Adding a note at the 10 minute stage in the Kronolith event to force an update also doesn't appear to push it through. Onto iPhone and accept the event and then syncs back to Kronolith as a duplicate event, which I expected. This syncs across to the iPad, this time with no Organizer, and no Invitees, i.e. as an appointment. The same event that I Accepted and added to calendar from Kronolith is still not sync'ed to either iOS device, despite showing fine in Kronolith. Feels like if Kronolith were to retain the Organizer this issue would now go away...

02/26/2013 10:44:13 AM	simon (at) simonandkate (dot) net	Comment #11	Reply to this comment
Detailed testing results: First of all the original issue for this bug of meetings syncing between iOS devices on the same ActiveSync account collecting the owner as an invitee is fixed. I'm working on getting logs for the issues described below...

02/26/2013 02:29:14 AM	simon (at) simonandkate (dot) net	Comment #10	Reply to this comment
Following on from below... The second of the two identical appointments from Kronolith test account, I accepted in Horde (by Accept and Add to Calendar in Imp, instead of in iOS. The resultant Kronolith meeting doesn't seem to indicate that it has an Organizer anywhere that I can see (Dynamic view), and 15 minutes later had not sync'ed with either iOS device, despite what looks like several sync attempts (I'll check AS logs for details later). Adding a note at the 10 minute stage in the Kronolith event to force an update also doesn't appear to push it through. Onto iPhone and accept the event and then syncs back to Kronolith as a duplicate event, which I expected. This syncs across to the iPad, this time with no Organizer, and no Invitees, i.e. as an appointment. The same event that I Accepted and added to calendar from Kronolith is still not sync'ed to either iOS device, despite showing fine in Kronolith.

02/26/2013 02:09:47 AM	simon (at) simonandkate (dot) net	Comment #9	Reply to this comment
To run some tests for some funny invite behaviour that I have still been seeing I generated two appointments in Kronolith whilst logged in as a user with no activesync devices. The appointments were identical, just one hour apart. Each had one Invitee - me. I have only 2 activesync devices attached to my account, an iPhone and an iPad. The appointment from my test account to me generated (as expected) two invites in my mail inbox. I accepted on my iPad (iOS 6.1.2) First strangeness - on iOS the appointments showed with TWO attachments, each named event-invitation.ics, and identical in content: BEGIN:VCALENDAR VERSION:2.0 METHOD:REQUEST X-WR-CALNAME:Calendar of server PRODID:-//The Horde Project//Horde iCalendar Library//EN BEGIN:VEVENT DTSTART:20130301T093000Z DTEND:20130301T103000Z DTSTAMP:20130226T000408Z UID:20130226100408.Ng8RuzOzVSD1VgLMYkjQhw5@mail.simonandkate.net CREATED:20130226T000408Z LAST-MODIFIED:20130226T000408Z SUMMARY:Cards test ORGANIZER;CN=Server Wilson:mailto:server@simonandkate.net CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:simon@ simonandkate.net BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Cards test TRIGGER;VALUE=DURATION:-PT15M END:VALARM END:VEVENT END:VCALENDAR Opening the .ics on iPad shows From as Wilson Server server@simonandkate.net (correctly), and No Reply - my address. Selecting Add to Calendar creates an appointment in my Horde sync'ed calendar on iOS. The meeting that is created after I accept (by "Add to Calendar") on an iOS device has the following characteristics: 1. No Accept / Decline / Maybe is shown (either when accepted on iPhone or iPad). It is not seeing it as a Declinable / Acceptable meeting. 2. Because of an issue with the way iPad calendar works, the only way you can get rid of a meeting on iPad is to decline it. As there is no decline button on meetings that come from Kronolith there is no way to do this. (On iPhone, you can Edit, and delete that way.) 3. When the iOS device syncs back to Horde, and down to my other iOS device, it loses From and Invitees, and replicates to the other device as an Appointment, not a Meeting. If I then edit (e.g. add "some notes") in the device that sees it as an appointment not a meeting, that syncs back to Horde ok - but sends an email with 'meeting.ics' from me (originally invitee) to me (invitee), now with ME as the organizer, not the test account. Given that the second iOS device has seen it as an appointment I can see why it thinks I am Organizer, but no idea why it is generating an email. The meeting.ics is: BEGIN:VCALENDAR CALSCALE:GREGORIAN METHOD:REQUEST PRODID:-//Apple Inc.//iPhone 3.0//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT+1000 BEGIN:STANDARD DTSTART:20010101T000000 TZNAME:GMT+10:00 TZOFFSETFROM:+1000 TZOFFSETTO:+1000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN="simon@simonandkate.net";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-AC TION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:simon@simonandkate.net CREATED:20130226T012656Z DESCRIPTION:Notes in here DTEND;TZID=GMT+1000:20130301T213000 DTSTAMP:20130226T013441Z DTSTART;TZID=GMT+1000:20130301T203000 LAST-MODIFIED:20130226T013441Z ORGANIZER;CN="Simon Wilson";EMAIL="simon@simonandkate.net":mailto:simon@ simonandkate.net SEQUENCE:0 SUMMARY:Cards test 2 TRANSP:OPAQUE UID:32303133303232363131323532342E705654346B767969417A435152694C37654A4D 55757731406D61696C2E73696D6F6E616E646B6174652E6E6574 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:Reminder TRIGGER:-PT15M UID:C5994E7F-1103-4C3D-A608-EE9B8FD92B5D X-WR-ALARMUID:C5994E7F-1103-4C3D-A608-EE9B8FD92B5D END:VALARM END:VEVENT END:VCALENDAR This shows in the original iPad with the grey bordered invitation with only me as an invitee, and no Organizer, as per this bug. Removing the invitee from the now-organizer-less meeting completes the breaking of the loop, with both devices now having an organizer-less and invitee-less appointment. We are also having issues with date changes not sync'ing through correctly, but I will do some more digging on that one and post back.

02/21/2013 01:55:25 PM	Michael Rubinsky	State ⇒ Resolved

02/21/2013 09:23:13 AM	simon (at) simonandkate (dot) net	Comment #8	Reply to this comment
It has fixed it perfectly in my iPhone / Kronolith / iPad. Will check across other users over next day or so and report back. Thanks Michael.

02/20/2013 11:36:49 PM	simon (at) simonandkate (dot) net	Comment #7	Reply to this comment
I'll update my git and give it a try, thanks Michael.

02/20/2013 06:11:34 AM	Michael Rubinsky	Comment #6 Assigned to Michael Rubinsky State ⇒ Feedback	Reply to this comment
Can you test these changes? I can't reproduce this on any of my devices, including various versions of iOS. The POOMCAL_MEETINGSTATUS property is what EAS uses to indicate an appointment is a meeting. According to the protocol specs, it is an OPTIONAL property that defaults to an empty value (which indicates it is NOT a meeting). To save bandwidth, the specs recommend not sending optional properties when they would be set to their default values. So much for following the specs...

02/20/2013 06:07:47 AM	Git Commit	Comment #5	Reply to this comment
Changes have been made in Git (master): commit ba28d99e6500abf09733f44d60d123ac17ed82fc Author: Michael J Rubinsky <mrubinsk@horde.org> Date: Wed Feb 20 01:06:04 2013 -0500 Explicitly set the MEETING_NOT_MEETING value. Possible fix for ~~Bug: 12056~~ kronolith/lib/Event.php \| 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) http://git.horde.org/horde-git/-/commit/ba28d99e6500abf09733f44d60d123ac17ed82fc

02/20/2013 06:07:40 AM	Git Commit	Comment #4	Reply to this comment
Changes have been made in Git (master): commit dd9a153290c9ea407f60243624071c1d2c63873f Author: Michael J Rubinsky <mrubinsk@horde.org> Date: Wed Feb 20 01:05:28 2013 -0500 Output an empty POOMCAL_MEETINGSTATUS property. Possible fix for ~~Bug: 12056~~ .../lib/Horde/ActiveSync/Message/Appointment.php \| 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) http://git.horde.org/horde-git/-/commit/dd9a153290c9ea407f60243624071c1d2c63873f

02/19/2013 09:40:52 AM	simon (at) simonandkate (dot) net	Comment #3	Reply to this comment
OK, another update - with two devices on the same Horde account, when you edit the appointment on one device to remove the invitee, which fixes it for that device, that obviously initiates a re-sync. Re-syncing the appointment back through Horde AS to the other device then resets the second device's state to have the originator as an invitee again. So fixing it on one device breaks it on the other one, and vice versa. Generating an invitee-free invitation on one of the iOS devices works fine for THAT device. No invitee is added. But when it syncs through Horde AS to Kronolith and back down to the other device, the organiser is added as an invitee, and the problem re-occurs.

02/19/2013 09:40:28 AM	simon (at) simonandkate (dot) net	Comment #2	Reply to this comment
As an additional piece of information, Exchange ActiveSync accounts synced to the same devices do not exhibit this behaviour when no-invitee appointments are created in e.g. making an appt in Outlook 2010 syncs to iOS without this issue.

02/19/2013 09:39:39 AM	simon (at) simonandkate (dot) net	Comment #1 Priority ⇒ 1. Low State ⇒ Unconfirmed Patch ⇒ No Milestone ⇒ Summary ⇒ New Kronolith appt w/no invitees sync to iOS, result in greyed item in iOS Calendar Type ⇒ Bug Queue ⇒ Horde Base	Reply to this comment
When I generate a new basic appointment with no attendees from Kronolith 4.0.4, Horde 5.0.4, it generates an SQL entry with event_attendees as a:0:{}. All good. That syncs as the following event: 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Commands> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Add> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <ServerEntryId> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <ServerEntryId/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Data> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Timezone> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O qP3//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Timezone/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:DtStamp> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 20130216T000813Z 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:DtStamp/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:StartTime> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 20130214T223000Z 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:StartTime/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Subject> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O PE Test 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Subject/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:UID> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 32303133303231363130303432372E524377323557765975726E5350776A774F524F31725131406D61696C2E73696D6F6E616E646B6174652E6E6574 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:UID/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:EndTime> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 20130214T233000Z 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:EndTime/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Sensitivity> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 0 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Sensitivity/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:BusyStatus> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 2 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:BusyStatus/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Reminder> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 15 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <POOMCAL:Reminder/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:Body> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:Type> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 1 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:Type/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:EstimatedDataSize> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O 0 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:EstimatedDataSize/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <AirSyncBase:Body/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Data/> 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Add/> 2013-02-16T10:08:14+10:00 DEBUG: Updating state during change 2013-02-16T10:08:14+10:00 DEBUG: [1827] O <Commands/> So, still no attendees. All good still. iOS for some reason (love Apple!) tags the event with Invitees: (the originating email account). Because of that, iOS Calendar shows the event as Greyed out with a dashed border. Any event that I create on Kronolith with no specified attendees syncs to iOS with the owner as an attendee, and does not display correctly. If I add any attendee in a new Kronolith appointment, it syncs with that Invitee, and displays fine. Google finds a few people with the problem, but no solution other than remove the invitee, which fixes it. I did find a comment that iOS 6 (I've tried 6 and 6.1, no change) Calendar is more sensitive to "meeting type" in the synced event - is that something that needs to be / can be explicitly added to the event comms from Horde AS where there are no invitees - is that a particular type of meeting / appointment in AS tags? This does not occur in Android - works fine, does not add an invitee, and just displays as an attendee-less appointment. Adding an attendee in Kronolith Android shows Organiser and Attendees. If you go into the event in iOS calendar, and remove the invitee, the event then displays correctly. This syncs back to ActiveSync: 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <Modify> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <ServerEntryId> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </ServerEntryId> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <Data> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:Timezone> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I qP3//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxP///w== 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:Timezone> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:AllDayEvent> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 0 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:AllDayEvent> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:BusyStatus> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 2 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:BusyStatus> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:DtStamp> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 20130216T002532Z 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:DtStamp> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:EndTime> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 20130214T233000Z 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:EndTime> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:Reminder> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 15 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:Reminder> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:Sensitivity> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 0 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:Sensitivity> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:Subject> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I PE Test 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:Subject> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:StartTime> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 20130214T223000Z 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:StartTime> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:UID> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 32303133303231363130303432372E524377323557765975726E5350776A774F524F31725131406D61696C2E73696D6F6E616E646B6174652E6E6574 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:UID> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I <POOMCAL:MeetingStatus> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I 0 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </POOMCAL:MeetingStatus> 2013-02-16T00:25:37+00:00 DEBUG: [1422] I </Data> 2013-02-16T00:25:37+00:00 DEBUG: [1422] Horde_Core_ActiveSync_Driver::_smartStatMessage(@Calendar@, 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net) 2013-02-16T10:25:37+10:00 DEBUG: [1422] Horde_Core_ActiveSync_Driver::changeMessage(@Calendar@, 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net ...) 2013-02-16T10:25:38+10:00 DEBUG: [1422] Horde_Core_ActiveSync_Driver::_smartStatMessage(@Calendar@, 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net) 2013-02-16T10:25:38+10:00 DEBUG: Updating state during change 2013-02-16T10:25:38+10:00 DEBUG: [1422] I </Modify> That then syncs over to another iOS device on this account as this: 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <Modify> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <ServerEntryId> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 20130216100427.RCw25WvYurnSPwjwORO1rQ1@mail.simonandkate.net 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <ServerEntryId/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <Data> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Timezone> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O qP3//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Timezone/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:DtStamp> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 20130216T003032Z 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:DtStamp/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:StartTime> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 20130214T223000Z 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:StartTime/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Subject> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O PE Test 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Subject/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:UID> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 32303133303231363130303432372E524377323557765975726E5350776A774F524F31725131406D61696C2E73696D6F6E616E646B6174652E6E6574 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:UID/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:EndTime> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 20130214T233000Z 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:EndTime/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Sensitivity> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 0 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Sensitivity/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:BusyStatus> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 2 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:BusyStatus/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Reminder> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 15 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <POOMCAL:Reminder/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:Body> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:Type> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 1 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:Type/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:EstimatedDataSize> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O 0 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:EstimatedDataSize/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <AirSyncBase:Body/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <Data/> 2013-02-16T10:30:33+10:00 DEBUG: [14214] O <Modify/> But the other iOS device still shows the owner as an invitee, and displays incorrectly. Any suggestions? This is affecting my wife's calendar particularly, as I have just migrated all of her content into the new Horde 5 by import / export in Kronolith, so it's pushed ALL of her appointments out to iOS as greyed out...