Hi, I am trying to push Calendarserver 5.x into Ubuntu Trusty (due to release on April 17). While testing I have found two issues. Any help to have them resolved would be great. 1. Earlier, for XML entries, I have distributed a sample accounts.xml file with the guid same as the uid (for ex. admin, test, etc.). However, with calendarserver 5.x, I can see that these kind of guids are considered invalid. Now, I figured out that the valid guid can be generated from the function 'str(uuid4()).upper()'. But how do I migrate the data from older guids to the newer guids? Is there any database update command that I can run? 2. Next, I have observed that for calendarserver 5.x, tasks are disabled when I access the calendar from Thunderbird. I am not sure if tasks have been disabled upstream or whether there is some compatibility issue with Thunderbird & Apple calendarserver. Any help in resolving these issues would be of great help as there are only a couple of days left for the Ubuntu LTS release. Regards, Rahul.
On Apr 13, 2014, at 9:27 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
Hi, I am trying to push Calendarserver 5.x into Ubuntu Trusty (due to release on April 17). While testing I have found two issues. Any help to have them resolved would be great.
1. Earlier, for XML entries, I have distributed a sample accounts.xml file with the guid same as the uid (for ex. admin, test, etc.). However, with calendarserver 5.x, I can see that these kind of guids are considered invalid. Now, I figured out that the valid guid can be generated from the function 'str(uuid4()).upper()'. But how do I migrate the data from older guids to the newer guids? Is there any database update command that I can run?
The behavior you’re describing is not in a 5.x release, it’s only on trunk right now. We’ll sort out a way to upgrade data in the 6.x release.
2. Next, I have observed that for calendarserver 5.x, tasks are disabled when I access the calendar from Thunderbird. I am not sure if tasks have been disabled upstream or whether there is some compatibility issue with Thunderbird & Apple calendarserver.
VTODOs (tasks) have been split out into separate calendar collections, so you probably just need to add the “tasks” calendar to your client as well.
Any help in resolving these issues would be of great help as there are only a couple of days left for the Ubuntu LTS release.
Regards, Rahul. _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
On Monday 14 April 2014 10:20 PM, Morgen Sagen wrote:
On Apr 13, 2014, at 9:27 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
Hi, I am trying to push Calendarserver 5.x into Ubuntu Trusty (due to release on April 17). While testing I have found two issues. Any help to have them resolved would be great.
1. Earlier, for XML entries, I have distributed a sample accounts.xml file with the guid same as the uid (for ex. admin, test, etc.). However, with calendarserver 5.x, I can see that these kind of guids are considered invalid. Now, I figured out that the valid guid can be generated from the function 'str(uuid4()).upper()'. But how do I migrate the data from older guids to the newer guids? Is there any database update command that I can run?
The behavior you’re describing is not in a 5.x release, it’s only on trunk right now. We’ll sort out a way to upgrade data in the 6.x release. Ok. So, is there any workaround (easy or difficult) for users who are now using xml directory with invalid guids? I mean as soon as they upgrade to 5.x from 3.x or 2.x, all their data would no longer be accessible. What can be done to fix this?
One workaround that I could think of is to comment out the line "assert len(name) > 4, ..." in twistedcaldav/directory/common.py while compiling but I am not sure if it is such a good idea. Kindly advise on what is the best approach.
2. Next, I have observed that for calendarserver 5.x, tasks are disabled when I access the calendar from Thunderbird. I am not sure if tasks have been disabled upstream or whether there is some compatibility issue with Thunderbird & Apple calendarserver.
VTODOs (tasks) have been split out into separate calendar collections, so you probably just need to add the “tasks” calendar to your client as well.
What would the url be like? For calendar, I have been using http://calenarserver:8008/calendars/users/<user>/calendar/.
Sorry, I didn’t explain the situation clearly enough: XML files with <guid> elements containing values (such as “admin”) which are not in GUID form are still allowed in the 5.x codebase. It will not become an issue until 6.x in which the code is stricter about GUID values, at which point we will have an upgrade solution. On Apr 14, 2014, at 10:48 AM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
On Monday 14 April 2014 10:20 PM, Morgen Sagen wrote:
On Apr 13, 2014, at 9:27 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
Hi, I am trying to push Calendarserver 5.x into Ubuntu Trusty (due to release on April 17). While testing I have found two issues. Any help to have them resolved would be great.
1. Earlier, for XML entries, I have distributed a sample accounts.xml file with the guid same as the uid (for ex. admin, test, etc.). However, with calendarserver 5.x, I can see that these kind of guids are considered invalid. Now, I figured out that the valid guid can be generated from the function 'str(uuid4()).upper()'. But how do I migrate the data from older guids to the newer guids? Is there any database update command that I can run?
The behavior you’re describing is not in a 5.x release, it’s only on trunk right now. We’ll sort out a way to upgrade data in the 6.x release. Ok. So, is there any workaround (easy or difficult) for users who are now using xml directory with invalid guids? I mean as soon as they upgrade to 5.x from 3.x or 2.x, all their data would no longer be accessible. What can be done to fix this?
One workaround that I could think of is to comment out the line "assert len(name) > 4, ..." in twistedcaldav/directory/common.py while compiling but I am not sure if it is such a good idea.
Kindly advise on what is the best approach.
2. Next, I have observed that for calendarserver 5.x, tasks are disabled when I access the calendar from Thunderbird. I am not sure if tasks have been disabled upstream or whether there is some compatibility issue with Thunderbird & Apple calendarserver.
VTODOs (tasks) have been split out into separate calendar collections, so you probably just need to add the “tasks” calendar to your client as well.
What would the url be like? For calendar, I have been using http://calenarserver:8008/calendars/users/<user>/calendar/.
… and to clarify even further than that, please use a release from: http://trac.calendarserver.org/browser/CalendarServer/tags/release and not trunk: http://trac.calendarserver.org/browser/CalendarServer/trunk Cheers, -dre On Apr 14, 2014, at 10:55 AM, Morgen Sagen <sagen@apple.com> wrote:
Sorry, I didn’t explain the situation clearly enough: XML files with <guid> elements containing values (such as “admin”) which are not in GUID form are still allowed in the 5.x codebase. It will not become an issue until 6.x in which the code is stricter about GUID values, at which point we will have an upgrade solution.
On Apr 14, 2014, at 10:48 AM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
On Monday 14 April 2014 10:20 PM, Morgen Sagen wrote:
On Apr 13, 2014, at 9:27 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
Hi, I am trying to push Calendarserver 5.x into Ubuntu Trusty (due to release on April 17). While testing I have found two issues. Any help to have them resolved would be great.
1. Earlier, for XML entries, I have distributed a sample accounts.xml file with the guid same as the uid (for ex. admin, test, etc.). However, with calendarserver 5.x, I can see that these kind of guids are considered invalid. Now, I figured out that the valid guid can be generated from the function 'str(uuid4()).upper()'. But how do I migrate the data from older guids to the newer guids? Is there any database update command that I can run?
The behavior you’re describing is not in a 5.x release, it’s only on trunk right now. We’ll sort out a way to upgrade data in the 6.x release. Ok. So, is there any workaround (easy or difficult) for users who are now using xml directory with invalid guids? I mean as soon as they upgrade to 5.x from 3.x or 2.x, all their data would no longer be accessible. What can be done to fix this?
One workaround that I could think of is to comment out the line "assert len(name) > 4, ..." in twistedcaldav/directory/common.py while compiling but I am not sure if it is such a good idea.
Kindly advise on what is the best approach.
2. Next, I have observed that for calendarserver 5.x, tasks are disabled when I access the calendar from Thunderbird. I am not sure if tasks have been disabled upstream or whether there is some compatibility issue with Thunderbird & Apple calendarserver.
VTODOs (tasks) have been split out into separate calendar collections, so you probably just need to add the “tasks” calendar to your client as well.
What would the url be like? For calendar, I have been using http://calenarserver:8008/calendars/users/<user>/calendar/.
_______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
On Monday 14 April 2014 11:25 PM, Morgen Sagen wrote:
Sorry, I didn’t explain the situation clearly enough: XML files with <guid> elements containing values (such as “admin”) which are not in GUID form are *still allowed* in the 5.x codebase. It will not become an issue until *6.x* in which the code is stricter about GUID values, at which point we will have an upgrade solution. Ok. So, I believe I can go ahead and comment the line where we are doing:
assert len(name) > 4, "Directory record has an invalid GUID: %r" % ( name,) Any idea on what could this break? if I don't comment out this line, xml records with guid lesser than 5 characters such as "test" are considered invalid. Also, could you tell me the direct url to be added for accessing tasks? For ex. for calendar I add http://<calendarserver>:8008/calendars/users/<user>/calendar/? Thanks, Rahul.
On Monday 14 April 2014 11:32 PM, Rahul Amaram wrote:
Any idea on what could this break? if I don't comment out this line, xml records with guid lesser than 5 characters such as "test" are considered invalid.
I have found the solution for XML guids issue. I have realized that I have added the invalid form guid entries in only a recent release, which I believe has not been pushed to any major distribution. So, I can have this fixed.
Also, could you tell me the direct url to be added for accessing tasks? For ex. for calendar I add http://<calendarserver>:8008/calendars/users/<user>/calendar/?
Kindly let me know the URL with which I can access the tasks.
On Apr 15, 2014, at 12:31 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
On Monday 14 April 2014 11:32 PM, Rahul Amaram wrote:
Any idea on what could this break? if I don't comment out this line, xml records with guid lesser than 5 characters such as "test" are considered invalid.
I have found the solution for XML guids issue. I have realized that I have added the invalid form guid entries in only a recent release, which I believe has not been pushed to any major distribution. So, I can have this fixed.
Also, could you tell me the direct url to be added for accessing tasks? For ex. for calendar I add http://<calendarserver>:8008/calendars/users/<user>/calendar/?
Kindly let me know the URL with which I can access the tasks.
/calendars/users/<user>/tasks/
On Apr 15, 2014, at 1:39 PM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
On Wednesday 16 April 2014 02:07 AM, Rahul Amaram wrote:
Kindly let me know the URL with which I can access the tasks.
/calendars/users/<user>/tasks/
The Tasks URL returns 404 not found.
From twistedcaldav/stdconfig.py, here's the comment for the RestrictCalendarsToOneComponentType plist setting:
# Only allow calendars to be created with a single component type # If this is on, it will also trigger an upgrade behavior that will # split existing calendars into multiples based on component type. # If on, it will also cause new accounts to provision with separate # calendars for events and tasks. In other words, a 404 might be expected depending on the above setting, and when your account was provisioned relative to any upgrades or changes to this setting. -dre
Also, are tasks migrated along with the events when moving from files to db storage? _______________________________________________ calendarserver-dev mailing list calendarserver-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-dev
On Wednesday 16 April 2014 02:14 AM, Andre LaBranche wrote:
From twistedcaldav/stdconfig.py, here's the comment for the RestrictCalendarsToOneComponentType plist setting:
# Only allow calendars to be created with a single component type # If this is on, it will also trigger an upgrade behavior that will # split existing calendars into multiples based on component type. # If on, it will also cause new accounts to provision with separate # calendars for events and tasks.
In other words, a 404 might be expected depending on the above setting, and when your account was provisioned relative to any upgrades or changes to this setting.
-dre
Awesome!!! This was what I was looking for :). One last query. So , in versions prior to calendarserver 5.x, the guid used to be automatically generated for XML records which did not have guid. But since 5.x, this auto-generation is removed and as I understand, users are supposed to explicitly mention the guid. So, if they want to have access to the migrated data, they should know what auto-generated guid was being used earlier. I have written a script which will tell them this if they give the realm, recordType and uid. However, I am wondering if there is already a solution for this provided out-of-the-box or a more elegant way of doing it. Thanks a ton for all the prompt responses. Regards, Rahul.
On Wednesday 16 April 2014 03:00 AM, Rahul Amaram wrote:
One last query. So , in versions prior to calendarserver 5.x, the guid used to be automatically generated for XML records which did not have guid. But since 5.x, this auto-generation is removed and as I understand, users are supposed to explicitly mention the guid. So, if they want to have access to the migrated data, they should know what auto-generated guid was being used earlier. I have written a script which will tell them this if they give the realm, recordType and uid. However, I am wondering if there is already a solution for this provided out-of-the-box or a more elegant way of doing it.
Thanks a ton for all the prompt responses.
I have pushed calendarserver 5.2 into Debian Unstable and requested Ubuntu release team to include it in Ubuntu Trusty. Let us hope for the best :).
On Wednesday 16 April 2014 03:56 AM, Rahul Amaram wrote:
On Wednesday 16 April 2014 03:00 AM, Rahul Amaram wrote:
One last query. So , in versions prior to calendarserver 5.x, the guid used to be automatically generated for XML records which did not have guid. But since 5.x, this auto-generation is removed and as I understand, users are supposed to explicitly mention the guid. So, if they want to have access to the migrated data, they should know what auto-generated guid was being used earlier. I have written a script which will tell them this if they give the realm, recordType and uid. However, I am wondering if there is already a solution for this provided out-of-the-box or a more elegant way of doing it.
Thanks a ton for all the prompt responses.
I have pushed calendarserver 5.2 into Debian Unstable and requested Ubuntu release team to include it in Ubuntu Trusty. Let us hope for the best :).
Great news guys. calendarserver 5.2 seems to have made it into Ubuntu Trusty :).
On Apr 16, 2014, at 10:01 AM, Rahul Amaram <amaramrahul@users.sourceforge.net> wrote:
On Wednesday 16 April 2014 03:56 AM, Rahul Amaram wrote:
On Wednesday 16 April 2014 03:00 AM, Rahul Amaram wrote:
One last query. So , in versions prior to calendarserver 5.x, the guid used to be automatically generated for XML records which did not have guid. But since 5.x, this auto-generation is removed and as I understand, users are supposed to explicitly mention the guid. So, if they want to have access to the migrated data, they should know what auto-generated guid was being used earlier. I have written a script which will tell them this if they give the realm, recordType and uid. However, I am wondering if there is already a solution for this provided out-of-the-box or a more elegant way of doing it.
Thanks a ton for all the prompt responses.
I have pushed calendarserver 5.2 into Debian Unstable and requested Ubuntu release team to include it in Ubuntu Trusty. Let us hope for the best :).
Great news guys. calendarserver 5.2 seems to have made it into Ubuntu Trusty :).
Nice! Thanks for your work on this package :) I will try to take it for a spin soon... -dre
participants (3)
-
Andre LaBranche
-
Morgen Sagen
-
Rahul Amaram