* VTIMEZONE blocks must be sent in our ics files for meeting
invitations that are recurring, as the originator's time zone
is critical in making attendee's calendars accurate
* Created a utility to convert TimeZone to VTIMEZONE data; the
utility successfully generates data (including recurrence rules)
for the entire tzinfo database (the source of TimeZone).
* Updated our ics files to include VTIMEZONE when appropriate and
send DTSTART/DTEND in local time in that case
* Wrote some unit tests, but more are needed
Change-Id: Iccbdd00cd3b2be2da058b344ebacd17ed6fb0e3d
* My Calendar observer registration code was storing the wrong id
in the hash map. Because of this, the code could be called again
and again, generating lots of extraneous queries and generally
creating a lot of havoc, including ANR's
Bug: 2450322
Change-Id: I03db8156ee99a0c7243a9188558dffc6a843a65a
We've observed that the secure.emailsrvr.com email server returns an excess
FETCH response for a UID FETCH command. Excess responses don't have the
UID field, even though we request, which led the response parser to crash.
This patch fixes it by making the parser ignore response lines that don't
have UID.
Bug: 2441065
* Syncs in progress weren't checking the getSyncAutomatically setting in
the account; therefore, a long sync would continue running even though the
user unchecked the "Sync Calendar/Contacts" box in the settings
* Make the adapters check the flag each time through its sync loop (which
is currently 5 items); this should cause in-progress syncs to stop within
a few seconds
Bug: 2185319
Change-Id: Ie181f6de4219ecf27fff58ed59a277ae285622c5
* We weren't retrying the initial account sync after policies are
successfully enabled. This results in failure to sync, as we
go right into a ping loop.
* Retry account sync after provisioning is first successful
Bug: 2474554
Change-Id: I20165a5941626b690710f82088d8d861679084b2
On the first boot after upgrade from Eclair, enable calendar sync for all the
existing Exchange accounts, if any, and show notification.
Note on this version, nothing happens when you click on the "Calendar added"
notification. We're waiting for an API (action or something) to launch
calendar.
Bug 2428718
* Fill in this missing piece of meeting related functionality.
* We keep track of the last synced attendee status in the newly
created syncAdapterData event column
* When this changes, we (in addition to syncing up the change)
send an email to the organizer (unless we're the organizer, of
course)
Bug: 2467153
Change-Id: I6332fb6d0839e33d4c54bd4358ee0f154bff6612
* In #2469254, uploaded new events were rejected because the time zone was
sent after dates; this doesn't matter to Exchange 2007, but it apparently
does to Exchange 2003
* Also, I noticed that upsync was upsyncing all new events, regardless of
whether the event belonged to the Calendar being synced! So this is
fixed as well.
Bug: 2469254
Change-Id: I651d591cf26e00b414f6da19897fddcdb840c97c
* When the user selects accept/decline/tentative in MessageView, we now send
an email to the organizer, with an iCalendar attachment indicating the reply
* Added a unit test for the reply case, but more tests to be added to handle
other circumstances
Change-Id: Iff799d88a92b6546735bf4965b22febf3a82b56f
* Was checking for any meeting related email
* Changed to look specifically for incoming meeting invites
* Bug noticed during debugging
Change-Id: I8f43d7a506939dbfc0504f96b249e5c17107bf47
* Wrote utility to create an ics file (iCalendar) based on a
CalendarProvider Event. This is a good first pass, but we need
to consider whether to include alarms, etc.
* Use aforementioned utility and new convenience method to send
meeting invitations to attendees of newly created meetings (events)
when they are uploaded to the server via the CalendarSyncAdapter
* Overall, attempted to modify existing provider and rfc822 output
code as little as possible. Rfc822Output is actually very limited
in its capabilities and should be made more robust in future
Change-Id: Ie20b9137df56dc414de6737d05fa40ec9cdf47e0
* We can use this for meeting request information which will start out with
one or two pieces of information, but might grow in the future.
* Binary compatible with Address.pack() format, so we can eventually
combine code.
