[dev] Exposing timeobjects to caldav

[Ralf Lang]

>>>>> * Patching Kronolith is tempting, but I don't think it's wise to 
>>>>> just expose random timeobjects providers to caldav interface 
>>>>> without letting the admin or user decide. Kronolith is complicated 
>>>>> and a prime horde app.
>>>>
>>>> I still think this is still the way to go. We should expose all 
>>>> calendar backends to CalDAV, limiting their features where 
>>>> necessary, like marking them read-only. Remote calendars might be an 
>>>> exception, since they can be exposed directly to clients using the 
>>>> "subscriptions" CalDAV extension.
>>>> If necessary, we could add a preference to allow users to only 
>>>> select a number of calendar types (or even individual calendars) to 
>>>> be exposed for synchronization.
>>>>
>>>
>>> Wow, that's quite some patch. I will consult with Diana if that is 
>>> something we can easily provide within reasonable time. If this is 
>>> the case, we will provide a PR.
>>
>> I've been looking at this.
>> For now, all externals will be presented readonly.
>>
>> I the visible name of the external collection contains the provider 
>> name and the collection name. For instance, if the provider was whups 
>> (declared as "Tickets" in the horde menu) and the collection label was 
>> "My Tickets by Due Date", this would be "Tickets - My Tickets by Due 
>> Date".
>>
>> I tried to sort the external calendars into a subfolder but this 
>> proved tricky without patching Horde_Dav, which is out of scope for a 
>> kronolith patch. For now, I stick with a flat user/calendars 
>> hierarchy, only visibly discerning shares from externals.
>>
>> Under the application name path (like whups), it seems Horde_Dav just 
>> invokes browse() to return a tree level. I am not sure but this looks 
>> like plain webdav instead of caldav.
>>
>> I think I am on the right track now. It's all settling step by step.
>>
> As external events pop up out of nowhere, there is no internal or 
> external object id. For collections, getExternalCollectionId 
> automagically calls addCollectionMap if missing. 
> Horde_Dav_Storage::getExternalObjectId however doesn't implicitly add 
> object maps. This is inconsistent, but can be worked around by checking 
> for an exception in Application::davGetObjects

Here is the PR https://github.com/horde/horde/pull/226
No filtering preferences yet.
All externals currently have the principal -system- but there is no real 
permission checking yet. It just assumes if the user is allowed to grab 
it via the timeobjects api, then the user is likewise allowed to expose 
it via DAV to his own login name.


-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang at b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537