1117104 - Thunderbird: Lightning: Cannot Alter Calendar to which item is entered after item created

Status: RESOLVED DUPLICATE of bug 702570

(Calendar :: Provider: CalDAV, defect)

Description

[Doug]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 2014112600

Steps to reproduce:

Using Lightning 3.3.2 on Thunderbird 31.3.0, OpenSuse 13.1

1.  Setup two calendars in Lightning (from Yahoo) ("Calendar1" and "Calendar2")
2.  Create calendar entry, save onto "Calendar1"
3.  Realize saved onto wrong calendar, open calendar item.
4.  In dialog box/popup, for Calendar entry, change dropdown box value from "Calendar1" to "Calendar2".
5.  Save, save and close, use any sequence to save change to calendar item





Actual results:

6.  UNEXPECTED RESULT:  Change to calendar item is not saved, item does not change from one calendar to another.  Item remains saved on "Calendar1", item not created on "Calendar2".  Item continues to be displayed in Thunderbird in color scheme attributable to "Calendar1".



Expected results:

EXPECTED RESULT:  Lightning should have saved item onto "Calendar2" removed from "Calendar1", and dispayed alteration visually.  Alternatively, should show error message alerting user that manual deletion, re-creation is required.

WORKAROUND:  "Calendar1" item must be manually deleted and re-created to change to "Calendar2"

Comment 1

[[:MakeMyDay]]

Do you see any message in the error log (ctrl+shift+j) when saving? Please enable calendar.debug.log, calendar.debug.log.verbose and javascript.options.showInConsole? Do you have cache enabled for the respective calendars?

Comment 2

[Doug]

Here is the message log entry.  This might be enough for troubleshooting.  If not, please state how to enable other options.  I have changed email address/user in log entry below, so it is not verbatim.  The email in the log is the one associated with "Calendar1".

*********************

[JavaScript Error: "CalDAV: Unexpected status adding item to Doug: 412
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20150102T163617Z
DTSTAMP:20150102T163617Z
UID:645523d0-e311-4045-8e8e-04b3690fc289
SUMMARY:New Event1
PRIORITY:0
STATUS:CONFIRMED
ORGANIZER;SENT-BY="mailto:[e-mail]":mailto:[e-mail]
DTSTART;TZID=America/New_York:20150116T120000
DTEND;TZID=America/New_York:20150116T130000
CLASS:PUBLIC
SEQUENCE:0
X-YAHOO-YID:dougt901-2012
TRANSP:OPAQUE
X-YAHOO-USER-STATUS:BUSY
X-YAHOO-EVENT-STATUS:BUSY
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Default Mozilla Description
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for DESCRIPTION pro
 perty. Removing entire property:
END:VALARM
END:VEVENT
END:VCALENDAR
"]

Comment 3

[Doug]

Actually, the account in the error log @3 is for "Calendar2" in the bug report.  The error message is returned the same without the X-LIC-ERROR when a description is included in the calendar entry.

Comment 4

[Doug]

(In reply to MakeMyDay from comment #1)
> Do you have cache enabled for the
> respective calendars?

Offline support is enabled.

Comment 5

[[:MakeMyDay]]

The X-LIC_ERROR shouldn't make a problem here. This is okay.

Can you recheck this with cache disbaled for both calendars, whether it works then?

Also please provide the full set of messages you get in the error console (preferably as an attched text file to this bug). The 412 error code indicates there is eventually a problem with the etags, but to investigate further, we need the full view on the client server communication from the log.

Comment 6

[Doug]

Attachment: error log start tbird, attempt w/offline suport, attempt w/o cache

With offline support (cache?) disabled for both calendars, now I get an error messasge that previously was suppressed:

>   An error occurred when writing to the calendar Doug!
>   ERROR CODE:  MODIFICATION_FAILED
>   Description: Status Code: 2147500037, The request cannot be processed.
>   Server Replied with 412

Error message also newly reflected in log.  The attached log is tbird start, attempt with offline support enabled, first attempt with offline support disabled.  Both attempts raise an error concerning getAttributeNodeNS().

Pls. send info on enabling debugging options if desired.

Comment 7

[Doug]

With caching disabled, change might be visually displayed in partial or temporary way.  That is, visual object representing calendar entry might change color to that of correct calendar for a moment or something, which it does not seem to do at all with offline support enabled.

Comment 8

[[:MakeMyDay]]

Offline support is intended to (also) keep Lightning usable, even if there are current network problems, so this behaviour is expected.

Enabling debugging was already described in comment #1: Please enable calendar.debug.log, calendar.debug.log.verbose and javascript.options.showInConsole (in config editor). Can you please provide the debug logging?

Comment 9

[Doug]

Attachment: lighting_err_log_debug_redact

This is verbose with degugging enabled through console.  Thx.  Whole calendar showed up in log, trucated that and .ics names, id info.  Otherwise, this again is starting tbird, attempting to change item's calendar with caching enabled, disabling caching on destination calendar, repeating.

Comment 10

[[:MakeMyDay]]

Thanks. Your replacements of with SIMULTED.ics in the log make it hard to so exactly what happened. Could you provide an updated log without these modifications. Truncating the event details and modifying the id infos is ok.

Additionally, there's a second thing you can try please:

1. make sure offline support is diabled for both Yahoo calendars
2. create a local calendar (or use an existing subsequently)
3. open the respective event in the Yahoo calendar
4. change the calendar to the local one from step 2
5. Save & close the event dialog
6. reopen the event
7. change the calendar to the alternate Yahoo calendar
8. Again, save & close the event dialog

Does this work, so that the event is in the local calendar after step 5 and in the alternate Yahoo calendar after step 8?

Comment 11

[Doug]

Attachment: error console @10 steps, multiple iterations, ending with failure to read duplicate item from local calendar

The specific sequence @10 completes successfully, but random variations on that sequence @10 produce unexpected results.  @10 requires three calendars, two Yahoo calendars (Y1 and Y2) and one local (L1).  FYI, Y2 is a shared/unowned calendar.

If I create entry on on Y1, transfer to L1 works, and can retransfer to Y1.  However, I cannot retransfer to Y2.  Seems pretty stable in those relationships.

If I create entry on Y2, transfer to L1 works, and retransfer to Y2 also works.  Initially, retransfer to Y1 fails, but then later if I juggle back and forth enough transfer to Y1 from L1 will succeed, but also result in creation of duplicate calendar items on L1 and Y1 or Y2, neither of which duplicate items can be transferred.

The attached logfile is roughly this sequence, many iterations of transferring items between calendars via calendar test_local.  Endpoint of log is failure to read from test_local calendar item that was created as duplicate as some point when moving from test_local to one of the Yahoo calendars (I think).

Left ics filenames intact in this.  Redacted ids, removed full recitation of calendar at beginning of log.

Comment 12

[[:MakeMyDay]]

This is the same issue as bug 702570. We need probably need to implement MOVE (and COPY) method(s) to deal with that.