I'm using CalDavZAP 0.10.0.5 and right after upgrading from an older version I've noticed that an event that is long past due (last year) but still not completed (still "needing action") is not shown in the todo list - but after a short while (the first auto-reload I assume - about 2 minutes) it does show up without any intervention from me. I confirmed the issue by creating a brand new todo with a future due date (showed up immediately after logging in) which I then modified to have a due date in the past (started showing up with a delay after login, just like the other one).
- Attila
Hi Atilla,
the problem you described may depend on the server you use. We use time range filtering for server which supports that functionality, otherwise we use completely different synchronization. If you want a really fast solution please create a demo server/account (+ send me a private email with credentials) and we can check where is the problem.
JM
On 21 Apr 2014, at 21:22, Attila Asztalos attila.asztalos@gmail.com wrote:
I'm using CalDavZAP 0.10.0.5 and right after upgrading from an older version I've noticed that an event that is long past due (last year) but still not completed (still "needing action") is not shown in the todo list - but after a short while (the first auto-reload I assume - about 2 minutes) it does show up without any intervention from me. I confirmed the issue by creating a brand new todo with a future due date (showed up immediately after logging in) which I then modified to have a due date in the past (started showing up with a delay after login, just like the other one).
- Attila
Hi Ján,
I'd love to, but this is a home/personal LAN-only server running on my desktop (whenever I start it), not set up to be accessed from the internet - I don't even have a fixed IP. That said, the server I use is Baikal (with digest auth), the Apache log entries between me logging in and the two todo items showing up are pasted below, and I'd be glad to send you / sniff any other traffic you might find useful - just let me know how else I can help...
- Attila
[22/Apr/2014:20:47:03 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 207 436 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:47:04 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 15309 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 187 [22/Apr/2014:20:49:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:04 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:49:05 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 403 540 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 403 275 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 207 18026 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 27535
On 22-Apr-2014 09:26, Ján Máté wrote:
Hi Atilla,
the problem you described may depend on the server you use. We use time range filtering for server which supports that functionality, otherwise we use completely different synchronization. If you want a really fast solution please create a demo server/account (+ send me a private email with credentials) and we can check where is the problem.
JM
On 21 Apr 2014, at 21:22, Attila Asztalos attila.asztalos@gmail.com wrote:
I'm using CalDavZAP 0.10.0.5 and right after upgrading from an older version I've noticed that an event that is long past due (last year) but still not completed (still "needing action") is not shown in the todo list - but after a short while (the first auto-reload I assume - about 2 minutes) it does show up without any intervention from me. I confirmed the issue by creating a brand new todo with a future due date (showed up immediately after logging in) which I then modified to have a due date in the past (started showing up with a delay after login, just like the other one).
- Attila
Unfortunately this information is not really helpful because there are lot of errors (and lot of them are maybe related to digest auth). So my first recommendation is to switch to basic auth (with https).
For further debugging we really need an access to test server where we can reproduce the problem ... can you create a VMWare virtual machine with minimal Debian installation and Baikal where the problem is reproducible?
JM
On 22 Apr 2014, at 20:09, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi Ján,
I'd love to, but this is a home/personal LAN-only server running on my desktop (whenever I start it), not set up to be accessed from the internet - I don't even have a fixed IP. That said, the server I use is Baikal (with digest auth), the Apache log entries between me logging in and the two todo items showing up are pasted below, and I'd be glad to send you / sniff any other traffic you might find useful - just let me know how else I can help...
- Attila
[22/Apr/2014:20:47:03 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 207 436 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:47:04 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 15309 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 187 [22/Apr/2014:20:49:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:04 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:49:05 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 403 540 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 403 275 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 207 18026 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 27535
Unfortunately I don't think I can do that, Baikal only supports digest auth AFAIK. That's the source of all those 401's - they are normal. And, to be honest, best I can tell I never even used a VM before - so this flies a bit over my head. However, I did capture the initial transactions using Chrome - both requests and replies, including the actual XML data. I'll send them to you directly, let me know if they are of any use.
- Attila
On 22-Apr-2014 21:35, Ján Máté wrote:
Unfortunately this information is not really helpful because there are lot of errors (and lot of them are maybe related to digest auth). So my first recommendation is to switch to basic auth (with https).
For further debugging we really need an access to test server where we can reproduce the problem ... can you create a VMWare virtual machine with minimal Debian installation and Baikal where the problem is reproducible?
JM
On 22 Apr 2014, at 20:09, Attila Asztalos <attila.asztalos@gmail.com mailto:attila.asztalos@gmail.com> wrote:
Hi Ján,
I'd love to, but this is a home/personal LAN-only server running on my desktop (whenever I start it), not set up to be accessed from the internet - I don't even have a fixed IP. That said, the server I use is Baikal (with digest auth), the Apache log entries between me logging in and the two todo items showing up are pasted below, and I'd be glad to send you / sniff any other traffic you might find useful - just let me know how else I can help...
- Attila
[22/Apr/2014:20:47:03 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 207 436 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:47:04 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 15309 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 187 [22/Apr/2014:20:49:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:04 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:49:05 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 403 540 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 403 275 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 207 18026 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 27535
Hi Attila, thanks for your attachment. The reason why you don't see your to-do from last year is because we use time range filtering for todo/event loading (Calendar-query) to minimalize server traffic. So we are loading todos which are after start of that time range. Unfortunately there is no such thing as using of time range filter in combination with STATUS=NEEDS-ACTION filter in logical "OR" relation (http://tools.ietf.org/html/rfc4791#section-7.8). But you can extend the start of your time range by setting globalEventStartPastLimit variable to bigger number in config.js file. Default value is 3. Regards, Andrej Dňa 22. 4. 2014 22:06 Attila Asztalos wrote / napísal(a):
Unfortunately I don't think I can do that, Baikal only supports digest auth AFAIK. That's the source of all those 401's - they are normal. And, to be honest, best I can tell I never even used a VM before - so this flies a bit over my head. However, I did capture the initial transactions using Chrome - both requests and replies, including the actual XML data. I'll send them to you directly, let me know if they are of any use.
- Attila
On 22-Apr-2014 21:35, Ján Máté wrote:
Unfortunately this information is not really helpful because there are lot of errors (and lot of them are maybe related to digest auth). So my first recommendation is to switch to basic auth (with https).
For further debugging we really need an access to test server where we can reproduce the problem ... can you create a VMWare virtual machine with minimal Debian installation and Baikal where the problem is reproducible?
JM
On 22 Apr 2014, at 20:09, Attila Asztalos <attila.asztalos@gmail.com mailto:attila.asztalos@gmail.com> wrote:
Hi Ján,
I'd love to, but this is a home/personal LAN-only server running on my desktop (whenever I start it), not set up to be accessed from the internet - I don't even have a fixed IP. That said, the server I use is Baikal (with digest auth), the Apache log entries between me logging in and the two todo items showing up are pasted below, and I'd be glad to send you / sniff any other traffic you might find useful - just let me know how else I can help...
- Attila
[22/Apr/2014:20:47:03 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/ HTTP/1.1" 207 436 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:04 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:47:04 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 15309 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:47:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 187 [22/Apr/2014:20:49:04 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:04 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/principals/myuser/ HTTP/1.1" 207 978 [22/Apr/2014:20:49:05 +0300] "PROPPATCH /cal.php/principals/myuser/ HTTP/1.1" 403 540 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/ HTTP/1.1" 207 5218 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 403 275 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "PROPFIND /cal.php/calendars/myuser/default/ HTTP/1.1" 207 18026 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 401 292 [22/Apr/2014:20:49:05 +0300] "REPORT /cal.php/calendars/myuser/default/ HTTP/1.1" 207 27535
Hi, that's perfectly reasonable (and events with, say, less than a month past-due indeed do show up immediately). What is a bit confusing is that much earlier events do show up anyway after waiting a short time - just not immediately. Perhaps some consistency (either loading everything right from the start, or not loading events older than the 'globalEventStartPastLimit' limit at all - except maybe at a specific request of clicking a "load older/all todos" button) would be preferable? It's clearly not a big issue of course... Regards, Attila
On 23-Apr-2014 16:31, Andrej Lezo wrote:
Hi Attila, thanks for your attachment. The reason why you don't see your to-do from last year is because we use time range filtering for todo/event loading (Calendar-query) to minimalize server traffic. So we are loading todos which are after start of that time range. Unfortunately there is no such thing as using of time range filter in combination with STATUS=NEEDS-ACTION filter in logical "OR" relation (http://tools.ietf.org/html/rfc4791#section-7.8). But you can extend the start of your time range by setting globalEventStartPastLimit variable to bigger number in config.js file. Default value is 3. Regards, Andrej Dňa 22. 4. 2014 22:06 Attila Asztalos wrote / napísal(a):
Hi Attila, it seems that your server supports Calendar-query reuqests but no sync-collection requests. It results in performing of PROPFIND requests so every event is loaded. Could you create a demo account for me and send credentials on my email? I can check whole behaviour and make potential fix. Thanks in advance Regards, Andrej Dňa 2. 5. 2014 13:55 Attila Asztalos wrote / napísal(a):
Hi, that's perfectly reasonable (and events with, say, less than a month past-due indeed do show up immediately). What is a bit confusing is that much earlier events do show up anyway after waiting a short time
- just not immediately. Perhaps some consistency (either loading
everything right from the start, or not loading events older than the 'globalEventStartPastLimit' limit at all - except maybe at a specific request of clicking a "load older/all todos" button) would be preferable? It's clearly not a big issue of course... Regards, Attila
On 23-Apr-2014 16:31, Andrej Lezo wrote:
Hi Attila, thanks for your attachment. The reason why you don't see your to-do from last year is because we use time range filtering for todo/event loading (Calendar-query) to minimalize server traffic. So we are loading todos which are after start of that time range. Unfortunately there is no such thing as using of time range filter in combination with STATUS=NEEDS-ACTION filter in logical "OR" relation (http://tools.ietf.org/html/rfc4791#section-7.8). But you can extend the start of your time range by setting globalEventStartPastLimit variable to bigger number in config.js file. Default value is 3. Regards, Andrej Dňa 22. 4. 2014 22:06 Attila Asztalos wrote / napísal(a):
Hi, I'd love to, but as I already mentioned earlier in this thread this is not an internet-facing setup, it works on LAN only, and it's not even powered up most of the time. I'll happily run whatever test you can think of or send you any log / config file you might need, but making it externally accessible is not really an option right now. Anyway, it's a standard Baikal-on-Apache setup, nothing special about it. Regards, Attila
On 2-May-2014 15:34, Andrej Lezo wrote:
Hi Attila, it seems that your server supports Calendar-query reuqests but no sync-collection requests. It results in performing of PROPFIND requests so every event is loaded. Could you create a demo account for me and send credentials on my email? I can check whole behaviour and make potential fix. Thanks in advance Regards, Andrej Dňa 2. 5. 2014 13:55 Attila Asztalos wrote / napísal(a):
Hi, that's perfectly reasonable (and events with, say, less than a month past-due indeed do show up immediately). What is a bit confusing is that much earlier events do show up anyway after waiting a short time
- just not immediately. Perhaps some consistency (either loading
everything right from the start, or not loading events older than the 'globalEventStartPastLimit' limit at all - except maybe at a specific request of clicking a "load older/all todos" button) would be preferable? It's clearly not a big issue of course... Regards, Attila
On 23-Apr-2014 16:31, Andrej Lezo wrote:
Hi Attila, thanks for your attachment. The reason why you don't see your to-do from last year is because we use time range filtering for todo/event loading (Calendar-query) to minimalize server traffic. So we are loading todos which are after start of that time range. Unfortunately there is no such thing as using of time range filter in combination with STATUS=NEEDS-ACTION filter in logical "OR" relation (http://tools.ietf.org/html/rfc4791#section-7.8). But you can extend the start of your time range by setting globalEventStartPastLimit variable to bigger number in config.js file. Default value is 3. Regards, Andrej Dňa 22. 4. 2014 22:06 Attila Asztalos wrote / napísal(a):
Hi, in that case could you send me a log file with every request performed including requests for synchronization? I can check that and find out exact order of performing ajax calls. Thanks Regards, Andrej Dňa 2. 5. 2014 17:14 Attila Asztalos wrote / napísal(a):
Hi, I'd love to, but as I already mentioned earlier in this thread this is not an internet-facing setup, it works on LAN only, and it's not even powered up most of the time. I'll happily run whatever test you can think of or send you any log / config file you might need, but making it externally accessible is not really an option right now. Anyway, it's a standard Baikal-on-Apache setup, nothing special about it. Regards, Attila
On 2-May-2014 15:34, Andrej Lezo wrote:
Hi Attila, it seems that your server supports Calendar-query reuqests but no sync-collection requests. It results in performing of PROPFIND requests so every event is loaded. Could you create a demo account for me and send credentials on my email? I can check whole behaviour and make potential fix. Thanks in advance Regards, Andrej Dňa 2. 5. 2014 13:55 Attila Asztalos wrote / napísal(a):
Hi, that's perfectly reasonable (and events with, say, less than a month past-due indeed do show up immediately). What is a bit confusing is that much earlier events do show up anyway after waiting a short time - just not immediately. Perhaps some consistency (either loading everything right from the start, or not loading events older than the 'globalEventStartPastLimit' limit at all - except maybe at a specific request of clicking a "load older/all todos" button) would be preferable? It's clearly not a big issue of course... Regards, Attila
On 23-Apr-2014 16:31, Andrej Lezo wrote:
Hi Attila, thanks for your attachment. The reason why you don't see your to-do from last year is because we use time range filtering for todo/event loading (Calendar-query) to minimalize server traffic. So we are loading todos which are after start of that time range. Unfortunately there is no such thing as using of time range filter in combination with STATUS=NEEDS-ACTION filter in logical "OR" relation (http://tools.ietf.org/html/rfc4791#section-7.8). But you can extend the start of your time range by setting globalEventStartPastLimit variable to bigger number in config.js file. Default value is 3. Regards, Andrej Dňa 22. 4. 2014 22:06 Attila Asztalos wrote / napísal(a):
-
Andrej Lezo -
Attila Asztalos -
Ján Máté