Open Bug 1140035 Opened 10 years ago Updated 1 year ago

alarms only work for a maximum of 30 days before/after the event even if set higher

Categories

(Calendar :: Alarms, defect)

Lightning 3.3
defect

Tracking

(Not tracked)

People

(Reporter: post, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 2015022000 Steps to reproduce: Create a new event say 35 days in the future and set an alarm to remind you 34 days before the event starts. Actual results: The alarm will remind you in 5 days, i.e. 30 days before the event not 34 days. Expected results: The alarm should have been after one day not five. This is a major bug since the user is allowed to set higher numbers than 30 days as alarms and trust that thunderbird will stick to that. Without knowing about this, the user can miss important appointments.
Correct, Lightning checks only one month in the past and future for reminders on purpose due to performance reasons. See the German post at https://www.thunderbird-mail.de/index.php/Thread/68443-Terminerinnerung-40-Tagen-vor-Terminbeginn-meldet-sich-erst-30-Tage-vor-Terminbe/ for some steps on how to modify this behavior in Lightning.
Thank you for this useful information. But it is still a dangerous bug since the user expects some other behavior. I personally needed to be reminded 90 days ahead which was not happening. To summarize the workaround in English: Search for the file calAlarmService.js in your thunderbird profile directory and change the 1 in the lines (there are several) "until.month += 1" to the amount of months you want the calendar to look in the future. There are several ways to fix this. Either one provides a user setting for this number and print a warning if the user creates an event with a reminder out of this range. But this will not help if the event was created by another program and was synchronized to thunderbird unless one would hook this warning to the synchronization process. Or one creates a hash table for a reverse lookup (input: day x; output: list of events with a reminder for day x). This would scale much better but the entries need to be created/updated also after synchronization with an external calendar.
Philipp, do you think that adding an hidden preference (maybe with an unsurmountable upper limit) for the range of the active reminders could be a problem?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: alarms only work for a maximum of 30 days before the event even if set higher → alarms only work for a maximum of 30 days before/after the event even if set higher
Flags: needinfo?(philipp)
I have no problem with a such hidden pref
Flags: needinfo?(philipp)
I don't know the codebase well so I might be missing something, but it looks to me like what would help here would be to take the existing MAX_SNOOZE_MONTHS constant and change it into something user-configuration (hidden or otherwise). With or without the code change, adding something to the documentation mentioning this limitation would also be appreciated, since the behaviour isn't obvious. (In my case I went from having 10 reminders showing in Outlook to only one showing in Thunderbird, and I couldn't find any documentation for the "Show missed reminders" option that would explain why.) Thanks!
For what it's worth, I just noticed that this bug is a duplicate of bug 572111.
Attached patch snooze_patch.diff (obsolete) — Splinter Review

Attaching patch how this bug can be fixed.
As suggested above, we can add hidden variable(s) that would allow to configure date range where alarms stays active.
I think it would be much more flexible to have possibility to configure past and future ranges separately. For me past ranges much more important, and it was really annoying to see that remainders disappears without any notice.
I have added two new hidden preferences for alrams: calendar.alarms.maxpastmonths and calendar.alarms.maxfuturemonths for max range for past events and future events respectively.

Attaching fixed patch, previous one remove one preference by accident.

Comment on attachment 9134924 [details] [diff] [review] snooze_patch.diff Obsolete per comment#11.
Attachment #9134924 - Attachment is obsolete: true

I am wondering if there is any chance my patch will be integrated into TB 78? What needs to done for it to accepted?

Severity: normal → S3
Duplicate of this bug: 1890489
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: