September 2009 - calendarserver-dev

[CalendarServer] #303: Support 'component'(=VEVENT, VTODO) parameter in getcontenttype properties of PROPFIND results
by CalendarServer 26 Oct '09

26 Oct '09

#303: Support 'component'(=VEVENT,VTODO) parameter in getcontenttype properties of PROPFIND results -------------------------------+-------------------------------------------- Reporter: helge(a)zideone.com | Owner: wsanchez(a)apple.com Type: Enhancement | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: -------------------------------+-------------------------------------------- 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 }}} Rational: In Outlook we need to map a single calendar collection to two (or three) Outlook folders, eg "Calendar (Events)" and "Calendar (Tasks)". In Outlook each folder has a distinct type (its either tasks or events, never both). So when we do a PROPFIND on a CalDAV calendar which supports both (calendar-component-set: VEVENT+VTODO), tasks and events (and journals ...), we currently just get the generic text/calendar type. We need to fetch the content to decide whether the item is relevant or not for a specific Outlook folder type. If the server would report the contained component-type, we could avoid that annoyingly hard work ;-) Thanks PS: obviously the client can't (and shouldn't) rely on that parameter, but its a relevant optimization. -- Ticket URL: <http://trac.calendarserver.org/ticket/303> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 3

[CalendarServer] #297: Incorrect treatment of Depth on REPORTs
by CalendarServer 26 Oct '09

26 Oct '09

#297: Incorrect treatment of Depth on REPORTs ---------------------------------+------------------------------------------ Reporter: navara(a)emclient.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: CalDAV Tester | Version: Severity: Other | Keywords: ---------------------------------+------------------------------------------ CalDAVTester incorrectly sends calendar-query REPORTs with no Depth header and expect it to match on the contents of the collection. No Depth header is equivalent to Depth: 0 as per RFC 4791 and RFC 3253 (section 3.6), so no matching on child resources should be performed by the server. This results in the failure of reports.xml tests and possibly others. -- Ticket URL: <https://trac.calendarserver.org/ticket/297> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #277: Set process name
by CalendarServer 26 Oct '09

26 Oct '09

#277: Set process name --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 3: Important | Milestone: 2.x Component: Calendar Server | Version: Severity: Other | Keywords: --------------------------------+------------------------------------------- Server should do `setproctitle` or whatever to set the process name so that it isn't `python`, which makes it harder to distinguish from other python programs. I think this would require a C extension, since Python doesn't provide API for it. -- Ticket URL: <https://trac.calendarserver.org/ticket/277> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #274: caldavd does not properly quote parameters
by CalendarServer 26 Oct '09

26 Oct '09

#274: caldavd does not properly quote parameters ---------------------------------+------------------------------------------ Reporter: kmdurbrow(a)gmail.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: ---------------------------------+------------------------------------------ Last line of caldavd {{{ ${configfile} }}} should be quoted -- Ticket URL: <https://trac.calendarserver.org/ticket/274> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #319: A solution is needed when max_allowed_instances is exceeded.
by CalendarServer 26 Oct '09

26 Oct '09

#319: A solution is needed when max_allowed_instances is exceeded. -----------------------------+---------------------------------------------- Reporter: apm@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Serious Keywords: | -----------------------------+---------------------------------------------- With the ability to create events longer into the future the possibility that a user will create an event with more than "max_allowed_instances" (currently 1000) increases. From instance.py: # The maximum number of instances we will ezpand out to. # Raise a TooManyInstancesError exception if we exceed this. max_allowed_instances = 1000 ... which will make events disappear from instance 1000 or not get created at all if you place the mother event sufficiently far back in the past. If - say - your default_future_expansion_duration is 2 years, you currently cannot create a daily recurring event with a motherevent before ~ april 2008. Or if you create a daily recurring event today, it will no longer work after 1000 days. I see no good solution to this without some mechanism for the user to clean up old calendars, so the don't unnecessarily contain - say - 5 year old daily events. -- Ticket URL: <http://trac.calendarserver.org/ticket/319> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #349: location in snow leopard...
by CalendarServer 01 Oct '09

01 Oct '09

#349: location in snow leopard... -----------------------------------+---------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 3: Important | Milestone: Later Component: Calendar Server | Severity: Serious Keywords: location snow leopard | -----------------------------------+---------------------------------------- when using "location" text field in iCal, it accepts directly, ...even if the user is not in the proxy list in the xml file. here is the part of the xlm, where user demo can mofidy calendar (it shouldn't) : <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi(a)location.fr</email-address> <auto-schedule/> <proxies> <member type="users">jduffas</member> </proxies> </location> -- Ticket URL: <http://trac.calendarserver.org/ticket/349> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 28 Sep '09

28 Sep '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: sagen@… Type: Feature | Status: new Priority: 2: Expected | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by naoh123@…): Sorry if this isn't the place, but is the LDAP patch at all applicable to CalendarServer 2.x? -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:32> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

calendarserver and interoperability
by Matthieu Huin 25 Sep '09

25 Sep '09

Hello all, I am documenting myself on calendaring systems and implementations of the CalDAV protocol, preferably in python; that is how I found out about Calendarserver. Does this server provide any kind of interoperability with other CalDAV servers such as Zimbra or Google Agenda ? In other words, is it possible to use Cosmo as a central server synchronizing itself with other CalDAV-compliant servers ? Cheers, Matthieu

1 0

Rejected timezones
by Helge Heß 18 Sep '09

18 Sep '09

Hi, I'm currently using timezones from tzurl.org. Some of them are apparently rejected by iCal Server? ---snip--- BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ZideOne//NONSGML ZideOne MAPI Store//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Caracas TZURL:http://tzurl.org/zoneinfo-outlook/America/Caracas X-LIC-LOCATION:America/Caracas BEGIN:STANDARD TZOFFSETFROM:-0430 TZOFFSETTO:-0430 TZNAME:VET DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT SEQUENCE:0 CREATED:20090918T141708Z DTSTAMP:20090918T141708Z UID:z1-20090918-141708-945-1 SUMMARY:Caracas DTSTART;TZID=America/Caracas:20090831T080000 DTEND;TZID=America/Caracas:20090876T204600 END:VEVENT END:VCALENDAR ---snap--- Looks fine to me, no? Thanks, Helge -- Helge Hess http://helgehess.eu/

1 0

[CalendarServer] WikiStart modified
by CalendarServer 15 Sep '09

15 Sep '09

Changed page "WikiStart" by wsanchez(a)apple.com from 17.224.20.215* Page URL: <http://trac.calendarserver.org/wiki/WikiStart> Diff URL: <http://trac.calendarserver.org/wiki/WikiStart?action=diff&version=36> Revision 36 Comment: repository.xml has been gone a long time, dude -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: WikiStart ========================================================================= --- WikiStart (version: 35) +++ WikiStart (version: 36) @@ -11,7 +11,6 @@ * [wiki:FAQ Frequently Asked Questions] * [wiki:Portability Supported Platforms and Portability] * [wiki:DirectoryService Configuring directory services] - * [wiki:RepositoryXML Configuring repository.xml] * [wiki:CalDAVClientLibrary Client and Admin tool Library] -------8<------8<------8<------8<------8<------8<------8<------8<-------- * The IP shown here might not mean anything if the user or the server is behind a proxy. -- CalendarServer </> HTTP/WebDAV/CalDAV Server This is an automated message. Someone at / added your email address to be notified of changes on WikiStart. If it was not you, please report to .

1 0