User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20060508 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 The behavior is different when changing different aspects of the time / date. I managed to see three different behaviors: - Event overwritten - Extra event created when changing the date - Event overwritten and duplicate alarm appearing in the "Calendar Alarm" list In all cases, however, the time was changed back when dismissing the event. Reproducible: Always Steps to Reproduce: 1. Create an event with an alarm 2. Wait until the alarm is fired 3. Change the event alarm time 4. Dismiss the alarm Actual Results: The alarm time is set to what it was at step 2. Expected Results: The alarm time is unchanged.
What version of Sunbird or Lightning do you use? If you use an older version or the obsolete Calendar extension: Does the problem still exist in Sunbird 0.3 alpha2 build?
I'm using 0.3a2. Sorry for forgetting that.
OK, I can see how this would happen. There are 2 bugs here. First, the provider should be throwing since we're trying to modify an old copy of an event. Second, we need to handle the case where modifications of an event happen between the alarm-fire time and the alarm-dismiss time. Perhaps it's time to exercise getItem() to get an up-to-date copy?
Status: UNCONFIRMED → NEW
Component: General → Alarms
Ever confirmed: true
jminta: Did you fix this with the updated alarm dialog?
WFM now with Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:188.8.131.52pre) Gecko/20071006 Sunbird/0.7
As far as I see this should be fixed by Bug 389245. Or is there a use case left that still triggers the issue?
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.