579719 - recurring even start date should match custom recurrence pattern

Status: RESOLVED DUPLICATE of bug 411264

(Calendar :: Dialogs, defect)

Description

[Simon Schubert]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
Build Identifier: 2b1d32144d10

When creating a new custom recurring event, the start date should be matched to the first occurrence.

Currently it doesn't, since the start date is filled before you can open the custom recurrence editor.  This leads to the odd behavior that the event will occur on the start date *and* on the selected recurring days.


Reproducible: Always

Steps to Reproduce:
For example, if today is Sunday, and I want to create a new recurring event, I go to Events and Tasks->New Event.  Today's start date will be filled in (actually the currently selected day, but that's beyond the point).

Now I select custom recurrence and set up a weekly recurrence pattern, every Tuesday and Thursday.

Actual Results:  
The result is an even that will occur on said Sunday, and then every Tuesday and Thursday.

Expected Results:  
Hardly what is expected.  I'd expect it to occur on Tuesdays and Thursdays only.

I suggest automatically adjusting the start date to the first occurrence.  If the user is really interested in having an odd recurrence rule with additional start date occurrence (which I highly doubt), he could later (after closing the recurrence editor) change the start date manually.

Comment 1

[Martin Schröder [:mschroeder]]

This could be reproduced using Lightning 1.0. It should be investigated what should be done from an UX POV.

Comment 3

[[:MakeMyDay]]

Still an issue in Lightning 3.3.1 and 3.6

In case of rrules, which specify a "nth occurrence within a period" rule, the event start and end date should be adapted - if neccessary - when closing the custom recurrence dialog and returning to event dialog. Also a notification bar would probably nice to inform the user about the adaption, so he/she can revert the change for the unlikely case this special behaviour is explicitely wanted.

Comment 4

[Decathlon]

This seems a duplicate of Bug 411264.