Tickets :: [#5736] shared calendar alarms shouldn't be exported through webdav

6.0.0-beta1

9/22/25

Summary	shared calendar alarms shouldn't be exported through webdav
Queue	Kronolith
Queue Version	HEAD
Type	Enhancement
State	Resolved
Priority	1. Low
Owners	jan (at) horde (dot) org
Requester	munzli (at) olmero (dot) ch
Created	09/24/2007 (6573 days ago)
Due
Updated	05/01/2008 (6353 days ago)
Assigned	09/24/2007 (6573 days ago)
Resolved	11/20/2007 (6516 days ago)
Milestone
Patch	No

05/01/2008 10:10:47 PM	Jan Schneider	Comment #9	Reply to this comment
Please create a new request for this.

04/21/2008 03:43:48 PM	munzli (at) olmero (dot) ch	Comment #8	Reply to this comment
We can't determine the difference between dismissing an alarm, and disabling an alarm, if the client doesn't. Or does sunbird do anything different? well sunbird/lightning publishes the VALARM with an X option: X-MOZ-LASTACK:20080421T153603Z if dismissed and: X-MOZ-SNOOZE-TIME:20080421T155109Z when the alarm get's snoozed (the time is the next reminder time afaik), this option is in the VEVENT parent and not in the VALARM

02/25/2008 07:01:03 PM	Jan Schneider	Comment #7	Reply to this comment
We can't determine the difference between dismissing an alarm, and disabling an alarm, if the client doesn't. Or does sunbird do anything different?

02/25/2008 03:47:16 PM	munzli (at) olmero (dot) ch	Comment #6	Reply to this comment
I still don't see why snoozing alarms through external client should be prohibited, but changing private events or event owners is fixed now. bacause the owner might not want his event to be dismissed. they'd have to be dismissed on a user basis so that every user that has a shared calender can dismiss an event, but everybody else still get's the alarm.

11/20/2007 04:52:08 PM	Jan Schneider	Comment #5 State ⇒ Resolved	Reply to this comment
I still don't see why snoozing alarms through external client should be prohibited, but changing private events or event owners is fixed now.

10/08/2007 09:10:12 AM	munzli (at) olmero (dot) ch	Comment #4	Reply to this comment
oh and i'm talking about alarms from shared calendars, your own alarms are fine, it's just those of shared calendars

10/08/2007 09:08:12 AM	munzli (at) olmero (dot) ch	Comment #3	Reply to this comment
Are you dismissing the alarms through the external client? I don't see any reason why we shouldn't export alarms. yes i am. and they don't get dismissed. and if the calendar is writable the owner and title change! this should not happen, especially on private events the title is changed to "Private Event...."

10/05/2007 03:25:23 PM	Jan Schneider	Comment #2 State ⇒ Feedback Taken from Horde Developers	Reply to this comment
Are you dismissing the alarms through the external client? I don't see any reason why we shouldn't export alarms.

09/24/2007 06:54:40 PM	Chuck Hagenbuch	Assigned to Jan Schneider State ⇒ Assigned Assigned to Horde Developers

09/24/2007 09:58:11 AM	munzli (at) olmero (dot) ch	Comment #1 Priority ⇒ 1. Low Type ⇒ Enhancement Summary ⇒ shared calendar alarms shouldn't be exported through webdav Queue ⇒ Kronolith State ⇒ New	Reply to this comment
people that have shared calendars open in third party applications (for example sundbird/lightning) receive alarms for calendars that are shared by other people. if they use the normal ics export they can't dismiss the alarms. if they use the webdav interface and have write permissions on the calendar the events automaticly change the owner as soon as they dismiss the alarm. for private events this even changes the description to "Private Event from ...." and the original description is lost! IMHO shared calendars shoudln't contain the alarms.