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)
Calendar
Calendar Frontend
Tracking
(Not tracked)
NEW
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
Reporter | ||
Updated•18 years ago
|
Flags: blocking0.3?
Comment 1•18 years ago
|
||
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
Reporter | ||
Updated•18 years ago
|
Whiteboard: [litmus testcase wanted]
Comment 2•18 years ago
|
||
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
Updated•17 years ago
|
Status: REOPENED → NEW
Flags: blocking-calendar0.7?
OS: Windows XP → All
Hardware: PC → All
Version: Trunk → unspecified
Comment 3•17 years ago
|
||
We decided on the QA chat this bug doesn't block 0.7.
Flags: blocking-calendar0.7? → blocking-calendar0.7-
Updated•17 years ago
|
Flags: blocking-calendar0.7-
Comment 4•14 years ago
|
||
Does this still happen with the latest 1.0b2pre nightlies?
Updated•14 years ago
|
Whiteboard: [feedback?]
Reporter | ||
Comment 5•14 years ago
|
||
confirmed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9pre) Gecko/20100307 Calendar/1.0b2pre
Updated•14 years ago
|
Flags: blocking-calendar1.0+
Whiteboard: [feedback?] → [not needed beta][no l10n impact]
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.
Description
•