350603 - Drag'n'drop of all day events in week view not possible

Status: VERIFIED WORKSFORME

(Calendar :: Calendar Frontend, enhancement)

Description

[Sebastian Schwieger]

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.

Comment 1

[Paul Ivanov]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1

BuildId: 2007011603

Comment 3

[Fco. Jose Mulero]

User-Agent:      Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.19) Gecko/20081209 Lightning/0.9 Thunderbird/2.0.0.19

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:1.8.1.19)  
  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>"

Comment 4

[Philipp Kewisch [:Fallen][☁️📆]]

Does this occur in 1.0pre? I've fixed a similar bug just recently.

Comment 5

[Martin Schröder [:mschroeder]]

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

Comment 6

[Fco. Jose Mulero]

I can not reproduce the problem in Lightning 1.0pre. The bug is fixed.