GNOME Bugzilla – Bug 271126
Recurring appointment with exceptions has incorrect recurrence count
Last modified: 2006-07-31 10:35:42 UTC
Distribution: Debian 3.0 Package: Evolution Priority: Normal Version: GNOME2.8.1 2.0.3 Gnome-Distributor: Debian Synopsis: Recurring appointment with exceptions has incorrect recurrence count Bugzilla-Product: Evolution Bugzilla-Component: Calendar Bugzilla-Version: 2.0.3 Description: Description of Problem: Take the following example: Create recurring appt for 2 occurences starting 1/Jan/05 with exceptions on 2/Jan and 3/Jan. This should result in appointments on the 1/Jan and 4/Jan. Instead, it appears that exceptions are included within the occurences count and in the example above only the 1/Jan appointment is shown. Steps to reproduce the problem: 1. Setup recurring appt for 2 occurences starting 1/1/05 with exceptions on 2/Jan and 3/Jan. Actual Results: Observe that 4/Jan does not show the appointment. Expected Results: A recurring appointment showing instances on 1/Jan and 4/Jan. How often does this happen? Every time. Additional Information: NIL. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
I don't believe this is a bug. You are creating the recurrence rule, which creates a pattern. Then you add exceptions which removes certain instances from the rule, if the rule were to take this into account, it would be a different rule than it shows itself as. I will refer this to the usuability team for a second opinion.
Thanks for the feedback. I would see it as follows: (a) Using the rule "Every 1 day *until* 12/3/2005" with exceptions logically changes the number of occurrences. However, (b) Using the rule "Every 1 day *for* 10 occurences" with exceptions as dates (eg 10/3/2005) is interpreted as follows: I want 10 occurences, but the exception should extend the effective finish date. Take this example: My kids have 10 swimming lessons over 2 weeks excluding weekends - it seems out of place to me to have to specify "12 occurences" (2 "extra" occurences to counter the 2 weekend exception dates). Thoughts?
My thought for b) is that it does not seem strange if you follow the widget order. Also this would force the user to calculate in their head the number of exceptions in order to properly set the count before hand.
Also for b) if you were to remove an exception, this would change when the final event instance to a later time, which seems like an unusual case.
So this is probably a classic case of the UI representing the underlying code. We just aren't able to fix it in 2.1 though base on time.
possibly a WONTFIX now that people are used to how Evolution interprets the number of recurrences. i vote for closing this. any comments?
For my two cents worth, my original thoughts stand. However, that's just my view. Anyone else?
Daniel does have a point - W/o prior familiarity with the UI, I might have argued the same. The flow of how the rule is unpacked is open for interpretation and there are multiple ways to do that, each valid from its point of view. Flip the current way and someone else will find it strange !! Solution : The visual feedback using the mini-calendar tells you what gets really counted. If it does not match your expectations, you make corrections. Aliter : Just follow the widget order, you will get the flow. My point is that the alternatives are just different - not better or worse. Since most of the users have already adapted to the existing way, I feel it is better to leave it alone. Unless - someone comes up with a univeral UI that can never be misinterpreted or it can accommodate ALL perspectives. Until then, respectfully...