Make Google Calendar Stop Automatically Adding Events

From today's New York Times a good question and answer:

How do I make Google Calendar stop automatically adding events mentioned in Gmail?

Certainly it is possible but heed this warning: "Google warns that doing so removes all the past events added from Gmail."

This is totally bush-league!

Google should be ashamed they foisted that kind of slipshod capability on the public.

@Apple OS X iCalendar: “Travel Time” and Migration to @MSFTExchange or @Office365

Spoiler alert: We've been skunk-working a project for migrating Apple iCalendar to Microsoft Exchange and we've come up with a few things we should blog on.

First, read OS X Mavericks: Using “Travel Time” in Calendar.

Travel Time is a very cool feature and I remember sites asking for it when I was on Meeting Maker way back in the prior century.  

Apple implemented it.

The question becomes: what do you do with Travel Time in OS X Server El Capitan when you migrate calendars to Microsoft Exchange?

For appointments, it's very simple: you insert another appointment adjacent to the one with travel time and set it up with a reminder at the time you need to leave.

For meetings you do the same thing -- but as nearly as we can tell Travel Time only applies to the Organizer of the meeting (what Apple refers to as the CHAIR) not the attendees.  This makes it really simple for us, but as always, we put this out in the blogosphere for comments and for power users to say "not so fast!".

So what looks like this on the Macintosh for Janis Joplin:

Will become this on Office 365:

There's a couple of  things here that we're working with:

• Defining the Travel Time Free-Busy status on Exchange as "OOF" or "Away" as Office 365 now refers to it.  Somehow that seems more true to the intended spirit of the feature than "busy."  And "Free" is just right out.
• Since Travel Time is not defined with an actual name in the Apple iCalendar data structures we're going to keep all the times singular.  In English "3 hour travel time" makes more sense than "3 hours travel time."  (Those of a certain age will remember the immortal line: "A 3 hour tour....a 3 hour tour.")
• Reminder will kick off for Travel Time at the start of Travel Time.

One of the clever things about the Macintosh calendar user interface is that in monthly view the travel time does not appear  (heck, maybe it's a bug and no one's fixed it yet and everyone's really complaining about it -- but I think it keeps down on visual clutter).

So here's what a monthly view looks like for this event on the Macintosh:

And here's what it will look like in Office 365.  

A little advance training on your users will do wonders. 

#MDaemon to @Office365 International Migrations - Character Sets Deuxième partie

FOLDER NAMES!

Dagnabbit -- we forgot folder names in UTF-8.

This was one where the file system was replacing the “Tâches“ with “T&AOI-ches”

So we updated the code to handle it,

The latest build,  mCalreader_v4.1.17 addresses this issue.

To be safe, I recommend deleting these four lines in the XML config file and then re-running the code’s setup/configuration if you are already in a migration:

  

NB: Don’t worry if the config values look odd.  We save the localization values in “HTML-Friendly” format, so the “&” becomes “ampersand;”  (except in Blogger it gets interpreted into something not plain text)

For the curious, this is the table so you can handle your own cases:

           

Note that this is also a problem in email migration:  http://www.linux-france.org/prj/imapsync_list/msg01976.html

#MDaemon to #Office365 International Migrations - Character Sets

Let's say that you are happily migrating calendar data from MDaemon to Microsoft Office 365 or Exchange and you're someplace other than the USA with various accented characters.

Most times we've had no problem out of the box with the MDaemon calendar migration (and we see many migrations in Europe).

But one French site reported "é"s (as well as every other accented character) coming out incorrectly.  For example:

This is a classic symptom of the original character set being UTF-8 and that not meshing with the default Windows Western European character set.  Note that the e-acute in "Migré" was inserted under program control as a string already in the Windows character set.

No worries.

Modify the _Config_mCalReader.xml file to contain the following line:

Run your insertion.  It'll come out correctly in Exchange: