2 Sep
2013
2 Sep
'13
11 p.m.
Hello,
is there a possibility for saving the user settings regarding the
visibility of calendars?
We have some people which setup group calendars for public read access.
After every login to CalDavZAP I have to unselect these calendars,
because they are of no interest for me and therefore confusing.
CalDavZap is configured with delegation=true.
Ingo
3 Sep
3 Sep
8:34 a.m.
Hi Ingo,
this feature is already supported:
1.) you must enable the settingsAccount exactly for ONE account (usually the logged user
account)
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)
If it not helps then your server maybe don't have support for storing DAV properties.
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.
JM
On Sep 3, 2013, at 1:00 AM, rog7993(a)web.de wrote:
Hello,
is there a possibility for saving the user settings regarding the visibility of
calendars?
We have some people which setup group calendars for public read access. After every login
to CalDavZAP I have to unselect these calendars, because they are of no interest for me
and therefore confusing. CalDavZap is configured with delegation=true.
Ingo
9 Sep
9 Sep
10:39 p.m.
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
10:52 p.m.
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
11:25 p.m.
Hi Ján,
Am 10.09.2013 00:52, schrieb Ján Máté:
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.
The patch fixed it. Thank you very much.
You wrote in one of your last mails
If it not helps then your server maybe don't have
support for storing
DAV properties"
I understand this sentence, that the setting is stored on the server. I
tested this with two different browsers on the same PC (Firefox,
Chrome). Saving of the setting, which calendars should be shown, works
with both. But this information is not shared, which I would expect,
when the setting is stored on the server. Each browser restores only the
settings which I saved with it. But this is not really important for me.
Ingo Rogalsky
11:31 p.m.
Hi,
On Sep 10, 2013, at 1:25 AM, rog7993(a)web.de wrote:
I understand this sentence, that the setting is stored
on the server. I tested this with two different browsers on the same PC (Firefox, Chrome).
Saving of the setting, which calendars should be shown, works with both. But this
information is not shared, which I would expect, when the setting is stored on the server.
Each browser restores only the settings which I saved with it. But this is not really
important for me.
we read settings from the server only after login. Then settings are stored during the
resource synchronization and logout. If you are logged multiple times then setting changes
are not shared between browsers (both browser perform settings "store" and the
last will win => next time you login, you will get settings stored last time)
JM
10 Sep
10 Sep
12:01 a.m.
Hi,
Am 10.09.2013 01:31, schrieb Ján Máté:
we read settings from the server only after login.
Then settings are
stored during the resource synchronization and logout. If you are
logged multiple times then setting changes are not shared between
browsers (both browser perform settings "store" and the last will win
=> next time you login, you will get settings stored last time)
I did some more tests. But the observed behavior is different. I looks,
like every browser saves it own settings. This does not depend from the
fact, which session I closed last. Anyway. At the moment this is not
really disturbing. I do not switch browsers all the time. And the few
check marks are quickly done, if I start a browser for the first time.
Ingo
12:16 a.m.
On Sep 10, 2013, at 2:01 AM, rog7993(a)web.de wrote:
I did some more tests. But the observed behavior is
different. I looks, like every browser saves it own settings. This does not depend from
the fact, which session I closed last. Anyway. At the moment this is not really
disturbing. I do not switch browsers all the time. And the few check marks are quickly
done, if I start a browser for the first time.
Settings are stored as a DAV property into principal-URL (or calendar-home-set /see
config.js/) ... DAV properties are defined as key=>value pair and the "key"
in CalDavZAP is fixed string (currently "http://inf-it.com/ns/cal/:settings",
but we will change it in the next version). So it is not possible to create different
settings for each browser - settings are stored for each user and not browser.
In DAViCal you can check the stored settings by using:
SELECT * FROM property WHERE
property_name='http://inf-it.com/ns/cal/:settings'ings';
JM
8:57 a.m.
Hi,
Am 10.09.2013 02:16, schrieb Ján Máté:
On Sep 10, 2013, at 2:01 AM, rog7993(a)web.de wrote:
I tried this in the on the PC in the office now. Here it works as you
predicted. Maybe I was too tired for doing this right last night....
Thanks for your help.
Ingo
I did some more tests. But the observed behavior
is different. I looks, like every browser saves it own settings. This does not depend from
the fact, which session I closed last. Anyway. At the moment this is not really
disturbing. I do not switch browsers all the time. And the few check marks are quickly
done, if I start a browser for the first time.
Settings are stored as a DAV property into principal-URL (or calendar-home-set /see
config.js/) ... DAV properties are defined as key=>value pair and the "key"
in CalDavZAP is fixed string (currently "http://inf-it.com/ns/cal/:settings",
but we will change it in the next version). So it is not possible to create different
settings for each browser - settings are stored for each user and not browser.
10:02 a.m.
Hello,
Am 10.09.2013 10:57, schrieb rog7993(a)web.de:
Addition:
I got an idea what went wrong yesterday. It seems, that the saved
settings are dependent of the server name, one use for connecting to
CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
reached with two different DNS names or better domains. Maybe I used one
in Firefox and the other on Chrome.
Ingo
Settings are stored as a DAV property into principal-URL (or calendar-home-set /see
config.js/) ... DAV properties are defined as key=>value pair and the "key"
in CalDavZAP is fixed string (currently "http://inf-it.com/ns/cal/:settings",
but we will change it in the next version). So it is not possible to create different
settings for each browser - settings are stored for each user and not browser.
I tried this in the on the PC in the office now. Here it works as you
predicted. Maybe I was too tired for doing this right last night....
1:22 p.m.
Yes,
this is true ... we store the URL with the domain name because if you use multiple CardDAV
accounts we need to distinguish between identical collection names.
JM
On Sep 10, 2013, at 12:02 PM, rog7993(a)web.de wrote:
Addition:
I got an idea what went wrong yesterday. It seems, that the saved
settings are dependent of the server name, one use for connecting to
CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
reached with two different DNS names or better domains. Maybe I used one
in Firefox and the other on Chrome.
Ingo
11 Sep
11 Sep
2:45 p.m.
Hello,
i watched this thread as it is very interesting to me, too. After
applying the patch, now the selection of calendars is persistent. But
one thing is a little bit confusing: deselected calendars are hidden in
the interface but still get loaded when the gui starts up. Wouldn't it
be a better performance, if the hidden calendars are only loaded on
demand? Only when the user activates the deselected items again? With
the settings remembered, i now don't see my archive calendars in the
gui. But startup still take a long time.
Just to say: it is a great enhancement, that the settings are now
remembered! MANY thanks for this option and the software itself!
Rudolf
Am 10.09.13 15:22, schrieb Ján Máté:
Yes,
this is true ... we store the URL with the domain name because if you use multiple
CardDAV accounts we need to distinguish between identical collection names.
JM
On Sep 10, 2013, at 12:02 PM, rog7993(a)web.de wrote:
> Addition:
>
> I got an idea what went wrong yesterday. It seems, that the saved
> settings are dependent of the server name, one use for connecting to
> CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
> reached with two different DNS names or better domains. Maybe I used one
> in Firefox and the other on Chrome.
>
> Ingo
>
--
Rudolf Graf von Roit zu Hoya
*E-Mail:* graf.roit(a)gmail.com
4:40 p.m.
Hi Rudolf,
it is not as easy as looks like. Currently a collection can be visible or hidden (but
always loaded). The feature you want will cause lot of problems, e.g.:
- how to add 3rd state (not loaded) to the interface and teach users what is the
difference between the not loaded and not visible collection
- this functionality will break the globalShowHiddenAlarms=true option (hidden collection
!= do not show alarms from this collection)
- if you load a collection each time when user clicks to a checkbox, you can/will crash
your browser (~ 30 concurrent requests /30 enabled collections/ = browser crash) ... =>
it requires request queue
- if we load all collection at once, we can reduce the number of requests to the server -
we can get sync-token changes from one PROPFIND request instead of N
CalDavZAP 0.10.0 will add time-range synchronization, so you can configure number of
months you want to load from past (default 1) and future (default 1). If you don't
change these configuration options then your client will load only 3 months of data (if
you set both options to 0, then only 1 month). The rest of data will be loaded only if you
click to date out of the already downloaded time-range (it will extend the
"window" of downloaded data). If you use DAViCal or other "good"
server with support for time-range filtering and sync-collection REPORT then CalDavZAP
will be REALLY FAST.
RC1 coming tonight or tomorrow :-)
JM
On Sep 11, 2013, at 4:45 PM, Graf von Roit zu Hoya <graf.roit(a)gmail.com> wrote:
Hello,
i watched this thread as it is very interesting to me, too. After applying the patch, now
the selection of calendars is persistent. But one thing is a little bit confusing:
deselected calendars are hidden in the interface but still get loaded when the gui starts
up. Wouldn't it be a better performance, if the hidden calendars are only loaded on
demand? Only when the user activates the deselected items again? With the settings
remembered, i now don't see my archive calendars in the gui. But startup still take a
long time.
Just to say: it is a great enhancement, that the settings are now remembered! MANY thanks
for this option and the software itself!
Rudolf
Am 10.09.13 15:22, schrieb Ján Máté:
Yes,
this is true ... we store the URL with the domain name because if you use multiple
CardDAV accounts we need to distinguish between identical collection names.
JM
On Sep 10, 2013, at 12:02 PM, rog7993(a)web.de wrote:
> Addition:
>
> I got an idea what went wrong yesterday. It seems, that the saved
> settings are dependent of the server name, one use for connecting to
> CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
> reached with two different DNS names or better domains. Maybe I used one
> in Firefox and the other on Chrome.
>
> Ingo
>
--
Rudolf Graf von Roit zu Hoya
E-Mail: graf.roit(a)gmail.com
8 p.m.
Hello Ján,
thank you for this comprehensive answer. These are details, a normal user never thinks
about.
The option to remember settings are a great enhancement. Combining this with the time
range selection makes it nearly perfect.
Again - thanx a lot.
Rudolf
Am 11.09.2013 um 18:40 schrieb Ján Máté <jan.mate(a)inf-it.com>om>:
Hi Rudolf,
it is not as easy as looks like. Currently a collection can be visible or hidden (but
always loaded). The feature you want will cause lot of problems, e.g.:
- how to add 3rd state (not loaded) to the interface and teach users what is the
difference between the not loaded and not visible collection
- this functionality will break the globalShowHiddenAlarms=true option (hidden collection
!= do not show alarms from this collection)
- if you load a collection each time when user clicks to a checkbox, you can/will crash
your browser (~ 30 concurrent requests /30 enabled collections/ = browser crash) ... =>
it requires request queue
- if we load all collection at once, we can reduce the number of requests to the server -
we can get sync-token changes from one PROPFIND request instead of N
CalDavZAP 0.10.0 will add time-range synchronization, so you can configure number of
months you want to load from past (default 1) and future (default 1). If you don't
change these configuration options then your client will load only 3 months of data (if
you set both options to 0, then only 1 month). The rest of data will be loaded only if you
click to date out of the already downloaded time-range (it will extend the
"window" of downloaded data). If you use DAViCal or other "good"
server with support for time-range filtering and sync-collection REPORT then CalDavZAP
will be REALLY FAST.
RC1 coming tonight or tomorrow :-)
JM
On Sep 11, 2013, at 4:45 PM, Graf von Roit zu Hoya <graf.roit(a)gmail.com> wrote:
> Hello,
>
> i watched this thread as it is very interesting to me, too. After applying the patch,
now the selection of calendars is persistent. But one thing is a little bit confusing:
deselected calendars are hidden in the interface but still get loaded when the gui starts
up. Wouldn't it be a better performance, if the hidden calendars are only loaded on
demand? Only when the user activates the deselected items again? With the settings
remembered, i now don't see my archive calendars in the gui. But startup still take a
long time.
>
> Just to say: it is a great enhancement, that the settings are now remembered! MANY
thanks for this option and the software itself!
>
> Rudolf
>
> Am 10.09.13 15:22, schrieb Ján Máté:
>> Yes,
>>
>> this is true ... we store the URL with the domain name because if you use
multiple CardDAV accounts we need to distinguish between identical collection names.
>>
>>
>> JM
>>
>> On Sep 10, 2013, at 12:02 PM, rog7993(a)web.de wrote:
>>
>>> Addition:
>>>
>>> I got an idea what went wrong yesterday. It seems, that the saved
>>> settings are dependent of the server name, one use for connecting to
>>> CalDavZAP. The server, on which CalDavZAP and Davical runs, can be
>>> reached with two different DNS names or better domains. Maybe I used one
>>> in Firefox and the other on Chrome.
>>>
>>> Ingo
3213
days inactive
3222
days old
13 comments
4 participants
participants (4)
-
Graf Roit -
Graf von Roit zu Hoya
-
Ján Máté -
rog7993＠web.de