Closed Bug 396865 Opened 17 years ago Closed 17 years ago

WCAP only: Alarm setting for Tasks corrupted

Categories

(Calendar :: Tasks, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ulf.stroehler, Assigned: ulf.stroehler)

Details

Attachments

(1 file)

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
Does alarms work with WCAP calendars now? -> Bug 380423
in reply to Comment #1:

as a result of Bug 380423 only pop-up alarms are disabled, but email reminder should still work flawlessly.
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
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?
A workaround may be to enforce DUE (being set to DTSTART), although this somehow falsifies the todo.
Attachment #281650 - Flags: review?(michael.buettner)
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 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+
(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
Target Milestone: --- → 0.7
Version: Trunk → unspecified
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
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
Can this bug be resolved?
Ulf, have you filed a bug against CS (comment #8)?
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.