empty/blank status of calendar task

RESOLVED FIXED in 1.0b1

Status

defect
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: aryx, Assigned: Fallen)

Tracking

Trunk
1.0b1
Bug Flags:
blocking-calendar1.0 +

Details

Attachments

(2 attachments, 1 obsolete attachment)

Posted file testcase β€”
Tested with

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090219 Calendar/1.0pre

and

yesterday's nightly (20090309):

Had the attached task in a sqlite calendar, editing it showed its status as blank. This also happens if you open the calendar (= ics) in a new profile.
This blocks if confirmed.
Flags: blocking-calendar1.0+
Comment on attachment 366546 [details]
testcase

>STATUS:CONFIRMED

Did you created this task from an event? CONFIRMED is not specified for tasks:

From RFC 2445 Chapter 3.8.1.11. Status:
[[[
  statvalue-event = "TENTATIVE"    ;Indicates event is tentative.
                  / "CONFIRMED"    ;Indicates event is definite.
                  / "CANCELLED"    ;Indicates event was cancelled.
  ;Status values for a "VEVENT"

  statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
                  / "COMPLETED"    ;Indicates to-do completed.
                  / "IN-PROCESS"   ;Indicates to-do in process of.
                  / "CANCELLED"    ;Indicates to-do was cancelled.
  ;Status values for "VTODO".
]]]
<http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-09#section-3.8.1.11>
Probably, also possible that it was once a task, than convert to an event and later the other way. Or only event > task, don't remember.
Posted patch Fix - v1 (obsolete) β€” β€” Splinter Review
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #367426 - Flags: review?(ssitter)
As supposed: The issue can be reproduced by converting event/task to task/event. In both cases the status is just copied, e.g. you get an event with status NEEDS-ACTION - and no entry selected in the corresponding menu.

In addition to the task fallback added with the patch there should be a similar fallback for events.

And maybe the conversion should map the status during conversion, e.g.
TENTATIVE <-> NEEDS-ACTION
CONFIRMED <-> COMPLETED
CONFIRMED <-- IN-PROCESS
CANCELLED <-> CANCELLED
Posted patch Fix - v2 β€” β€” Splinter Review
I agree we should convert the status values, but I'm not quite sure of the map yet. My proposal here, with comments for changes.

Event -> Task:
TENTATIVE --> NEEDS-ACTION
CONFIRMED --> IN-PROCESS (A definitive Event is not a completed task)
CANCELLED <-> CANCELLED

Task -> Event:
NEEDS-ACTION --> TENTATIVE
COMPLETED    --> CONFIRMED (Not sure here. I'd actually say CANCELLED, since its
                         already done, but could that cause confusion?
IN-PROCESS   --> CONFIRMED
CANCELLED    <-> CANCELLED

I admit this will change values if you convert a task -> event -> task, but I think this is inevitable also for other fields.
Attachment #367426 - Attachment is obsolete: true
Attachment #367468 - Flags: review?(ssitter)
Attachment #367426 - Flags: review?(ssitter)
Comment on attachment 367468 [details] [diff] [review]
Fix - v2

r=ssitter
Attachment #367468 - Flags: review?(ssitter) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5b7638646d00>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → 1.0
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.