| Summary | shared calendar alarms shouldn't be exported through webdav |
| Queue | Kronolith |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Resolved |
| Priority | 1. Low |
| Owners | Jan Schneider <jan (at) horde (dot) org> |
| Requester | munzli (at) olmero (dot) ch |
| Created | 09/24/2007 (230 days ago) |
| Due | |
| Updated | 05/01/2008 (10 days ago) |
| Assigned | 09/24/2007 (230 days ago) |
| Resolved | 11/20/2007 (173 days ago) |
| Attachments | |
| Milestone | |
| Patch |
Please create a new request for this.> 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
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?> 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.
State ⇒ Resolved
I still don't see why snoozing alarms through external client should be prohibited, but changing private events or event owners is fixed now.oh and i'm talking about alarms from shared calendars, your own alarms are fine, it's just those of shared calendars> 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...."
Taken from
State ⇒ Feedback
Are you dismissing the alarms through the external client?I don't see any reason why we shouldn't export alarms.
Assigned to Jan Schneider
Assigned to
Priority ⇒ 1. Low
Queue ⇒ Kronolith
Type ⇒ Enhancement
Summary ⇒ shared calendar alarms shouldn't be exported through webdav
State ⇒ New
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.