Re: Exposing timeobjects to caldav

On 13.08.2017 19:01, Ralf Lang wrote:
>>>>>> * 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.
> 
> 
Updated the PR. I changed everything Jan commented on, with the 
exception of the calendar id's - if they contain slashes, they break 
caldav stuff and get interpreted as hierarchy delimiters.

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: [email protected]
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]