Closed Bug 1727123 Opened 5 years ago Closed 4 years ago

Reminders of appointments that were created by others in connection with a CalDAV calendar cannot be closed.

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Product:
Calendar
Component:
E-mail based Scheduling (iTIP/iMIP)
Version:
Thunderbird 91
Type:
defect

Tracking

(thunderbird_esr91+ wontfix, thunderbird103?)

Status:
RESOLVED FIXED
Milestone:
100 Branch
Tracking Flags:
Tracking Status
thunderbird_esr91 + wontfix
thunderbird103 ? ---

People

(Reporter: a.guerler, Assigned: lasana)

References

Details

Attachments

(1 file)

Bug 1727123 - Ignore alarms for repeating events we cannot modify. r=darktrojan
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Steps to reproduce:

  1. Subscribe to a CALDAV calendar.
  2. Have someone else create an appointment in the previously subscribed CALDAV calendar to which you will be invited. Make sure you are not the owner of the event entry.
  3. Let Thunderbird remind you of the appointment as an invited person.
  4. Try to close the reminder window.

Actual results:

The appointment reminder window does not close.

Expected results:

The reminder window should close after clicking the button provided.

Component: Untriaged → E-mail based Scheduling (iTIP/iMIP)
Product: Thunderbird → Calendar

Confirm, same issue here.

Hello Ali Guerler,

Are you able to indicate which caldav service provider you are using?

Flags: needinfo?(a.guerler)

Hello Ali Guerler,

Are you able to indicate which caldav service provider you are using?

Yes, it's a calendar module of eGroupware, you can find it on https://www.egroupware.org/en

Flags: needinfo?(a.guerler)

(In reply to Ali Guerler from comment #7)

Hello Ali Guerler,

Are you able to indicate which caldav service provider you are using?

Yes, it's a calendar module of eGroupware, you can find it on https://www.egroupware.org/en

I've seen this happen with only one person at my org. I forget which bug I once opened or commented in for a similar issue.

In my case, I have a Mac user creating the event in Webmail GMail (using Chrome, I think). I'll get their invite, accept and the day of the event the event will fire off in TB and it then cannot be dismissed no matter how many times you press Dismiss. In order to dismiss it, I have to log into my Webmail GMail and manually delete the event from my calendar and re-sync the calendar in TB for it to disappear.

So far this looks like an error in the parser. For some reason the request sent for recurring invitations contains two events, the parent event and the event being dismissed.
Serialization takes place here which seems to produce the wrong ics:
https://searchfox.org/comm-central/rev/7a0e536f6bbef48d2bd17a410017f2d5ac5e4b0a/calendar/providers/caldav/CalDavCalendar.jsm#723

Further analysis of the parsing code is needed to figure out what's going wrong.

Assignee: nobody → lasana
Status: UNCONFIRMED → NEW
Ever confirmed: true

Thank you Lasana. You are doing important work here!

Ok comment 11 is wrong. I made an exception to the event I was testing with unintentionally. I analyzed the network traffic and workflow with both a properly working repeating event I created and one automatically added to the calendar from an invitation. My previous analysis about this being server seems more accurate. Seems like these invitations are immutable on some servers and if they have alarms attached, then we can't dismiss them because we modify the event to record the dismissal.

I think at this point the best thing for us to do is recognize our changes never happened and ignore the alarms for somehow. Long term, I think we should stop relying on the servers to store event metadata completely, that may have side-effects that need to be considered as well though.

I tried fixing this by first:

Instead of storing the alarm acknowledgment on the parent item, create an exception for the date being dismissed. This seemed to work well but when you click "Dismiss All" I eventually hit a 403 error with Google calendar. We dismiss the alarms one by one without waiting on the result so I noticed some weird UI stuff going on as well. Furthermore, for events with a lot of alarms this will probably generate too much traffic so I abandoned this approach.

I came to the conclusion that the best thing we could do right now is to take note that we can't modify the parent event for some reason and ignore the alarm. Right now that only lasts for the session so the alarm will return on restart, it would be nice if we could keep track of event alarms to ignore somehow but that's tricky with the uncached calendars that store in memory.

Maybe we could store the event ids in a pref or as a calendar property?

Status: NEW → ASSIGNED

Hmm, looks like calendar properties are already stored as prefs, we could probably persist the ignored alarms in there.

Keywords: checkin-needed-tb
Target Milestone: --- → 100 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/5943d54eff77
Ignore alarms for repeating events we cannot modify. r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

(In reply to Wayne Mery (:wsmwk) from comment #2)

Reporter, do you still see this issue?
beta 100 has a fix from Bug 1727123 - Reminders of appointments that were created by others in connection with a CalDAV calendar cannot be closed.

Yes, the behavior has changed, but still persists in beta 100:

  • Click on Dismiss All now works, but does not dismiss notifications, just refreshes the list back with the old list.
  • Dismissing a single notification now does work, it didn't before. With hundreds of notifications, this doesn't really help, we still need Dismiss All functionality.

Thanks

Not uplifting this because it relies on the promise based changes in bug 1693873.

status-thunderbird_esr91: affected → wontfix

(In reply to github from comment #19)

(In reply to Wayne Mery (:wsmwk) from comment #2)

Reporter, do you still see this issue?
beta 100 has a fix from Bug 1727123 - Reminders of appointments that were created by others in connection with a CalDAV calendar cannot be closed.

Yes, the behavior has changed, but still persists in beta 100:

  • Click on Dismiss All now works, but does not dismiss notifications, just refreshes the list back with the old list.
  • Dismissing a single notification now does work, it didn't before. With hundreds of notifications, this doesn't really help, we still need Dismiss All functionality.

Thanks

That's strange, the "Dismiss All" button more or less calls dismissAlarm on each of the alarms displayed. What do you see in the error console when you click "Dismss All"?

I tried reproducing the issue on 100.0b2 and it does not happen, at least for the recurring gmail invitations issue. There are unfortunately, many different ways dismissing alarms can fail with caldav servers because we rely on the server to keep our X-MOZ properties intact. The server could silently update the entire event without us realizing for example.

If anyone is still running into these issues I'm going to need as much information as you can to hunt down the problem. At the very least:

  1. The Caldav provider/server you are using.
  2. Was the event created as an invitation or regular event?
  3. Is the calendar you are subscribed to read-only?
  4. If possible, a copy of the event from thunderbird as well as the invitation if applicable.
  5. How you added the calendar (auto-discovery, calendar url etc.).

For users using their own servers (ie not Gmail,Fastmail etc.) be aware that it's hard to know what the servers might be doing without access.
It's possible some servers may be ignoring updates from TB without sending the right http status code for example.
If the nature of the calendar with the offending event is not sensitive and you are able to share it that will help
tremendously.

It seems the issue was with a bunch of old reminders, that were ignored for more than a month, like about 20 of them. When they were ignored one by one individually, a new reminders started working with Dismiss All. So my issues seems to be solved.

Except one itsy-bitsy feature request: how about the dialog closes after all reminders are dismissed? Please, pretty please. Thanks!

(In reply to Lasana Murray from comment #23)

I tried reproducing the issue on 100.0b2 and it does not happen, at least for the recurring gmail invitations issue. There are unfortunately, many different ways dismissing alarms can fail with caldav servers because we rely on the server to keep our X-MOZ properties intact. The server could silently update the entire event without us realizing for example.

This appears to be ok now as of TB 101 b1.

And back as of 101.0b4.

This behavior has returned in 103.0b4, not able to dismiss notifications neither with "Dismiss" or "Dismiss all"

https://bugzilla.mozilla.org/show_bug.cgi?id=1745917

tracking-thunderbird103: --- → ?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: