Hi Ingo,
we found a bug related to your problem. It will be fixed in the next release, but you can
apply the included patch (and execute the cache_update.sh) if you need the fix
immediately.
JM
On Sep 10, 2013, at 12:39 AM, rog7993(a)web.de wrote:
Hello Ján,
thanks for your answer and the beautiful application.
Am 03.09.2013 10:34, schrieb Ján Máté:
this feature is already supported:
1.) you must enable the settingsAccount exactly for ONE account (usually the logged user
account)
Maybe I don't understand this correctly. What do you mean with "exactly one
account"?
My config.js defines
var globalNetworkCheckSettings={href:
location.protocol+'//'+location.hostname+(location.port ?
':'+location.port:
'')+location.pathname.replace(RegExp('/+[^/]+/*(index\.html)?$'),'')+'/caldav.php/',
hrefLabel: null, crossDomain: null, additionalResources: [], forceReadOnly: null,
withCredentials: false, showHeader: true, settingsAccount: true, checkContentType: true,
syncInterval: 60000, timeOut: 30000, lockTimeOut: 10000, delegation: true, ignoreAlarms:
false, backgroundCalendars: []}
globalAccountSettings and globalNetworkAccountSettings are undefined.
2.) you must set the globalSettingsType to
'calendar-home-set' if your server has no support for setting DAV properties to
'principal-URL' (this is the default for DAViCal)
I tried 'calendar-home-set' and 'principal-URL' (which is the
default, when this parameter is undefined, or?), but saving of the user settings does not
work with any of both alternatives.
If it not helps then your server maybe don't have support for storing DAV
properties.
Should this work with the combo Davical/Apache? Davical has version 1.1.1 without any
patches.
If you think that this is a bug, you can create a
demo/testing account on your server (+send me a private e-mail with credentials) and we
can check where is the problem.
The calendar server sits behind a firewall and is used only internally. I fear, the
person responsible for it, won't open it for a debug session.
Ingo Rogalsky