User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060829 BonEcho/2.0b2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060828 Calendar/0.3a2+ Drag'n'drop of all day events is possible in month view and multiweek view but *not* in week view. Reproducible: Always Steps to Reproduce: 1.Create All day event 2.change to week view 3.try to drag the event to another day Actual Results: no dragging possible Expected Results: drag'n'drop should be possible.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1 BuildId: 2007011603
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:22.214.171.124) Gecko/20081209 Lightning/0.9 Thunderbird/126.96.36.199 The error is caused by a malformed condition in the PUT request. This is the head of the request that is sended to a CalDAV backend when we follows the specified steps: host = "localhost:8080" user-agent = "Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:188.8.131.52) accept = "text/xml" accept-language = "es-es,es;q=0.8,en-us;q=0.5,en;q=0.3" accept-encoding = "gzip,deflate" accept-charset = "utf-8,*;q=0.1" keep-alive = "300" connection = "keep-alive" content-length = "440" content-type = "text/calendar; charset=utf-8" if-none-match = "*" pragma = "no-cache" cache-control = "no-cache" ... The condition that is sended (if-none-match = "*"), is used to create new elements, no to modify them. In that case, where we can modify an existing event, the condition of the request (if-none-match = "*") must be similar to: if-match = "<current-etag-element-in-client>"
Does this occur in 1.0pre? I've fixed a similar bug just recently.
Original bug is WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090415 Lightning/1.0pre (20090415) Shredder/3.0b3pre. Jose, your issue from comment#3 is a separate one, and from a quick glance at the CalDAV code everything seems to be correct. doAdoptItem and doModifyItem use the conditions as you described in your comment. Please, open a _new_ bug if you can reproduce the behavior in Lightning 1.0pre. -> Resolving WORKSFORME
I can not reproduce the problem in Lightning 1.0pre. The bug is fixed.