360753 - Add migration support for migrating data from Vista's calendaring application.

Status: RESOLVED FIXED

(Calendar :: General, enhancement)

Description

[matthaeus123]

Migration support is needed for Windows Vista's integrated calendaring application "Windows Calendar". Support should be implemented into the Migration Wizard.

All of the calendar files are saved as ".ics". They are all saved in the same folder depending on the profile.

C:\Users\"profile name"\AppData\Local\Microsoft\Windows Calendar\Calendars

- the text "profile name" represents the name of the profile, which will change depending on the user.

This directory has only been confirmed on Microsoft Vista RC1 (Build 5600).

Comment 1

[matthaeus123]

I know that it has not been tested on the final version of Microsoft Windows Vista, but the paths probably will not change from RC1 to RTM.

Comment 2

[Joey Minta]

Attachment: untested patch

I had to eyeball this patch, since I don't have Vista.  The checking part at least runs without errors, so I don't think it'll break anything, but I can't promise it'll pick up data from Vista calendars.  If someone could test that, I'd appreciate it.

Comment 3

[Stefan Sitter [:ssitter]]

Depends on Bug 360659? (At least on win2k and winxp the migration wizard fails)

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v2

This patch should take care. I have Vista installed, but no development environment installed, so I can't test if getting the path works correctly. What I did for testing is to initialize a file object with /media/disk/Users/... instead of getting it from the directory service. From there it works fine for me.

I would appreciate if someone with vista could test this patch. to open the migrator on an existing profile, call this from the error console:

window.parent.opener.gDataMigrator.checkAndMigrate();

Comment 5

[Martin Schröder [:mschroeder]]

ssitter, can you take the review over? I don't have access to a box with Vista, but maybe you have.

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

As I've just noticed, please pretend there is a try-catch block around the get() for LocalAppData, as this throws on Linux.

Comment 7

[Martin Schröder [:mschroeder]]

Comment on attachment 398918 [details] [diff] [review]
Fix - v2

I won't be able to review this. Also, this patch has been lying around for a long time and may be bitrotted.

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v3

Unbitrotted, but not tested since I'm on mac now. Matthew, could you look into this instead?

Comment 9

[Matthew Mecca [:mmecca]]

Comment on attachment 592524 [details] [diff] [review]
Fix - v3

Review of attachment 592524 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/base/content/dialogs/calendar-migration-dialog.js
@@ +548,5 @@
> +        if (!settingsxml || !settingsxml.exists()) {
> +            // No Settings.xml, maybe Windows Calendar was never started?
> +            return [];
> +        }
> +        let settingsXmlUri = gDataMigrator.ioService.newFileURI(settingsxml);

This throws "Error: gDataMigrator.ioService is undefined". I see gDataMigrator has a mIoService property, but it doesn't seem to be initialized or referenced anywhere. Maybe cal.getIOService().newFileURI would work here, I don't have a dev environment set up on a Vista machine at the moment so I didn't try it.

Comment 10

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Indeed, the mIOService should have been removed some time in the past, the patches age is to be blamed :-) The better way would be to use Services.jsm and then Services.io.newFileURI.

Comment 11

[Matthew Mecca [:mmecca]]

With the ioService part fixed the import still fails with multiple 

Error: [calStorageCalendar] Message: Error selecting events with recurrence!
Exception: TypeError: this.mSelectEventsWithRecurrence is undefined
...

and

Error: [calStorageCalendar] Message: prepareStatement exception
Exception: TypeError: aStmt is undefined
...

It appears that the storage calendar isn't initialized fully because the id hasn't been set before the items are added.

Adding "calendar.id = cal.getUUID();" after the calendar is created in the importICSToStorage function here:
http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-migration-dialog.js#542
fixed this and the import worked fine.

Comment 12

[Matthew Mecca [:mmecca]]

Comment on attachment 592524 [details] [diff] [review]
Fix - v3

r=mmecca with aforementioned fixes

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to comm-central changeset 27959b5eab05