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"
Component: Lightning Only → Dialogs
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.
(In reply to MakeMyDay from comment #1) > Do you have cache enabled for the > respective calendars? Offline support is enabled.
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.
Component: Dialogs → Provider: CalDAV
Created attachment 8543348 [details] 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.
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.
Created attachment 8543381 [details] 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.
Attachment #8543348 - Attachment is obsolete: true
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?
Created attachment 8543757 [details] 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.
This is the same issue as bug 702570. We need probably need to implement MOVE (and COPY) method(s) to deal with that.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 702570
You need to log in before you can comment on or make changes to this bug.