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

VERIFIED WORKSFORME

Status

Calendar
Calendar Views
--
enhancement
VERIFIED WORKSFORME
11 years ago
9 years ago

People

(Reporter: Sebastian Schwieger, Unassigned)

Tracking

Details

(Reporter)

Description

11 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

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

BuildId: 2007011603

Updated

11 years ago
Duplicate of this bug: 372357

Comment 3

9 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>"
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
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME

Comment 6

9 years ago
I can not reproduce the problem in Lightning 1.0pre. The bug is fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.