Open Bug 354935 Opened 18 years ago Updated 3 years ago

undo after moving a single occurrence does the wrong thing

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: damian.publicemail, Unassigned)

Details

(Whiteboard: [not needed beta][no l10n impact])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Sunbird/0.3

When I want to drag occurrence of repeating event there is no confirmation if I would like to move single or group of occurences.

Reproducible: Always

Steps to Reproduce:
1. Create new repeating event (repeat for 5 days)
2. Drag and drop first occurrence
Actual Results:  
No confirmation if I want to move one occurrence or all
Single occurrence was moved

Expected Results:  
confirmation should appear like it used to be

Looks like regression because it worked before, right now confirmation appears only when you want to edit event

I found out it when wanted to verify bug 352862
Flags: blocking0.3?
This was an executive decision made in bug 352862 and bug 336952 comment 8.

-> not blocking the 0.3 release
--> WONTFIX
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking0.3? → blocking0.3-
Resolution: --- → WONTFIX
Whiteboard: [litmus testcase wanted]
After spending some time working with Damian to understand the details, the real problem appears to be that moving a single instance of a recurring event creates an EXDATE, and the undo simply changes the exception, rather than removing the EXDATE entirely.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: repeating events are treated as groups of single events → undo after moving a single occurrence does the wrong thing
Status: REOPENED → NEW
Flags: blocking-calendar0.7?
OS: Windows XP → All
Hardware: PC → All
Version: Trunk → unspecified
Flags: in-litmus?
Whiteboard: [litmus testcase wanted]
We decided on the QA chat this bug doesn't block 0.7.
Flags: blocking-calendar0.7? → blocking-calendar0.7-
Flags: blocking-calendar0.7-
Does this still happen with the latest 1.0b2pre nightlies?
Whiteboard: [feedback?]
confirmed with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100307 Calendar/1.0b2pre
Flags: blocking-calendar1.0+
Whiteboard: [feedback?] → [not needed beta][no l10n impact]

Antony, can you reproduce?

Flags: needinfo?(acdp)

Yes, just tried this with a recurring event and it alone was moved, no request to adjust the rest of them

I have had this a few times and a problem also when not the first instance, I am not asked if future instances need to move as well to be in Sync, even it originally set on a date preceeding the event I want to move

Flags: needinfo?(acdp)
You need to log in before you can comment on or make changes to this bug.