Open controlcde opened 6 years ago
Hi,
This error is “expected”. It used to be possible to store multiple calendar component types (eg VTODO, VEVENT) in a single collection. Sometime since 3.2, CalendarServer became more strict, and now does not let you mix component types in a single collection by default. You should put VTODOs to a collection that is configured to store only VTODOs.
Or, you can change the server config to relax this constraint; check https://github.com/apple/ccs-calendarserver/blob/a5b19e00a25f16ff2d56f899228bc6432b8b8828/conf/caldavd-stdconfig.plist#L1041
Hi,
--On June 19, 2018 at 9:14:57 AM -0700 Andre LaBranche notifications@github.com wrote:
This error is “expected”. It used to be possible to store multiple calendar component types (eg VTODO, VEVENT) in a single collection. Sometime since 3.2, CalendarServer became more strict, and now does not let you mix component types in a single collection by default. You should put VTODOs to a collection that is configured to store only VTODOs.
Or, you can change the server config to relax this constraint; check https://github.com/apple/ccs-calendarserver/blob/a5b19e00a25f16ff2d56f899 228bc6432b8b8828/conf/caldavd-stdconfig.plist#L1041
Actually I think the issue here is attempting to store the "private" X- components via PUT.
CalendarServer stores iCalendar data internally with special "private" components that are used to capture additional metadata such as per-user properties in events in shared calendars. Those private components are never exposed to clients (when a client does a GET we process the "raw" calendar data to remove/merge the private metadata components as needed). The server will reject any attempt to store calendar data with those components if received over HTTP (or some other channel like email invitations).
So, it is never OK to take "raw" calendar data from CalendarServer's files (for file-system based data) or directly from postgres, and PUT those back via HTTP.
So your options are:
1) For each event, GET it from the old server and PUT it to the new one (HTTP-based solution). 2) Copy the actual file system datastore from the old server to the new one and let CalendarServer migrate that to postgres itself.
We also have an "export" tool that will dump all the events in one calendar into a single iCalendar file that can then be used for an import operation using a client configured to use the new server. That is a manual process so it only makes sense if you have a few users/calendars.
-- Cyrus Daboo
I will sync from calendarserver 3.2 to a new one. I use the great software vdirsyncer. When I want to sync my todos the new server through out the following error:
And for example one .ics file contains:
and a second one:
Are the .ics files are corrupt or is this a bug?