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
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@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
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
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@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
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
Hi, On Sep 10, 2013, at 1:25 AM, rog7993@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
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
On Sep 10, 2013, at 2:01 AM, rog7993@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'; JM
Hi, Am 10.09.2013 02:16, schrieb Ján Máté:
On Sep 10, 2013, at 2:01 AM, rog7993@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.
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
Hello, Am 10.09.2013 10:57, schrieb rog7993@web.de:
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....
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
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@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
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@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@gmail.com
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@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@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@gmail.com
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@inf-it.com>:
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@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@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
participants (4)
-
Graf Roit -
Graf von Roit zu Hoya
-
Ján Máté -
rog7993＠web.de