Closed
Bug 360753
Opened 18 years ago
Closed 12 years ago
Add migration support for migrating data from Vista's calendaring application.
Categories
(Calendar :: General, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
1.9
People
(Reporter: matthaeus123, Assigned: Fallen)
Details
Attachments
(1 file, 2 obsolete files)
12.31 KB,
patch
|
mmecca
:
review+
|
Details | Diff | Splinter Review |
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).
Reporter | ||
Comment 1•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
Depends on Bug 360659? (At least on win2k and winxp the migration wizard fails)
Assignee | ||
Comment 4•15 years ago
|
||
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();
Assignee: nobody → philipp
Attachment #247882 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #398918 -
Flags: review?(mschroeder)
Comment 5•15 years ago
|
||
ssitter, can you take the review over? I don't have access to a box with Vista, but maybe you have.
Assignee | ||
Comment 6•15 years ago
|
||
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•12 years ago
|
||
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.
Attachment #398918 -
Flags: review?(mschroeder)
Assignee | ||
Comment 8•12 years ago
|
||
Unbitrotted, but not tested since I'm on mac now. Matthew, could you look into this instead?
Attachment #398918 -
Attachment is obsolete: true
Attachment #592524 -
Flags: review?(matthew.mecca)
Comment 9•12 years ago
|
||
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.
Assignee | ||
Comment 10•12 years ago
|
||
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•12 years ago
|
||
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•12 years ago
|
||
Comment on attachment 592524 [details] [diff] [review] Fix - v3 r=mmecca with aforementioned fixes
Attachment #592524 -
Flags: review?(matthew.mecca) → review+
Updated•12 years ago
|
Whiteboard: [needs updated patch]
Assignee | ||
Comment 13•12 years ago
|
||
Pushed to comm-central changeset 27959b5eab05
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.9
Updated•12 years ago
|
Whiteboard: [needs updated patch]
You need to log in
before you can comment on or make changes to this bug.
Description
•