Inf-IT DAV Clients September 2013

davclients@lists.inf-it.com

9 participants
23 discussions

CalDavZAP 0.10.0rc1
by Ján Máté 12 Sep '13

12 Sep '13

Hi list, CalDavZAP 0.10.0rc1 available: demo: http://www.inf-it.com/caldavzap-new/ changelog: http://www.inf-it.com/caldavzap-new/changelog.txt download: http://www.inf-it.com/CalDavZAP_0.10.0rc1.zip this relase contains LOT of internal changes and MAJOR improvements (e.g. time-range filtering support) so please test it ... and do not forget to read the changelog JM p.s.: CardDavMATE 0.12.0rc1 coming soon with LOT of changes - screenshot: http://www.inf-it.com/fixes/CardDavMATE-next.png

1 0

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 12 Sep '13

12 Sep '13

Do you want to test with my server? In can set you up later when I get back home. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University On Sep 11, 2013, at 5:39 PM, Ján Máté <jan.mate(a)inf-it.com> wrote: > Hi Ken, > > this sounds very good. Last time (1-2 months back) we tried this type of request with DAViCal we got an error ... > > I will ask Andrew for fix :-) > > > JM > > > On Sep 11, 2013, at 11:34 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Hi Ján, >> >> I just looked at RFC 4791 and it certainly looks like this SHOULD be supported by all servers: >> >> >> If the Request-URI is a collection resource, >> then the DAV:href elements MUST refer to calendar object resources >> within that collection, and they MAY refer to calendar object >> resources at any depth within the collection. As a result, the >> "Depth" header MUST be ignored by the server and SHOULD NOT be >> sent by the client. >> Note that it states that the resource may be "at any depth within the collection". >> >> I just tested this on my server and I can fetch objects from 2 different calendars by using the calendar-home-set as the target resource of the request as in your example. >> >> >> >> On 09/11/2013 05:17 PM, Ken Murchison wrote: >>> I wouldn't be surprised if some of the existing servers already support such requests. I will have to do some testing on my server to see if I support it (I'm thinking that I do). I suppose I also need to look at the CalDAV spec to see if its allowed. The other alternative is to pipeline the requests, so rather than 2 or more roundtrips you just have 1. >>> >>> >>> >>> On 09/11/2013 04:12 PM, Ján Máté wrote: >>>> Hi Ken, >>>> >>>> thanks - I added this functionality to my todo list. >>>> >>>> Is there any similar RFC to minimize the number of HTTP requests to the server? The biggest problem in JavaScript is the number of requests :-/ >>>> >>>> For example cross-collection calendar-multiget REPORT can extremely speed-up our clients and it requires minimal changes in servers. >>>> >>>> Instead of: >>>> >>>> REPORT /user/collection/ >>>> <calendar-multiget> >>>> <href>a.ics</href> >>>> <href>b.ics</href> >>>> </calendar-multiget> >>>> >>>> REPORT /user/another-collection/ >>>> <calendar-multiget> >>>> >>>> <href>x.ics</href> >>>> >>>> <href>y.ics</href> >>>> </calendar-multiget> >>>> >>>> why to not support: >>>> >>>> REPORT /user/ >>>> <calendar-multiget> >>>> >>>> <href>collection/x.ics</href> >>>> >>>> <href>collection/y.ics</href> >>>> >>>> <href>another-collection/x.ics</href> >>>> >>>> <href>another-collection/y.ics</href> >>>> </calendar-multiget> >>>> >>>> It can speed up lot of clients ... >>>> >>>> >>>> JM >>>> >>>> >>>> On Sep 11, 2013, at 9:52 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: >>>> >>>>> Hi Ján, >>>>> >>>>> If you're working towards less traffic over the wire, you could use the "return=minimal" Preference with your PROPFIND, REPORT, and PROPPATCH requests: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/ >>>>> >>>>> Its supported by my server, DAViCal, Bedework, and Apple as noted in the draft. >>>>> >>>>> >>>>> On 09/11/2013 12:40 PM, Ján Máté wrote: >>>>>> 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 >>>>>>> >>>>> >>>>> >>>>> -- >>>>> Kenneth Murchison >>>>> Principal Systems Software Engineer >>>>> Carnegie Mellon University >>> >>> >>> -- >>> Kenneth Murchison >>> Principal Systems Software Engineer >>> Carnegie Mellon University >> >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >

2 1

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 11 Sep '13

11 Sep '13

Hi Ján, I just looked at RFC 4791 and it certainly looks like this SHOULD be supported by all servers: If the Request-URI is a collection resource, then the DAV:href elements MUST refer to calendar object resources within that collection, and they MAY refer to calendar object resources at any depth within the collection. As a result, the "Depth" header MUST be ignored by the server and SHOULD NOT be sent by the client. Note that it states that the resource may be "at any depth within the collection". I just tested this on my server and I can fetch objects from 2 different calendars by using the calendar-home-set as the target resource of the request as in your example. On 09/11/2013 05:17 PM, Ken Murchison wrote: > I wouldn't be surprised if some of the existing servers already > support such requests. I will have to do some testing on my server to > see if I support it (I'm thinking that I do). I suppose I also need > to look at the CalDAV spec to see if its allowed. The other > alternative is to pipeline the requests, so rather than 2 or more > roundtrips you just have 1. > > > > On 09/11/2013 04:12 PM, Ján Máté wrote: >> Hi Ken, >> >> thanks - I added this functionality to my todo list. >> >> Is there any similar RFC to minimize the number of HTTP requests to >> the server? The biggest problem in JavaScript is the number of >> requests :-/ >> >> For example cross-collection calendar-multiget REPORT can extremely >> speed-up our clients and it requires minimal changes in servers. >> >> Instead of: >> >> REPORT /user/collection/ >> <calendar-multiget> >> <href>a.ics</href> >> <href>b.ics</href> >> </calendar-multiget> >> >> REPORT /user/another-collection/ >> <calendar-multiget> >> <href>x.ics</href> >> <href>y.ics</href> >> </calendar-multiget> >> >> why to not support: >> >> REPORT /user/ >> <calendar-multiget> >> <href>collection/x.ics</href> >> <href>collection/y.ics</href> >> <href>another-collection/x.ics</href> >> <href>another-collection/y.ics</href> >> </calendar-multiget> >> >> It can speed up lot of clients ... >> >> >> JM >> >> >> On Sep 11, 2013, at 9:52 PM, Ken Murchison <murch(a)andrew.cmu.edu >> <mailto:murch@andrew.cmu.edu>> wrote: >> >>> Hi Ján, >>> >>> If you're working towards less traffic over the wire, you could use >>> the "return=minimal" Preference with your PROPFIND, REPORT, and >>> PROPPATCH requests: >>> >>> https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/ >>> >>> Its supported by my server, DAViCal, Bedework, and Apple as noted in >>> the draft. >>> >>> >>> On 09/11/2013 12:40 PM, Ján Máté wrote: >>>> 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 <mailto: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(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 >>>>> >>>> >>> >>> >>> -- >>> Kenneth Murchison >>> Principal Systems Software Engineer >>> Carnegie Mellon University >> > > > -- > Kenneth Murchison > Principal Systems Software Engineer > Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 11 Sep '13

11 Sep '13

I wouldn't be surprised if some of the existing servers already support such requests. I will have to do some testing on my server to see if I support it (I'm thinking that I do). I suppose I also need to look at the CalDAV spec to see if its allowed. The other alternative is to pipeline the requests, so rather than 2 or more roundtrips you just have 1. On 09/11/2013 04:12 PM, Ján Máté wrote: > Hi Ken, > > thanks - I added this functionality to my todo list. > > Is there any similar RFC to minimize the number of HTTP requests to > the server? The biggest problem in JavaScript is the number of > requests :-/ > > For example cross-collection calendar-multiget REPORT can extremely > speed-up our clients and it requires minimal changes in servers. > > Instead of: > > REPORT /user/collection/ > <calendar-multiget> > <href>a.ics</href> > <href>b.ics</href> > </calendar-multiget> > > REPORT /user/another-collection/ > <calendar-multiget> > <href>x.ics</href> > <href>y.ics</href> > </calendar-multiget> > > why to not support: > > REPORT /user/ > <calendar-multiget> > <href>collection/x.ics</href> > <href>collection/y.ics</href> > <href>another-collection/x.ics</href> > <href>another-collection/y.ics</href> > </calendar-multiget> > > It can speed up lot of clients ... > > > JM > > > On Sep 11, 2013, at 9:52 PM, Ken Murchison <murch(a)andrew.cmu.edu > <mailto:murch@andrew.cmu.edu>> wrote: > >> Hi Ján, >> >> If you're working towards less traffic over the wire, you could use >> the "return=minimal" Preference with your PROPFIND, REPORT, and >> PROPPATCH requests: >> >> https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/ >> >> Its supported by my server, DAViCal, Bedework, and Apple as noted in >> the draft. >> >> >> On 09/11/2013 12:40 PM, Ján Máté wrote: >>> 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 <mailto: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(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 >>>> >>> >> >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 11 Sep '13

11 Sep '13

Hi Ján, If you're working towards less traffic over the wire, you could use the "return=minimal" Preference with your PROPFIND, REPORT, and PROPPATCH requests: https://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/ Its supported by my server, DAViCal, Bedework, and Apple as noted in the draft. On 09/11/2013 12:40 PM, Ján Máté wrote: > 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 <mailto: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(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 >> > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

saving of user settings
by rog7993＠web.de 11 Sep '13

11 Sep '13

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

4 13

translation and wish-list.
by Peter Holmberg 11 Sep '13

11 Sep '13

Hi! Great piece of software!! I have started on a Swedish translation but i cant find any way to submit the "patch". I also have a suggestion, an export/ print function. Where i get a week view and either that i could choose start and end time of the days or i get the minimum spread of my events with at least the business hours. /Peter

2 1

Roadmap - Features
by Adrien MALGOYRE 03 Sep '13

03 Sep '13

Hi Ján, hi list First of all, thanks for your great job! And sorry for my poor english Today, we use Agendav (www.agendav.org) for our users. I follow your work since the first release. We need features before migrate from Agendav to CaldavZap in a near future. Maybe it's already in your roadmap? (if not, can you give us your point of view? I read that you work first on the performance issues) - Agendav allow users to share their own calendar(s) directly to other users present in the davical server database. We like this feature because the davical admin frontend is too complex for basic users. - Is-there a way to let the user to choose the color of his calendars. Usefull for groups: each member can select the color of his choice for the team calendar. This feature is not server-dependant (i know that the color can be transmitted to the caldav server but this is not what we want) - Permit users to include external calendars ( .ics ) directly via caldavzap web frontend. Actually it seems possible only via config files. - Permit users to create calendars (already discussed in caldavzap mailing list). I think that it's already in the roadmap. - Forced Refresh button without waiting. ( F5 disconnect the user) Regards; Adrien

3 4

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 03 Sep '13

03 Sep '13

Actually, it doesn't look like it obeys the selected timezone either. Its defaults back to globalTimeZone On 09/03/2013 09:57 AM, Ján Máté wrote: > Hi Ken, > > thanks for the report ... will check and fix! > > > JM > > On Sep 3, 2013, at 3:55 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Hi Ján, >> >> The setting which controls which calendars are unselected does not work on my server. As you can see below, it is using URLs which don't correspond to any collections: >> >> PROPPATCH /dav/calendars/user/ken/ HTTP/1.1 >> Host: 192.168.137.22 >> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 >> Accept: application/xml, text/xml, */*; q=0.01 >> Accept-Language: en-US,en;q=0.5 >> Accept-Encoding: gzip, deflate >> Content-Type: text/xml; charset=UTF-8 >> Authorization: Basic ....... >> X-client: CalDavZAP 0.9.1.2 (Inf-IT CalDAV Web Client) >> Depth: 0 >> Referer: http://localhost/caldavzap-0.9.1.2/ >> Content-Length: 584 >> Origin: http://localhost >> Connection: keep-alive >> >> <?xml version="1.0" encoding="utf-8"?> >> <D:propertyupdate xmlns:D="DAV:"> >> <D:set> >> <D:prop> >> <I:settings xmlns:I="http://inf-it.com/ns/cal/"> >> {"inactiveCollections":["http://undefined","http://undefined","http://undefined","http://undefined","http://undefined"], >> "inactiveTodoCollections":[], >> "TodoListFilterSelected":["filterAction"], >> "activeView":"agendaWeek", >> "activeApp":"CalDavZAP", >> "calendarSelected":"ken/Default/", >> "TodoCalendarSelected":"ken/Default/", >> "addressbookSelected":"", >> "timezoneSelected":"America/New_York", >> "currentDate":"2013-9-1"} >> </I:settings> >> </D:prop> >> </D:set> >> </D:propertyupdate> >> >> >> >> On 09/03/2013 04:34 AM, Ján Máté wrote: >>> 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 >>>> >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] saving of user settings
by Ken Murchison 03 Sep '13

03 Sep '13

Hi Ján, The setting which controls which calendars are unselected does not work on my server. As you can see below, it is using URLs which don't correspond to any collections: PROPPATCH /dav/calendars/user/ken/ HTTP/1.1 Host: 192.168.137.22 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0 Accept: application/xml, text/xml, */*; q=0.01 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: text/xml; charset=UTF-8 Authorization: Basic ....... X-client: CalDavZAP 0.9.1.2 (Inf-IT CalDAV Web Client) Depth: 0 Referer: http://localhost/caldavzap-0.9.1.2/ Content-Length: 584 Origin: http://localhost Connection: keep-alive <?xml version="1.0" encoding="utf-8"?> <D:propertyupdate xmlns:D="DAV:"> <D:set> <D:prop> <I:settings xmlns:I="http://inf-it.com/ns/cal/"> {"inactiveCollections":["http://undefined","http://undefined","http://undefined","http://undefined","http://undefined"], "inactiveTodoCollections":[], "TodoListFilterSelected":["filterAction"], "activeView":"agendaWeek", "activeApp":"CalDavZAP", "calendarSelected":"ken/Default/", "TodoCalendarSelected":"ken/Default/", "addressbookSelected":"", "timezoneSelected":"America/New_York", "currentDate":"2013-9-1"} </I:settings> </D:prop> </D:set> </D:propertyupdate> On 09/03/2013 04:34 AM, Ján Máté wrote: > 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 >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients September 2013