Closed
Bug 350603
Opened 18 years ago
Closed 15 years ago
Drag'n'drop of all day events in week view not possible
Categories
(Calendar :: Calendar Frontend, enhancement)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: sebo.moz, Unassigned)
References
Details
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.
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 1•18 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1 BuildId: 2007011603
Comment 3•15 years ago
|
||
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•15 years ago
|
||
Does this occur in 1.0pre? I've fixed a similar bug just recently.
Comment 5•15 years ago
|
||
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
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
Comment 6•15 years ago
|
||
I can not reproduce the problem in Lightning 1.0pre. The bug is fixed.
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•