Version: 4.7 (using KDE 4.7.1) OS: Linux When the invitee/attendee information in an incidence in the incidence edit windows is modified, the changes are not taken over. No output at all in Akonadi Console. Reproducible: Always Steps to Reproduce: Open an existing incidence in KOrganizer with existing attendees and modify the attendance state, say from "tentative" to "confirmed" and submit. Actual Results: no modified attendee information when opened and edited again. Expected Results: Attendee information to be changed and submitted to Akonadi to be written to server Initial event created (akonadi console): akonadi_davgroupware_resource_0 (0x9b16a48) 892 UID FETCH 9771 FULLPAYLOAD CACHEONLY ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) akonadi_davgroupware_resource_0 (0x9b16a48) * 9771 FETCH (UID 9771 REV 2 REMOTEID "http://groupware.envirology.co.nz/groupdav.php/calendar/3ea4acf8-219a-441d-9ce2-7adec93a3dab.ics" MIMETYPE "application/x-vnd.akonadi.calendar.event" COLLECTIONID 62 SIZE 592 DATETIME "14-Oct-2011 00:08:01 +0000" REMOTEREVISION "\"2758:0:1318550856\"" FLAGS () ANCESTORS ((62 "http://groupware.envirology.co.nz/groupdav.php/calendar/") (7 "akonadi_davgroupware_resource_0") (0 "")) PLD:RFC822 {592} BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT CREATED:20111014T000801Z ORGANIZER;CN="Ingo Ratsdorf":MAILTO:ingo@envirology.co.nz ATTENDEE;CN="Ratsdorf, Janus";RSVP=TRUE;PARTSTAT=NEEDS-ACTION; ROLE=REQ-PARTICIPANT;X-UID=203561740:mailto:janus@envirology.co.nz DTSTAMP:20111014T000714Z UID:3ea4acf8-219a-441d-9ce2-7adec93a3dab SEQUENCE:1 LAST-MODIFIED:20111014T000714Z SUMMARY:test CATEGORIES:Eco DTSTART;TZID=Pacific/Auckland:20111014T124500 DTEND;TZID=Pacific/Auckland:20111014T150000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR) then event opened and attendee modified, no output in akonadi console whatsoever. No changes to event happening. I then add an attendee and confirm. Event is subsequently written to Akonadi: korganizer-1431355191 (0x9a8f390) 286 UID STORE 9771 REV 3 (REMOTEID "http://groupware.envirology.co.nz/groupdav.php/calendar/3ea4acf8-219a-441d-9ce2-7adec93a3dab.ics" PLD:RFC822 {721} korganizer-1431355191 (0x9a8f390) + Ready for literal data (expecting 721 bytes) korganizer-1431355191 (0x9a8f390) * 9771 FETCH (REV 4) korganizer-1431355191 (0x9a8f390) 286 OK DATETIME "14-Oct-2011 00:19:53 +0000" STORE completed and is fetched again: akonadi_davgroupware_resource_0 (0x9b16a48) 953 UID FETCH 9771 FULLPAYLOAD CACHEONLY ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) akonadi_davgroupware_resource_0 (0x9b16a48) * 9771 FETCH (UID 9771 REV 4 REMOTEID "http://groupware.envirology.co.nz/groupdav.php/calendar/3ea4acf8-219a-441d-9ce2-7adec93a3dab.ics" MIMETYPE "application/x-vnd.akonadi.calendar.event" COLLECTIONID 62 SIZE 721 DATETIME "14-Oct-2011 00:19:53 +0000" REMOTEREVISION "\"2758:1:1318550888\"" FLAGS () ANCESTORS ((62 "http://groupware.envirology.co.nz/groupdav.php/calendar/") (7 "akonadi_davgroupware_resource_0") (0 "")) PLD:RFC822 {721} BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT CREATED:20111014T001953Z ORGANIZER;CN="Ingo Ratsdorf":MAILTO:ingo@envirology.co.nz ATTENDEE;CN="Ratsdorf, Janus";RSVP=TRUE;PARTSTAT=NEEDS-ACTION; ROLE=REQ-PARTICIPANT;X-UID=203561740:mailto:janus@envirology.co.nz ATTENDEE;CN="Ratsdorf, Jolan";RSVP=TRUE;PARTSTAT=DECLINED; ROLE=REQ-PARTICIPANT;X-UID=205485356:mailto:jolan@envirology.co.nz DTSTAMP:20111014T000714Z UID:3ea4acf8-219a-441d-9ce2-7adec93a3dab SEQUENCE:2 LAST-MODIFIED:20111014T000714Z SUMMARY:test CATEGORIES:Eco DTSTART;TZID=Pacific/Auckland:20111014T124500 DTEND;TZID=Pacific/Auckland:20111014T150000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR) akonadi_davgroupware_resource_0 (0x9b16a48) 953 OK UID FETCH completed I then open the incidence again and delete the previously added attendee while also changing the state of the first attendee to "rejected". The incidence is written to Akonadi. korganizer-1431355191 (0x9a8f390) 321 UID STORE 9771 REV 5 (REMOTEID "http://groupware.envirology.co.nz/groupdav.php/calendar/3ea4acf8-219a-441d-9ce2-7adec93a3dab.ics" PLD:RFC822 {588} korganizer-1431355191 (0x9a8f390) + Ready for literal data (expecting 588 bytes) korganizer-1431355191 (0x9a8f390) * 9771 FETCH (REV 6) korganizer-1431355191 (0x9a8f390) 321 OK DATETIME "14-Oct-2011 00:22:09 +0000" STORE completed akonadi_davgroupware_resource_0 (0x9b16a48) 969 UID FETCH 9771 FULLPAYLOAD CACHEONLY ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) akonadi_davgroupware_resource_0 (0x9b16a48) * 9771 FETCH (UID 9771 REV 6 REMOTEID "http://groupware.envirology.co.nz/groupdav.php/calendar/3ea4acf8-219a-441d-9ce2-7adec93a3dab.ics" MIMETYPE "application/x-vnd.akonadi.calendar.event" COLLECTIONID 62 SIZE 588 DATETIME "14-Oct-2011 00:22:09 +0000" REMOTEREVISION "\"2758:2:1318551601\"" FLAGS () ANCESTORS ((62 "http://groupware.envirology.co.nz/groupdav.php/calendar/") (7 "akonadi_davgroupware_resource_0") (0 "")) PLD:RFC822 {588} BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT CREATED:20111014T002209Z ORGANIZER;CN="Ingo Ratsdorf":MAILTO:ingo@envirology.co.nz ATTENDEE;CN="Ratsdorf, Janus";RSVP=TRUE;PARTSTAT=DECLINED; ROLE=REQ-PARTICIPANT;X-UID=203561740:mailto:janus@envirology.co.nz DTSTAMP:20111014T000714Z UID:3ea4acf8-219a-441d-9ce2-7adec93a3dab SEQUENCE:3 LAST-MODIFIED:20111014T000714Z SUMMARY:test CATEGORIES:Eco DTSTART;TZID=Pacific/Auckland:20111014T124500 DTEND;TZID=Pacific/Auckland:20111014T150000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR) Et voila the attendee no 1 has changed from unconfirmed to declined, something I could not do just by changing the state itself. In summary: Chnaging the status of a attendee is only possible when some other information is chnaged too, otherwise the information is not updated in KOrganizer and written back to the server.
I guess my last comment highlights the fact the Korganizer or akonadi does not realise that an incidence was changed when just modifying the attendees. Is that possibly not compared against changes in the source code somewhere? Who decides when to save an incidence? Akonadi, the resource (groupdav), Korganizer?
(In reply to comment #1) > I guess my last comment highlights the fact the Korganizer or akonadi does not > realise that an incidence was changed when just modifying the attendees. > Is that possibly not compared against changes in the source code somewhere? > Who decides when to save an incidence? > Akonadi, the resource (groupdav), Korganizer? Check in kdepim/incidenceeditor-ng/incidenceattendee.cpp method isDirty(), somehow it isn't detecting the change. Repo: git://anongit.kde.org/kdepim
Hi. Thanks for the pointer. I had a look at the source and can confirm that ONLY attendees and organisers are compared, not their status. That explains why a status is ONLY recognised as changed when you change someting else in the incidence as well. So if someone calls you via phone (yes - that happens) and confirms his attendamce, there's no way to change his status other than deleting that person and adding it back in with the updated status... Causing confusion at the end user since he will receive two notifications from the server: one cancelled and one confirmed. Cheers, Ingo On Wed, 02 Nov 2011 04:34:37 Sergio Martins wrote: > --- Comment #2 from Sergio Martins <iamsergio gmail com> 2011-11-02 04:34:37 --- > (In reply to comment #1) > > I guess my last comment highlights the fact the Korganizer or akonadi does not > > realise that an incidence was changed when just modifying the attendees. > > Is that possibly not compared against changes in the source code somewhere? > > Who decides when to save an incidence? > > Akonadi, the resource (groupdav), Korganizer? > > Check in kdepim/incidenceeditor-ng/incidenceattendee.cpp method isDirty(), > somehow it isn't detecting the change.
The bug is still around in 4.8 and should be easy to be fixed. See last comment re kdepim/incidenceeditor-ng/incidenceattendee.cpp method isDirty() I had a look at the source and can confirm that ONLY attendees and organisers are compared, not their status. That explains why a status is ONLY recognised as changed when you change someting else in the incidence as well.
Still around 4.8.3. Plus now I cannot add any attendees any more at all when editing an existing incidence. Only when creating a new one. So it's getting worse.
Moved on to KDE 4.9 and the bug is still around.
Moved to 4.9.2 and bug is still there. Come on folks! I even described the solution up there.
(In reply to comment #7) > Moved to 4.9.2 and bug is still there. Come on folks! I even described the > solution up there. isDirty() looks ok, it compares the attendee, which contains the status and stuff.
Working on a fix.
Git commit 015cd8d1f8e862a527b732c1ef7788c14d8e988a by Sergio Martins. Committed on 16/10/2012 at 02:57. Pushed by smartins into branch 'master'. Mark the editor dirty when changing RSVP, role or status. The change() signal isn't used in IncidenceAttendee. M +5 -2 incidenceeditor-ng/attendeeline.cpp http://commits.kde.org/kdepim/015cd8d1f8e862a527b732c1ef7788c14d8e988a
YAY! Great stuff. That will make Korganzier almost perfect! :-) Thanks a lot!
Git commit c00a67dd162b745e3466202e716d10ce33d7581e by Sergio Martins. Committed on 16/10/2012 at 02:57. Pushed by smartins into branch 'KDE/4.9'. Mark the editor dirty when changing RSVP, role or status. The change() signal isn't used in IncidenceAttendee. (cherry picked from commit 015cd8d1f8e862a527b732c1ef7788c14d8e988a) M +5 -2 incidenceeditor-ng/attendeeline.cpp http://commits.kde.org/kdepim/c00a67dd162b745e3466202e716d10ce33d7581e