Ticket #95 (closed Defect: Duplicate)
/calendars/ not created
| Reported by: | cdaboo@… | Owned by: | wsanchez@… |
|---|---|---|---|
| Priority: | 2: Expected | Milestone: | CalDAV-access |
| Component: | Calendar Server | Severity: | Serious |
| Keywords: | Cc: | kurt.leubner@… | |
| Port: |
Description
/calendars/ is not created when the server starts up the first time. As a result it does not appear in a directory listing of /, though a PROPFIND or an explicit GET on /calendars does create it. The server should auto-create /calendars as it does /principals.
Change History
Note: See
TracTickets for help on using
tickets.
Hrmm... DirectoryPrincipalProvisioningResource seems to do self.provision() on init. There doesn't appear to be any danger in doing that with CalendarHomeProvisioningResource either. Though the usages of provision are numerous and unwieldy (it seems to be called in several cases for certain resources some of which include init) The only resource who has to defer provisioning (DirectoryCalendarHomeResource) seems to only call provision in self.locateChild and is appropriately deferred. So it should be safe to call .provision of CalendarHomeProvisioningResource in init as long as that doesn't trickle down to something that calls DirectoryCalendarHomeResource's .provision