Re: Exposing timeobjects to caldav

Zitat von Ralf Lang <[email protected]>:

> 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.

Ah yes, that bug in Sabre that never got fixed properly. That's why I  
use the tilde as a separator in CalDAV URLs too.

-- 
Jan Schneider
The Horde Project
https://www.horde.org/

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]