Inf-IT DAV Clients March 2013

davclients@lists.inf-it.com

7 participants
9 discussions

Using CalDAVzap with ownCloud
by Johan Vromans 26 Mar '13

26 Mar '13

I hope this is not considered off-topic ;) Has anyone succeeded in running CalDAVzap and CardDAVmate with the ownCloud server? -- Johan

2 1

Problem with crossDomain-setup
by Thomas W. 26 Mar '13

26 Mar '13

Hi, regarding the documentation I have to use the crossDomain attribute, if I want to use a caldavzap installation with the URL "https://xxx.aaa.com:443/calclient", which should use a Davical installation at URL "https://yyy.aaa.com:443/". I set the crossDomain attribute to "true", but the installation is not working. The Apache2 logging says, that there is an request to URL "https://xxx.aaa.com:443/caldav.php/", but this is wrong. What is the correct setup for this scenario? Must I use the hrefLabel attribute or something else? I also tried to modify the Apache2 Vhost config for the Davical vhost (generic allow rule), but this is not working either. Any ideas? Thanks and kind regards, Thomas

2 2

Re: [Inf-IT DAVcl] Strange behaviour
by Andrej Lezo 22 Mar '13

22 Mar '13

Hello Simon It is normal behaviour because we are using PROPATCH property for saving user settings. The request is launched with every resource synchronization. So we need support for additional methods. Best regards, Andrej Lezo Simon <caldavzap(a)svswift.de> napísal: >Hello Jan, > >I now took a look in the logs: > >When opening caldavzap I get the following: > >ROPFIND http://server/SOGo/dav/user/Calendar/ 207 Multi-Status 74ms > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus xmlns:a="http://apple.com/ns/ical/" >xmlns:D="DAV:"><D:response><D:href>/SOGo/dav/user/Calendar/</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><D:read/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><D:unbind/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege></D:current-user-privilege-set><D:displayname>Calendar</D:displayname><D:resourcetype><D:collection/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.ics</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.xml</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal/</D:href><D:propstat><D:status>HTTP/1.1 >200 >OK</D:status><D:prop><a:calendar-color>#84BC34FF</a:calendar-color><D:current-user-privilege-set >xmlns:n2="urn:inverse:params:xml:ns:inverse-dav" xmlns:D="DAV:" >xmlns:n1="urn:ietf:params:xml:ns:caldav"><D:privilege><D:read/></D:privilege><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><n1:read-free-busy/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><n1:schedule/></D:privilege><D:privilege><n1:schedule-post/></D:privilege><D:privilege><n1:schedule-post-vevent/></D:privilege><D:privilege><n1:schedule-post-vtodo/></D:privilege><D:privilege><n1:schedule-post-vjournal/></D:privilege><D:privilege><n1:schedule-post-vfreebusy/></D:privilege><D:privilege><n1:schedule-deliver/></D:privilege><D:privilege><n1:schedule-deliver-vevent/></D:privilege><D:privilege><n1:schedule-deliver-vtodo/></D:privilege><D:privilege><n1:schedule-deliver-vjournal/></D:privilege><D:privilege><n1:schedule-deliver-vfreebusy/></D:privilege><D:privilege><n1:schedule-respond/></D:privilege><D:privilege><n1:schedule-respond-vevent/></D:privilege><D:privilege><n1:schedule-respond-vtodo/></D:privilege><D:privilege><D:unbind/></D:privil >ege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:read-acl/></D:privilege><D:privilege><D:write-acl/></D:privilege><D:privilege><n2:admin/></D:privilege><D:privilege><D:all/></D:privilege></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype><D:collection/><calendar >xmlns="urn:ietf:params:xml:ns:caldav"/><vevent-collection >xmlns="http://groupdav.org/"/><vtodo-collection >xmlns="http://groupdav.org/"/><schedule-outbox >xmlns="urn:ietf:params:xml:ns:caldav"/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><D:sync-token/></D:prop></D:propstat></D:response></D:multistatus> > > >REPORT http://server/SOGo/dav/user/Calendar/personal/ 207 Multi-Status > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus >xmlns:D="DAV:"><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/6d026dd6044076dfde4ed7ecbedeec887b0df320de9ccd95f9f7469aae99cd17.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000002"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/c35bf93529a8a22cb079dc4d924ac359c477d2f0d60fcc88208b9bb02a14a658.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000001"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-token>1363922134</D:sync-token></D:multistatus> > >The .ics-file looks as follows: >BEGIN:VCALENDAR >VERSION:2.0 >BEGIN:VEVENT >CREATED:20130322T031033Z >LAST-MODIFIED:20130322T031532Z >DTSTAMP:20130322T031532Z >UID:b583diub-4e32-ia2p-ljmd-2yak0ufcgl5g >SUMMARY:Test3 >TRANSP:OPAQUE >CLASS:PUBLIC >DTSTART;TZID=Europe/Berlin:20130322T090000 >DTEND;TZID=Europe/Berlin:20130322T100000 >END:VEVENT >END:VCALENDAR > > >Right after the next REPORT I get the following: > >PROPPATCH http://server/SOGo/dav/user/Calendar/personal/ 403 Forbidden ><?xml version="1.0" encoding="ISO-8859-1"?> ><html xmlns="http://www.w3.org/1999/xhtml"> ><body><h3>An error occurred during object publishing</h3><p>Property >'{http://inf-it.com/ns/cal/}cal-settings' cannot be set.</p></body> ></html> > > >Yours, >Simon > >Am 06.03.2013 01:58, schrieb Ján Máté: >> Hi Simon, >> >> On Mar 6, 2013, at 1:51 AM, Simon <caldavzap(a)svswift.de> wrote: >> >>> Hey Jan, >>> >>> just tell when and how I can help (with logs or an account etc.). >>> So far: Seems really good! >>> If you are redoing the interface, could you make it so that entrys have a default starting hour (p.ex. next full hour) and an end-date which is starting hour+1 (even if one changes the starting hour). >> >> use double-click on the hour fields, and you will get: >> - the current time as "start time" and >> - current time+1 hour as "end time" (if the start and end dates are the same) or >> - the same "end time" as "start time" (if the end date is greater than start date) >> >> You can also create events using mouse (click, drag and release) and the dates/times will be predefined :-) >> >> >> JM >> >>> >>> I really like the fact that CalDAVzap uses the predefined colors from the server. >>> >>> Simon >>> >>> Am 06.03.2013 01:42, schrieb Ján Máté: >>>> Hi Simon, >>>> >>>> CalDavZAP is currently tested ONLY with DAViCal. Support for more servers will come in future - I hope in next 2-3 months (currently we are working on completely new interface for ToDo and minor bug fixes). >>>> >>>> >>>> JM >>>> >>>> >>>> On Mar 6, 2013, at 1:35 AM, Simon <caldavzap(a)svswift.de> wrote: >>>> >>>>> Hello from Passau, >>>>> >>>>> I have setup CalDAVzap with SOGo. This is working partly. >>>>> When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. >>>>> >>>>> However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. >>>>> >>>>> It seems like CalDAVzap is failing to load those entries from SOGo. >>>>> In the SOGo-Logs I see PROPFIND and REPORT. >>>>> >>>>> Any help appreciated. >>>>> >>>>> Simon >>>>> >>>> >>> >> >

3 3

Strange behaviour
by Simon 22 Mar '13

22 Mar '13

Hello from Passau, I have setup CalDAVzap with SOGo. This is working partly. When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. It seems like CalDAVzap is failing to load those entries from SOGo. In the SOGo-Logs I see PROPFIND and REPORT. Any help appreciated. Simon

2 4

Custom fields?
by Sven Anders 21 Mar '13

21 Mar '13

Hello! Is it possible to configure custom fields in the clients? We want to build a company wide addressbook and we need a customer number/id. I think something like would be nice: custom_fields = [ {name:'Customer Number', id:'X-CustomerNumber' }, ... ]; Regards Sven Anders -- Sven Anders <anders(a)anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin

2 1

About v0.11rc1
by Attila Asztalos 14 Mar '13

14 Mar '13

Hi, a few things I encountered / remembered just now (currently with 0.11rc1): - At the periodic sync update (the default 60 seconds for me) the entire webpage goes void of data (the frames are still there, but address books and contacts disappear) for a few seconds, then all goes back to normal. However, it does jump back to the first contact in the address book and if I was editing a contact, the light-grey "edit mode" of the list persists, so I cannot click on other contacts unless I either log in and back out or click "edit" on the displayed contact then cancel. If there was unsaved data in the edited contact it is of course lost after this. There are no error messages in the console. I don't remember this happening before - CalDavZAP for instance still syncs very nicely in the background, all I see is the little rotating symbol. - You might want to include special Romanian chars U+015E, U+015F (s with cedilla) and U+0162, U+0163 (t with cedilla) in the sort and search alphabet strings at letter 's' and 't' respectively - I can do it in my own config but I guess it doesn't hurt to have them there by default. You might also want to include U+218, U+219 (s with comma) and U+21A, U+21B (t with comma) versions too - only one of these two version is actually supposed to exist, but which one is the correct one is a rather messy affair - interested parties can read all about it at [1] (TL;DR: cedilla is the widely supported and used one, comma is supposed to be the correct one). - Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that. Regards, - Attila [1] - http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C… [2] - http://en.wikipedia.org/wiki/Mailing_address_format_by_country#Romania [3] - http://www.posta-romana.ro/posta-romana/produse-si-servicii/Personal_subpag…

2 5

CardDavMATE 0.11rc1
by Ján Máté 13 Mar '13

13 Mar '13

Hi everybody, CardDavMATE 0.11rc1 is available at: http://www.inf-it.com/CardDavMATE_0.11rc1.zip with: - **MAJOR** performence enhancements - support for photo editing by click to the "photo box" - and many other fixes/imporovements: http://www.inf-it.com/carddavmate-next/changelog.txt demo: http://www.inf-it.com/carddavmate-next/ Much thanks for your feedback! JM

1 0

Re: vCard files
by Ján Máté 07 Mar '13

07 Mar '13

Atilla, thanks for testing the patch - here is the more optimised version + one additional fix for the PHOTO attribute: http://www.inf-it.com/fixes/data_process.js for everybody who experience the same problem with duplicate IM values or have a problem with missing photos, use the quick fix above (replace the data_process.js in CardDavMATE) ... or wait for the next version ... JM On Mar 6, 2013, at 9:29 PM, Attila Asztalos <attila.asztalos(a)gmail.com> wrote: > Hi Ján, > > Yes it does fix the duplication. Thank you. In the long run, you might want to consider parsing the X-SKYPE key too though - if I understand correctly, right now it wouldn't even show up if there were no IMPP duplicate of it in the vCard (this does not affect of course software that already does store skype IDs in both formats). > > Regards, > - Attila

1 0

regarding merging of IMPP data
by Attila Asztalos 06 Mar '13

06 Mar '13

Hi, I just noticed that something funny is going on with the IM ID data of my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so: X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id While it certainly can be argued that this is not exactly good practice (RFC4770 that defines the IMPP syntax says nothing about allowing or prohibiting the alternative notation in parallel - strictly speaking CardDavMate being entitled to interpret this as FOUR individual IDs), I think we can safely say it's reasonable to merge any number of instances of the same specific protocol AND same exact ID to a single one when presenting it to the user (reducing the above to only two IDs). Especially since this is already happening with Skype - but not with Yahoo. Could this be implemented as proposed? Regards, Attila

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients March 2013