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