Last Comment Bug 308538 - Foreign X-Props in VALARMs are lost during roundtrip
: Foreign X-Props in VALARMs are lost during roundtrip
: dataloss
Product: Calendar
Classification: Client Software
Component: Internal Components (show other bugs)
: Trunk
: All All
-- normal (vote)
: 1.0b1
Assigned To: Philipp Kewisch [:Fallen]
Depends on: 298358
  Show dependency treegraph
Reported: 2005-09-14 12:20 PDT by Dan Mosedale (:dmose)
Modified: 2010-02-04 11:05 PST (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

308538 (30.70 KB, text/plain)
2009-05-18 22:08 PDT,
no flags Details

Description User image Dan Mosedale (:dmose) 2005-09-14 12:20:18 PDT
Currently, VALARMs are serialized without an ACTION property, which is required
by RFC 2445.  This means that modifying an ICS calendar created by another app
which has VALARMs will corrupt any VALARMs there.
Comment 1 User image Dan Mosedale (:dmose) 2005-12-13 12:50:22 PST
Reassigning to Joey, since he owns the dependent bug which will cause this to be fixed.
Comment 2 User image Joey Minta 2006-06-30 11:45:18 PDT
After Bug 315051 we now serialize with an ACTION property.  We'll still lose x-props from foreign alarms though.
Comment 3 User image Dan Mosedale (:dmose) 2006-09-11 17:52:24 PDT
I kinda suspect that this is fixed now.
Comment 4 User image Joey Minta 2006-09-11 17:54:47 PDT
(In reply to comment #3)
> I kinda suspect that this is fixed now.
Nope, we need to replicate the general fix for alarm components too.
Comment 5 User image Dan Mosedale (:dmose) 2006-09-12 13:10:59 PDT
iCal and Evolution appear to use X- properties, so this probably needs to block.  We'd like to see a low-risk fix though, which seems likely to mean something less correct than splitting of calIAlarm.
Comment 6 User image Dan Mosedale (:dmose) 2006-09-19 11:21:37 PDT
jminta thinks that the properties used by Evolution and iCal here wouldn't actually be missed if they were lost.  Waiting on more analysis...
Comment 7 User image Joey Minta 2006-09-19 15:29:01 PDT
(In reply to comment #6)
> Waiting on more analysis...
My argument here is not that the way they use them isn't interesting (it's nearly identical to our method), but rather that the way people use multiple calendaring apps isn't interesting.  This bug only becomes meaningful in the case that people repeatedly edit the same data-source from multiple applications, in which case the data about missed alarms may be lost.  Given that no one has reported a bug about 'dismissed alarms in other apps re-fired after sunbird edit,' this tells me that this usage case is rare, if not non-existent.

Comment 8 User image Dan Mosedale (:dmose) 2006-09-19 16:11:01 PDT
That seems like sound reasoning to me.  Removing from the blocker list.
Comment 9 User image Matthew (lilmatt) Willis 2006-09-24 14:45:46 PDT
When we do get around to fixing this, we should probably break the X-props thing out so that VCALENDAR, VTIMEZONE, VEVENT/VTODO, and VALARM can each use it and each have their own bag. That seems like the only way to preserve and round-trip X-PROPS at each level.
Comment 10 User image Matthew (lilmatt) Willis 2007-03-23 16:37:42 PDT
Not going to make the 0.5 train.
Comment 11 User image Simon Paquet [:sipaq] 2007-06-06 09:42:44 PDT
Moving bugs from Joey without a patch back to nobody, since Joey has basically left the project.
Comment 12 User image Simon Paquet [:sipaq] 2007-08-09 09:21:19 PDT
Given our tight schedule and the fact that the Calendar devs already have too
much on their plate for 0.7, this is unlikely to make it for 0.7 unless someone
steps up and finishes this.
Comment 13 User image Philipp Kewisch [:Fallen] 2008-01-06 05:34:04 PST
Bug 353492 will probably fix this, since a whole new calIAlarm interface will be added that saves x-props.
Comment 14 User image Philipp Kewisch [:Fallen] 2009-03-16 02:27:52 PDT
Fixed by bug 471973.
Comment 15 User image Bas van den Bosch 2009-03-16 22:51:11 PDT
judging comment 5 : does the new alarm-interface store x-props in alarms? This would solve the problem with dimissing one alarm dismisses all alarms as noticed in bug 353492.
Comment 16 User image Philipp Kewisch [:Fallen] 2009-03-19 11:38:15 PDT
It stores x-props, but I believe we don't store the last-ack in the valarm but rather on the item itself. As noted in the bug you mentioned, I'm not quite sure we even need to let the user dismiss multiple alarms for the same event separately if we are smart about how we display the alarm.
Comment 17 User image 2009-05-18 22:08:05 PDT
Created attachment 378253 [details]

Note You need to log in before you can comment on or make changes to this bug.