| Summary: | KAlarm does not accept date changes to existing reoccurring actions | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdepim | Assignee: | Michele Calgaro <michele.calgaro> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | bugwatch, darrella, michele.calgaro |
| Priority: | P1 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | All | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2247 | ||
| Attachments: |
kalarm patch
screenshot of the new error dialog |
||
|
Description
Darrell
2010-10-01 17:33:35 CDT
Insufficient time with Trinity does not yet provide data that the bug is resolved in Trinity. Please leave this bug open until Trinity is used on a regular basis for many weeks. This bug might be specific to 3.5.10 but only regular usage will tell. There is a not obvious workaround to this bug that does not require editing the data file: 1) disable the recurrence, 2) change the date, and 3) reenable the recurrence. There is a not obvious workaround to this bug that does not require editing the data file: 1) disable the recurrence, 2) change the date, and 3) reenable the recurrence. Should still be fixed, however. Some days I can't type and can't proofread either... The previous comment should say: There is a not-so obvious workaround to this bug that does not require editing the data file: 1) disable the recurrence, 2) change the date, and 3) reenable the recurrence. Should still be fixed, however. Some days I can't type and can't proofread either... The previous comment should say: There is a not-so obvious workaround to this bug that does not require editing the data file: 1) disable the recurrence, 2) change the date, and 3) reenable the recurrence. Should still be fixed, however. Bumping this to minor because there is a work-around. The settings for a reoccurring alarm are set in the "Recurrence" tab. If the alarm is set to go off every Monday, changing the date in the "Alarm" tab to a day different from Monday with select the next available Monday starting from the day that was selected.
Changing the settings in the "Recurrence" tab will move the day to another day if required.
>There is a not-so obvious workaround to this bug that does not require editing
>the data file: 1) disable the recurrence, 2) change the date, and 3) reenable
>the recurrence.
This works because reenabling the recurrence after changing the date will also move the recurring day to the corresponding day of the week (for example from Monday to Sunday in the example given)
I do not see any bug that needs to be fixed in this case.
Perhaps we could highlight the fact that the alarm is a reoccuring one with the following changes:
1) change "Time" to "Time (reoccuring alarm)"
2) change "At date/time" to "From date/time"
when we are editing a reoccuring alarm.
Darrell, what do you think?
Perhaps not a bug in the traditional sense, but at least a discoverability challenge. A user wanting to modify the date/time in a recurring action can't do so in an obvious way. Doing so requires three steps rather than just one.
Users can see the Recurrence tab in the background to notice whether the action is recurring, but most will not connect the logic dots that they cannot change the date without temporarily disabling recurrence.
Rhetorically, why can't a user change the date, which then would automatically update the recurrence data? The question is legitimate for any user, but from a code logic perspective the design makes sense. If an alarm is recurring every Monday and a user tries to change the date/time, likely this will conflict with the recurrence rule.
This could get complicated. Recurrence can occur based upon several criteria other than week day. If the user changes the date to Tuesday and recurrence is triggered by day of the month (e.g., 7th day of the month), how should the code logic update recurrence to match the new date? Should recurrence change to the 8th of the month or match the day of the month of the new date?
So what to do?
Perhaps when recurrence is enabled and the user attempts to modify the date/time, a dialog could appear reminding the user that recurrence is set. I am just throwing this off the cuff, but perhaps something like:
===============================================
Recurrence is set for this action. Please
temporarily disable recurrence before changing
the date/time. Otherwise the recurrence rule
will not match the new date/time.
OK
===============================================
A dialog like this would be more informative than the app doing nothing as I described in the original report. At least then users would not think there is a bug.
Of course, after adding such a dialog, fully expect somebody to file an enhancement request to allow changing the date/time without temporarily disabling recurrence.
Hi Darrell, good to see you are still around. Hope everything is well. The idea of displaying a dialog is perfect, I hadn't though about it. The user can change the date, but if the chosen date does not match the recurrence rule, a warning message is displayed and the change ignored. So for example for a weekly recurrence on Monday, the user can select other Mondays without any problem, but if they select a Tuesday they will see a warning. By the way, you do not need to disable recurrence to change the day. You can change the day in the "recurrence tab" (for example from Monday to Tuesday) and then select the new date in the "Alarm" tab in case the date is not the desired one -- depending on the changes done the automatically selected date could be one week later than expected for example. There is also a problem with recurring alarm with an end date. If an end date is specified and the alarm date set is such that the next occurance would happen after the end date, the alarm is set to the specified date, without being updated to the next matching day and without displaying any error. Looks like there is a little bit more to work on here. Created attachment 2550 [details] kalarm patch Darrell, I have prepared a patch that displays a message dialog when the start date/time on the alarm tab does not match the settings in the recurrence tab. This works only on recurrence events of type daily, weekly, monthly or yearly. The hourly type is not affected since there is no way to specify a reference time. Could you build KAlarm from the current git sources (main trunk) and the supplied patch to test and let me know your opinion? The problem with recurrence and end dates mentioned in comment 10 will be address on a separate patch. NOTE: the above patch introduces an API change on one of the inner classes used by KAlarm. Therefore the above patch will only be pushed to the main trunk (r14.1.x) and will *not* be ported to the r14.0.x branch Created attachment 2551 [details]
screenshot of the new error dialog
I don't know when I'll get to this. Good news, the above patch also fixes the problem described in comment 10 since it is no longer possible to select a start date that does not match a recurrence setting (which in turn would have generated the described problem). Fixed in commit 74a91e1 (master only) |