Version: 4.7 (using KDE 4.7.1) OS: Linux Akonadi Console output: korganizer-1431355191 (0x9a8f390) 29 UID STORE 9121 REV 81 (REMOTEID "http://groupware.envirology.co.nz/groupdav.php/janus/calendar/c1f2762b-05e0-42dc-b442-49ff38a948ee.ics" REMOTEREVISION "\"2614:0:1318475018\"" PLD:RFC822 {707} korganizer-1431355191 (0x9a8f390) 29 NO Only resources can modify remote revisions Reproducible: Always Steps to Reproduce: Edit an existing incidence in Korganizer and chnage the end date of a repeating event or chnage attendee information Actual Results: Dialog warning popup: Unable to store the incidence in the calendar. Try again? Reason: Unknown error. (NO Only resources can modify remote revisions ) Expected Results: Incidence to be updated Seems to be happening only with dates for recurring events and attendee modification.
Hi Ingo, I'm wondering if this should not be addressed in KOrg. I'm re-addressing this bug, as I don't see what can be done by the resource here. Cheers, Grégory
Hi, for information, I get the same bug. I'm synchronizing with a SOGo server in caldav. When I edit the same event twice, the error appears, I think it is linked to the fact that korganizer (or akonadi?) detects a conflict between the local event and the remote one maybe?!
My issue is independant from that. If I edit an istance too quickly (quicker then the updated version is retrieved from the server), akonadi or Korganizer will display a message where you can select the item that you want to keep (using 4.7.2). However, an ettempt to change repeating item end dates, exceptions or participants SOMETIMES produces this weired bug. I tried to reproduce it, but cannot. However it happened several times in the past. I will keep an eye on it and report steps taken once it occurs again. Regards, Ingo
Had it again. I added an exception to an reoccurring event. Saved it. Noticed that it was not changed, had a look at the server via web interface too and indeed the exception was not saved. Opened the incidence gain and added the exception, clicked "Ok" et voila: Said message pops up. Cannot change anything, simply won't save and repeats the same message. Clicked on "update calendar folder" to trigger a reload in KOrganizer. Did not help, still not able to change anything. That incidence is now a dead one in KOrganizer, all I can do is delete it. I opted to add the exception via web interface and reloaded the calendar in KOrganizer. All okay now.
I have the same issue, generally restarting kontact does help.
I'm seeing this with a Google CalDav resource, configured as as per here:http://jpwhiting.blogspot.com/2011/04/kontact-with-google-calendar.html Trying to save *any* edit of any property of an event that was originally added via the web interface generates the error, which BTW must rank as one of the most obscure and unhelpful messages ever - "http://jpwhiting.blogspot.com/2011/04/kontact-with-google-calendar.html [Yes] [No]"
note that I've just hit this issue (same as comment #2, editing an event twice) with korganizer 4.8.0
*** This bug has been confirmed by popular vote. ***
After some debugging on this issue today it seems that the problem is that Korganizer is not using the latest item known to Akonadi, at least in what concerns the remote revision. If you try to edit the item directly after starting Korg then everything will be fine. Any further edit in the same session will fail as the item known to Korg is never refreshed and the remote revision is now out of date (the dav resource will always fetch the latest remote revision behind the scenes). When the following edits are done Korg tries to set the remote revision to what it was, which is rejected by Akonadi. One solution would be that Korg updates the cached item once EventOrTodoDialog completes (haven't found how to do this easily, apparently this would require updating the incidenceeditor-ng to add a signal), or have Akonadi notify Korg that the remote revision has changed. I'm not sure I'll have some time soon to look into this, so if anybody want to pick this up he'll be more than welcome. Cheers, Grégory
just my 2 cents I can confirm this issue on KDE 4.9 (kubuntu 12.04) with akonadi-google resource. Just after start kontact I can edit event without problems. But second edit causes this error: Unable to store the incidence in the calendar. Try again? Reason: NO Only resources can modify remote revisions One fun fact: I can't edit start/end time of event due to this error, but I can drag'n'drop event to another time without problems. P.S. Sorry for my English
Created attachment 73665 [details] screenshot of error
JFYI: KDE 4.9.1. This bug is still with us
Confirmed, 4.9.1 still buggy :-(
*** Bug 307728 has been marked as a duplicate of this bug. ***
The issue is reproducible on any resource that uses remote revisions. You don't even need to modify the event, it's enough when the resource fetches changes from remote server, which lead to update of remote revision of the modified event. I spent some time tonight trying to find out what's wrong, this is what I got to: The problem is that CalendarSupport::Calendar caches Akonadi::Items but is not notified about update of their remote revisions. When a resource changes remote revision of an item in Akonadi, the change is not propagated to CalendarSupport::Calendar (and thus to it's cache). When user tries to modify such an out-of-sync event, IncidenceEditorNg creates an Akonadi::ModifyJob for Akonadi::Item which has an old remote revision and Akonadi evaluates it as an attempt to change the remote revision and refuses to continue. This is reproducible for example with the Google Calendar resource. The Akonadi resource in itemChanged() handler sends update to server, waits for reply and then calls Akonadi::Item item = reply->request()->property( "Item" ).value<Akonadi::Item>() item.setRemoteRevision( event->getRemoteRevision() ); changeCommitted( item ); which effectively changes remote revision of the item and submits it to Akonadi (by confirming that the update was successful). However! When Akonadi::EntityTreeModel::dataChanged(QModelIndex leftTop,QModelIndex rightBottom) is emitted (atm I don't know whether it's emitted before changeComitted() is called from the resource or after), the Akonadi::Item obtained from the leftTop index has the _OLD_ remote revision. So, the root cause is probably that remote revision of the Akonadi::Item in the model is not updated when it changes in Akonadi, or that the change does not cause the model to emit dataChanged() and so clients are not notified about it.
Git commit 2be280f91c1baa81e3aee3d029b0c507515fb0d5 by Dan Vrátil. Committed on 07/10/2012 at 12:48. Pushed by dvratil into branch 'KDE/4.9'. Correctly update Item's remoteRevision in Akonadi::Item::apply() REVIEW: 106710 FIXED-IN: 4.9.3 M +1 -1 akonadi/item.cpp http://commits.kde.org/kdepimlibs/2be280f91c1baa81e3aee3d029b0c507515fb0d5
On kubuntu 12.10/KDE 4.9.3 I have this issue yet
The bug reported here is still present in Kubuntu 13.10 along with KDE 4.10.2. For those who use the "Akonadi Calendar Resource", there is a useful "workaround". Simply bring in the event and especially its "description" in the agenda web interface of your google/ gmail account. I have created a .txt file with Kate and worked out there the description - a programme of a meeting. Then, I copy-pasted everthing at my online Google calendar, after which it also appeared in Kontact-Calendar. Respectfully yours, Bas G. Roufs.
(In reply to comment #18) > The bug reported here is still present in Kubuntu 13.10 along with KDE > 4.10.2. > For those who use the "Akonadi Calendar Resource", there is a useful > "workaround". > Simply bring in the event and especially its "description" in the agenda web > interface of your google/ gmail account. I have created a .txt file with > Kate and worked out there the description - a programme of a meeting. Then, > I copy-pasted everthing at my online Google calendar, after which it also > appeared in Kontact-Calendar. > > Respectfully yours, > > Bas G. Roufs. ERRATUM. At present, I work with the platform Kubuntu 13.04 - not yet 13.10 :-). To be honest, I do not understand why this bug has been qualified as "fixed" - it is still there. However, the "workaround" summarised here, works well enough for me.
Still there for me 4.10.2
I just had the bug with KOrganizer Version 4.10.2 on debian/testing.