Closed
Bug 396865
Opened 17 years ago
Closed 17 years ago
WCAP only: Alarm setting for Tasks corrupted
Categories
(Calendar :: Tasks, defect)
Calendar
Tasks
Tracking
(Not tracked)
RESOLVED
FIXED
0.7
People
(Reporter: ulf.stroehler, Assigned: ulf.stroehler)
Details
Attachments
(1 file)
1.60 KB,
patch
|
michael.buettner
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 ID:2007072816 Lightning Version 0.7.9.2007092008 Note ==== The following bug description applies only to WCAP Calendars. Other providers remain innocent: STR === 1. select WCAP Calendar 2. choose "File" -> "New" -> "Task..." 3. set "Reminder" to "5 minutes before" => (Start Time automatically gets checked and set to current time) 4. hit "Save and Close" Actual Result ============= The Reminder is set to "Custom..." "0 day after the event starts" Expected Result =============== 1. Reminder setting should stick to "5 minutes before" 2. Alarm should be fired right after hitting "Safe and Close" Reproducible ============ Always
Comment 1•17 years ago
|
||
Does alarms work with WCAP calendars now? -> Bug 380423
Assignee | ||
Comment 2•17 years ago
|
||
in reply to Comment #1: as a result of Bug 380423 only pop-up alarms are disabled, but email reminder should still work flawlessly.
Comment 3•17 years ago
|
||
The alarm offset is initialized as expected by the dialog, but gets lost during the roundtrip (results in an zero offset). It's definitely something that gets screwed up in the back-end -> reassigning to daniel.
Assignee: michael.buettner → daniel.boelzle
Comment 4•17 years ago
|
||
Reading the WCAP logs, CS seems to be the problem: The alarm offset doesn't get saved if you don't specify a DUE date: [calWcapNetworkRequest id=5dce41fc-aea5-4175-b085-b89af96361c3-152, parent-id=5dce41fc-aea5-4175-b085-b89af96361c3-151 (https://cal-emea.sun.com/storetodos.wcap?appid=mozilla-calendar&id=xyz&dtstart=20070920T132204Z&X-NSCP-DTSTART-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-REPLACE^Europe%2FParis&due=0&X-NSCP-DUE-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-DELETE^&isAllDay=0&rrules=&rdates=&exrules=&exdates=&orgCalid=db93792&summary=New%20Task&categories=&desc=&location=&icsUrl=&priority=0&icsClass=PUBLIC&status=3&transparent=0&percent=0&completed=0&attachments=&alarmStart=-PT5M&alarmEmails=Daniel.Boelzle%40Sun.COM&tzid=Europe%2FParis&storetype=1&mod=4&method=1&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=db93792), isPending=true, status=NS_OK] contentCharset = UTF-8 request result: BEGIN:VCALENDAR ... BEGIN:VALARM ACTION:EMAIL TRIGGER:-PT SUMMARY:Reminder: New Task ATTENDEE:MAILTO:Daniel.Boelzle@Sun.COM END:VALARM ... Ulf, could you figure out whether a corresponding bug already exists else file a new one against cs, please?
Comment 5•17 years ago
|
||
A workaround may be to enforce DUE (being set to DTSTART), although this somehow falsifies the todo.
Attachment #281650 -
Flags: review?(michael.buettner)
Comment 6•17 years ago
|
||
Comment on attachment 281650 [details] [diff] [review] workaround: enforcing DUE (set to DTSTART) > var dtstart = item.entryDate; > var dtend = item.dueDate; >+ >+ // cs bug: enforce DUE (set to DTSTART) if alarm is set >+ if (!dtend && item.alarmOffset) { >+ dtend = item.entryDate; better be just "dtend = dtstart;" of course
Comment 7•17 years ago
|
||
Comment on attachment 281650 [details] [diff] [review] workaround: enforcing DUE (set to DTSTART) >+ if (!dtend && item.alarmOffset) { >+ dtend = dtstart; >+ } You were faster than me :-) Yes, but apart from that, I'm shuddering and *eyes closed* (again), r=mickey.
Attachment #281650 -
Flags: review?(michael.buettner) → review+
Comment 8•17 years ago
|
||
(In reply to comment #7) > You were faster than me :-) Yes, but apart from that, I'm shuddering and *eyes > closed* (again), r=mickey. Yes, but do we have other options? IMO this cs workaround is not too invasive, but I admit, it's (again) another hack/workaround. Checked in on HEAD and MOZILLA_1_8_BRANCH. Reassigning to Ulf: please keep track of filing a bug, then resolve this one.
Assignee: daniel.boelzle → ulf.stroehler
Updated•17 years ago
|
Target Milestone: --- → 0.7
Version: Trunk → unspecified
Assignee | ||
Comment 9•17 years ago
|
||
fix seems to regress: * wcap email reminders stopp working for tasks * display of recurring rule wrong for wcap tasks: Example: repeating weekly gets changed to "Custom" and the rule is displayed as "Occurs every "$CurrentWeekDay" effective "$CurrentDate" from "$Current Time" to "$Current Time"" Reassigning back to Daniel (reason: fix regresses).
Assignee: ulf.stroehler → daniel.boelzle
Assignee | ||
Comment 10•17 years ago
|
||
Apologies: assumed regressions mentioned in Comment #9 do not seem to be reproducible. No idea what happened in the mean time - may be it was some kind of wcap server hiccup. Reassigning back to myself.
Assignee: daniel.boelzle → ulf.stroehler
Comment 11•17 years ago
|
||
Can this bug be resolved?
Comment 12•17 years ago
|
||
Ulf, have you filed a bug against CS (comment #8)?
Assignee | ||
Comment 13•17 years ago
|
||
workarounded in 0.7 and iplanet calendar server wcap Bug filed as requested: CR 6631547.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•