735619 - Event is moved from original calendar to primary Google calendar upon editing

Status: VERIFIED FIXED

(Calendar :: Provider: GData, defect)

Description

[Tobi]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

Edit an appointment in Lightning which is stored in a secondary google calendar.
(Not the main calendar!)
I use Provider for Google Calendar 0.9 with multiple google calendars.


Actual results:

The appointment was deleted from the sub calendar and stored to the main calendar from the google account.


Expected results:

The appointment should only saved with the new information on the same calendar.

Comment 2

[Stefan Sitter [:ssitter]]

Confirming based on various reports e.g. https://getsatisfaction.com/mozilla_messaging/topics/bug_thunderbird_10_lightning_drag_drop_makes_inappropriate_changes_to_the_calendar_entry

Comment 4

[Lewis Rosenthal]

I am unable to reproduce this with Lightning 1.2.3 / GData 0.11 *until* I enable caching for the test calendar. Once caching is turned on, I do not even have to edit an existing event; it immediately moves to the main calendar.

Tobi (& Stefan), is there a specific edit to an event which triggers this?

My steps:

1. I had a single private calendar (and subscribe to a half dozen public ones).
2. I created another private calendar, with no sharing enabled for anyone else.
3. I added this new calendar to my Lightning configuration, using the private XML url (my main calendar is configured similarly).
4. I created a new 1-hour event, with a (default) 15 minute reminder (not repeating). I did *not* assign a category. I entered some text for the description and entered a location.
5. I saved the new event.
6. I verified that the new event was visible in the new calendar in the Google we interface.
7. In Lightning, I opened the event, changed some of the description text, and saved it.
8. I verified that the event did not move to my "main" calendar.

I repeated the above steps several times, changing different things.

Can either or both of you confirm that the selected calendar shown when editing the event is indeed remaining as expected, and that this is not somehow changing upon opening the event, *and* that this behavior *only* occurs when caching is enabled?

I hadn't thought of caching until I reviewed the video in Bug 736277.

Comment 5

[Guido]

I just made a test using CalDAV instead of Provider. Changing an existing entry works fine (for only a few tests up to now). But creating a new event sometimes sets alarm/reminder flag.
This happens: 
- on the left calender overview the main calender is not highlighted 
- adding an item for this main calender by changing calendar within the calendar item GUI
- added entry has alarm/reminder flag set

Comment 6

[Katy]

I've just discovered I have this bug, too, and apparently have for a while. I thought my events were just disappearing (ala Bug 736590), but I've now found that whenever I edit and save events from my secondary Google calendars, the events get moved to my primary Google calendar (which I don't use and so hadn't exported to Lightning, until now). 

I currently have Windows 7, TB11.0, Lightning 1.3 and Provider 0.9, to which I just upgraded today and even reinstalled Lightning and Provider just in case. I was also having this problem with the previous version (TB10.0.2, Lightning 1.2.3, Provider 0.9). 

To reproduce:
1. I add a secondary Google calendar to Lightning, using the private XML link. The calendar can be shared or unshared. I do not check Cache. 
2. I create an event in Lightning in this calendar and save. The event shows up successfully in secondary calendar in both Lightning and Google Calendar Web version. 
3. I double click this event in Lightning, or select and click edit from taskbar. 
4. In Edit Event window, all the characteristics of the calendar are still as I set them ... including the Calendar name. Then, all I need to do is click "Save and Close" without actually changing anything (although it also happens when I change anything so far, location, description, time, all day event, reminder, and then click "save and close"). 
5. When I refresh my Lightning calendar and my Google Web version calendars, the event is now listed in my main Google calendar in both places. It also has changed the reminder from whatever I had set to "Multiple reminders," 10 min before alert and 10min before text message.

BUT - check this out -- I just noticed that if I go back in to edit the event, and only change its Calendar in the drop down menu from main Google calendar back to the original secondary calendar, and then "Save and Close," it switches it back successfully! Interestingly, it also fixes the reminders back to their original configuration (so, for example, the original event had no reminder, when it switched it to main Google cal, it turned on "multiple reminders"; switching it back to original calendar turned it back to no reminder). 

Sorry if this is too detailed. :)

Comment 7

[SoWhy]

My setup is the same as [e-mail]'s, so I think the "Version" should be adjusted accordingly in the bug-info (I can't make edits to it?)

Comment 8

[Lewis Rosenthal]

Katy, per comment 6: Never apologize for providing detail in a bug report. It is far more useful than some of the endless banter and conversation posted elsewhere.

Now, could everyone experiencing this bug kindly report on whether he or she has caching enabled for the affected calendar(s), please?

Comment 9

[SoWhy]

@Lewis: I have tried it with caching enabled as well as not enabled, with the same results.

Comment 10

[Guido]

In the beginning I had caching enabled. I deactivated it in the meanwhile - but there is no difference.

Comment 11

[Lewis Rosenthal]

Thanks, guys. What I *think* we're seeing is that *before* caching is enabled, this does not present itself, but once caching *has been* enabled, it is consistent. Per my test, creating the calendar without enabling caching, everything worked as expected. As soon as I toggled it, I saw the issue. Turning it off again made no difference.

And, as Katy mentioned in comment 6, editing an event and selecting the proper calendar and reminder setting seems to make it stick for future edits (for me, at least). Can either of you confirm that?

Comment 12

[SoWhy]

(In reply to Lewis Rosenthal from comment #11)
> Thanks, guys. What I *think* we're seeing is that *before* caching is
> enabled, this does not present itself, but once caching *has been* enabled,
> it is consistent. Per my test, creating the calendar without enabling
> caching, everything worked as expected. As soon as I toggled it, I saw the
> issue. Turning it off again made no difference.

Sorry to say but I cannot confirm your WORKSFORME. I just set up a completely clean fresh TB 11 install in a VM running Win7x64 and tried the steps outlined by Katy above (comment 6) and I could reproduce it with cache not enabled.

> And, as Katy mentioned in comment 6, editing an event and selecting the
> proper calendar and reminder setting seems to make it stick for future edits
> (for me, at least). Can either of you confirm that?

Re-changing it back from main to secondary in TB works and will restore it to the secondary calendar as expected. *But* as soon as you edit this event again, it will again be moved to the main calendar...

Comment 13

[Katy]

In reply to Lewis Rosenthal from comment #8) 
> Katy, per comment 6: Never apologize for providing detail in a bug report.

Thanks! :))

(In reply to Lewis Rosenthal from comment #11)
> Thanks, guys. What I *think* we're seeing is that *before* caching is
> enabled, this does not present itself, but once caching *has been* enabled,
> it is consistent. Per my test, creating the calendar without enabling
> caching, everything worked as expected. As soon as I toggled it, I saw the
> issue. Turning it off again made no difference.

I'm afraid that, to my knowledge, I've never had cache enabled, since I actually never knew what that function was for. With this latest re-install I definitely didn't check it. I can double-check my laptop which ostensibly still has the "old" TB10.0.2.

> And, as Katy mentioned in comment 6, editing an event and selecting the
> proper calendar and reminder setting seems to make it stick for future edits
> (for me, at least). Can either of you confirm that?

Just to be clear, the "fix" I discovered doesn't even need you to change the reminder settings back. Literally, all I did was change the calendar back and save... It's almost as if it still had the reminder info stored somewhere (which admittedly sounds awfully cache-like). 

And, like SoWhy, if it's back in the secondary calendar and I modify it once more and save, it moves it back to the main calendar yet again.

Comment 14

[Lewis Rosenthal]

(In reply to SoWhy from comment #12)
> (In reply to Lewis Rosenthal from comment #11)
> > Thanks, guys. What I *think* we're seeing is that *before* caching is
> > enabled, this does not present itself, but once caching *has been* enabled,
> > it is consistent. Per my test, creating the calendar without enabling
> > caching, everything worked as expected. As soon as I toggled it, I saw the
> > issue. Turning it off again made no difference.
> 
> Sorry to say but I cannot confirm your WORKSFORME. I just set up a
> completely clean fresh TB 11 install in a VM running Win7x64 and tried the
> steps outlined by Katy above (comment 6) and I could reproduce it with cache
> not enabled.
> 
Hmmm... So there must be something different about my setup. Perhaps its the platform (I'm on OS/2). I definitely did not see this without caching, saw it when caching was enabled, and turning caching off did nothing. But you are saying that you are experiencing this even with caching disabled.

Do you notice any difference with events created before or after enabling caching?

> > And, as Katy mentioned in comment 6, editing an event and selecting the
> > proper calendar and reminder setting seems to make it stick for future edits
> > (for me, at least). Can either of you confirm that?
> 
> Re-changing it back from main to secondary in TB works and will restore it
> to the secondary calendar as expected. *But* as soon as you edit this event
> again, it will again be moved to the main calendar...
>
And thanks (again) Katy for quickly confirming that this is the way yours behaves, as well.

I'll try to set up my calendars on Windows over the next few days and see what I get. I've tested under OS/2 and Linux, so perhaps my results will be different under Windows (and I do not know that I've tested for this particular issue under Linux).

Comment 15

[SoWhy]

I just tried the same procedure on a VM running Linux Mint 12 x64 (same TB/L/GDATA as above) and I was able to reproduce the bug as reported with cache not enabled.

Comment 16

[Matthew Mecca [:mmecca]]

I'm not really familiar with the GData Provider, but it appears to me that events in a secondary Google Calendar have a special organizer property in the form of [calendar-id]@group.calendar.google.com, rather than the user id used to access the calendar account. When the organizer property is changed to the user id, that seems to be interpreted by the server as moving the event to the primary calendar.

When an event is opened and saved in the event dialog, the item's organizer property is changed, whether anything else is explicitly changed or not. This behavior appears to have been introduced in Bug 586276.

Comment 17

[Matthew Mecca [:mmecca]]

Attachment: Fix v1

It looks like the item organizer change is acl related, so shouldn't be necessary without an aclEntry. Wolfgang, does this make sense?

Comment 18

[Guido]

In the same direction and as i mentioned earlier in /bug_thunderbird_10_lightning_drag_drop_makes_inappropriate_changes_to_the_calendar_entry


I logged the creating of an entry and the change afterward. Astonishing for me is during creation of an event in calendar named test:

Organizer:
ID: mailto:[e-mail]...
Name: test

But during changing it is:

Organizer:
ID: mailto:[e-mail]
Name: [e-mail]

Is this like it should be?
I had put the complete logs in https://getsatisfaction.com/mozilla_messaging/topics

Comment 19

[Morphal]

I also have the issue described here. I can provide details if needed, but it seems that everything is already here.
I hope the fix will be released quite soon!

Comment 20

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Fix - v2

In addtion to what you did in v1, I'd also like to change the organizerId for secondary calendars. Obviously Google expects the organizer to be the group email address, so we shouldn't change that.

Comment 21

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

comm-central changeset 5870edce4ebe
releases/comm-aurora changeset aabca6fd1b16
releases/comm-beta changeset 4ffd398b18aa

Comment 26

[Stefan Wolter]

Today I received Thunderbird 12.0 and Lightning 1.4, and the bug is NOT present anymore according to my short test. I didn't had to change anything with the google-provider-addon.

Thank you!

Comment 27

[Guido]

Yes since 1.4b3 the problem is fixed. Thank you very much from me too!

Comment 28

[Martin Schröder [:mschroeder]]

VERIFIED per comment#26 and comment#27

Comment 29

[Tobi]

Thanks a lot.
Now it works as requested.

Comment 30

[Stefan Sitter [:ssitter]]

Philipp, this might be another candidate to port back to 1.2.x esr release.