July 2008 - calendarserver-dev - lists.macosforge.org

[CalendarServer] #299: The twisted branch dav-acl-1608-4 no longer exists
by CalendarServer 14 Aug '08

14 Aug '08

#299: The twisted branch dav-acl-1608-4 no longer exists ---------------------------------------+------------------------------------ Reporter: illtud.daniel(a)llgc.org.uk | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: Component: Calendar Server | Version: Severity: Serious | Keywords: ---------------------------------------+------------------------------------ The run script tries to dl a branch of twisted: svn_uri="${proto}://svn.twistedmatrix.com/svn/Twisted/branches/dav- acl-1608-4"; That branch no longer exists in the twistedmatrix repository. I think maybe the dav-acl-1608-* branches have been merged into the trunk. I'm setting it to blocker because without this fix you can't build CalendarServer -- Ticket URL: <https://trac.calendarserver.org/ticket/299> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 1

'component' parameter in content-type
by Helge Heß 14 Aug '08

14 Aug '08

Hi, small wish: could iCalServer set the 'component' property in resource content-types? This would make in-place filtering of PROPFIND results easier: http://www.faqs.org/rfcs/rfc2447.html Sample: Content-Type:text/calendar; charset=UTF-8; component=vevent Thanks, Helge -- Helge Hess http://helgehess.eu/

2 1

[CalendarServer] #298: PROPFIND on existing collection returns 404
by CalendarServer 14 Aug '08

14 Aug '08

#298: PROPFIND on existing collection returns 404 -------------------------------+-------------------------------------------- Reporter: helge(a)zideone.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: trunk Severity: Other | Keywords: -------------------------------+-------------------------------------------- I'm getting a weird 404 as a response to a PROPFIND. The strange thing is that a PROPFIND from Cadaver works. So I suppose one of the requested properties which triggers the 404? But why is the whole result reported 404 then? Something is fishy ;-) Its trunk from today. ---snip--- 192.168.0.125 - - [25/Jul/2008:14:27:45 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 401 141 "-" "ZideOne/0.8.3 neon/0.27.2" [232.4 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:45 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/0.27.2" [116.5 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:46 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/0.27.2" [29.3 ms] 192.168.0.111 - - [25/Jul/2008:14:29:27 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 401 141 "-" "cadaver/0.23.2 neon/0.27.2" [51.7 ms] 192.168.0.111 - user01 [25/Jul/2008:14:29:33 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 207 3062 "-" "cadaver/0.23.2 neon/0.27.2" [118.1 ms] ---snap--- -- Ticket URL: <https://trac.calendarserver.org/ticket/298> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 4

[CalendarServer] #287: Breaks with python-vobject 0.6.6
by CalendarServer 14 Aug '08

14 Aug '08

#287: Breaks with python-vobject 0.6.6 -----------------------------+---------------------------------------------- Reporter: agx(a)sigxcpu.org | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: -----------------------------+---------------------------------------------- When replacing python-vobject 0.6.0 by 0.6.6 one gets and exception when trying to add a new appointment. Exception is attached to this report. This is calendarserver 1.2 -- Ticket URL: <http://trac.calendarserver.org/ticket/287> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 10

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 31 Jul '08

31 Jul '08

#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------+--------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: sagen(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: 2.x Component: Calendar Server | Version: Severity: Serious | Resolution: Keywords: | ------------------------------------+--------------------------------------- Comment (by wsanchez(a)apple.com) Right, the bug is that we handling `RECURRANCE_MAX` correctly. Sorry the milestone isn't satisfactory for you, but the reason its not at an earlier milestone is that desktop clients like iCal tend to do this sort of query based on their own local cache of everything in your calendar and not via CalDAV. Web clients which don't cache data are going to have to hit the server, but at the moment the number of CalDAV clients I'm aware of is rather low, and are all desktop clients. iCal also happens to be a bit of a priority for us at Apple, and we don't have a lot of incoming patches from outside of the Apple team in this area yet. If you want to pitch in or someone else manages to send us some fixed, I'd be happy to pull the milestone in. -- Ticket URL: <http://trac.calendarserver.org/ticket/207#comment:6> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 31 Jul '08

31 Jul '08

#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------+--------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: sagen(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: 2.x Component: Calendar Server | Version: Severity: Serious | Resolution: Keywords: | ------------------------------------+--------------------------------------- Comment (by apm(a)one.com) Replying to [comment:4 wsanchez(a)apple.com] > The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit. Yes but that indication is stored in the RESOURCE table in RECURRANCE_MAX and unless I'm sorely mistaken a simple grep will show that RECURRANCE_MAX is used no where in the 1.2 code except in "create table" statements and in the "insert into" statement which first inserts the event into the RESOURCE table. (index.py). No where is the value brought out farther. I'm sad to see this bumped to milestone 2.x. I would suspect this to be a serious blocker for any practical use. No events of the "same time, next year" kind can be used in the calendar. Anniversaries and every other event more than 356 days into the future will also disappear. -- Ticket URL: <http://trac.calendarserver.org/ticket/207#comment:5> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Strange 404 on PROPFIND
by Helge Heß 27 Jul '08

27 Jul '08

Hi, I'm getting a weird 404 as a response to a PROPFIND. The strange thing is that a PROPFIND from Cadaver works. So I suppose one of the requested properties which triggers the 404? But is the whole result reported 404 then? Something is fishy ;-) Its trunk from today. ---snip--- 192.168.0.125 - - [25/Jul/2008:14:27:45 +0200] "PROPFIND /calendars/ users/user01/ HTTP/1.1" 401 141 "-" "ZideOne/0.8.3 neon/0.27.2" [232.4 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:45 +0200] "PROPFIND / calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/ 0.27.2" [116.5 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:46 +0200] "PROPFIND / calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/ 0.27.2" [29.3 ms] 192.168.0.111 - - [25/Jul/2008:14:29:27 +0200] "PROPFIND /calendars/ users/user01/ HTTP/1.1" 401 141 "-" "cadaver/0.23.2 neon/0.27.2" [51.7 ms] 192.168.0.111 - user01 [25/Jul/2008:14:29:33 +0200] "PROPFIND / calendars/users/user01/ HTTP/1.1" 207 3062 "-" "cadaver/0.23.2 neon/ 0.27.2" [118.1 ms] ---snap--- Debug log is attached. Thanks, Helge -- Helge Hess http://helgehess.eu/

2 3

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 24 Jul '08

24 Jul '08

#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------+--------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: sagen(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: 2.x Component: Calendar Server | Version: Severity: Serious | Resolution: Keywords: | ------------------------------------+--------------------------------------- Changes (by wsanchez(a)apple.com) * owner: cdaboo(a)apple.com => sagen(a)apple.com * milestone: 1.3 => 2.x Comment: The index is supposed to indicate how far out expansion has happened for each event, and if a query against the index goes beyond that time, the expansion should be brought out farther, up to a defined limit. If we have expanded to the limit, then any queries that goes beyond the limit would have to read the icalendar data to see if that event matches (far more expensive, but the idea is that such queries should be rare). The code is apparently not working as I described. -- Ticket URL: <https://trac.calendarserver.org/ticket/207#comment:4> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 24 Jul '08

24 Jul '08

#207: Recurring events do not appear to extend beyond November 2008 ------------------------------------+--------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: 1.3 Component: Calendar Server | Version: Severity: Serious | Resolution: Keywords: | ------------------------------------+--------------------------------------- Comment (by agx(a)sigxcpu.org) Peter Mogensen noticed that DCS (1.2) will not return an event instance more than 356 days from the creation of the event in a calendar-query. He found that these events are not put into the TIMESPAN index, which means that they are not returned by a search using the index. Searches seems to not use the index when there's a time-range element in the filter, but the exception detecting this is only thrown from the filter expression generator for prop-filters, ... which again means that if you don't have a prop-filter in your query, you'll get a search using the index, which will ignore these 356+ days events. -- Ticket URL: <https://trac.calendarserver.org/ticket/207#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #296: Error when trying to load "principals" webpage
by CalendarServer 21 Jul '08

21 Jul '08

#296: Error when trying to load "principals" webpage ----------------------------------+----------------------------------------- Reporter: cabanela(a)mnstate.edu | Owner: wsanchez(a)apple.com Type: Defect | Status: closed Priority: 1: Blocker | Milestone: Component: Calendar Server | Version: Severity: Serious | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Changes (by wsanchez(a)apple.com) * status: new => closed * resolution: => fixed Comment: You have two options to fix the GUID change: 1) Add the GUID back to the XML file (though I wouldn't do that unless you were using valid GUIDs before). 2) Rename `/calendars/__uids__/<old_guid>/` to `/calendars/__uids__/<new_guid>/` on disk. -- Ticket URL: <https://trac.calendarserver.org/ticket/296#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0