[Kde-pim] Changing UID of a newly created Akonadi::Item

[Dan Vratil]

On Wednesday, November 23, 2011 13:25:15 Kevin Krammer wrote:

<snip>

> > Despite the fact, that I assigned a new payload which contains
> > UID='some-id- google-gave-me' and committed it, the item still has the
> > generic UID assigned by Akonadi. And this is the problem, because when I
> > want to update the event the serializer takes the payload but uses the
> > incorrect UID (the Akonadi's one) and Google then complains about
> > unknown
> > event.
> 
> So the problem is that the payload is not changed?

Exactly :)

> Try running Akonadiconsole when doing that and enable the debugger (tab
> Debugger). It shows the actual data transfer between Akonadiserver and its
> clients, so you could check if the new payload is sent correctly.

After accepting the Incidence editor, this appears in the debugger (note the 
generic UID):

24 UID FETCH 23014 FULLPAYLOAD CACHEONLY EXTERNALPAYLOAD (UID REMOTEID 
REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME) 
* 23014 FETCH (UID 23014 REV 0 REMOTEID "" MIMETYPE "application/x-
vnd.akonadi.calendar.event" COLLECTIONID 126 SIZE 416 DATETIME "23-Nov-2011 
23:08:40 +0000" FLAGS () PLD:RFC822 {416} BEGIN:VCALENDAR PRODID:-//K Desktop 
Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT 
CREATED:20111123T230840Z ORGANIZER;CN="Dan Vratil":MAILTO:dan at progdan.cz 
DTSTAMP:20111123T230822Z UID:9e98f5ae-d00b-40ba-b292-d68df47dd6d8 LAST-
MODIFIED:20111123T230822Z SUMMARY:A new bla test LOCATION:somewhere 
DTSTART;VALUE=DATE:20111125 DTEND;VALUE=DATE:20111126 TRANSP:OPAQUE END:VEVENT 
END:VCALENDAR) 
24 OK UID FETCH completed 

(I'm wondering how anyone can "FETCH" an item that has not yet been actually 
added to Akonadi....?).

This appears after reply from Google is received, after calling 
changeComitted();

24 UID STORE 23011 NOREV (REMOTEID "k7vr32iij11qiebaofogf789h8" REMOTEREVISION 
"\"F0oNRQFDfCp7JGA6WhJW\"" DIRTY false) 

Despite the fact I assigned a new payload, it only sees changes in remoteID 
and remoteRevision, the payload change is simply ignored. 

I actually tried to simplify the code as much as possible, calling 
changeCommitted() directly from the itemAdded() slot:

void CalendarResource::itemAdded(const Akonadi::Item& item, const 
Akonadi::Collection& collection) {

//EventPtr is KCalCore::Event::Ptr
EventPtr event = item.payload<EventPtr>();
event->setUid("123456789");
Akonadi::Item newItem(item);
newItem.setRemoteId("123456789");
newItem.setPayload<EventPtr>(event);
changeCommitted(newItem);

}

But without any result, the payload UID is not changed. So I'm beginning to 
wonder - am I even allowed to change payload of newly created Akonadi item?

You can see the current sources (without payload changing) here:

http://quickgit.kde.org/?p=akonadi-
google.git&a=blob&f=calendar/calendarresource.cpp

There are the two main slots: itemAdded() (called from Akonadi) and 
eventCreated() (reply from Google).

> 
> > So my question is, what am I doing wrong and how can I overwrite the
> > Akonadi's generic UID?
> > 
> > I'm sometimes getting similar warnings in .xsession-errors:
> > 
> > plasma-desktop(5193)/plasma: Ignoring item. item.id() = 1879 ; cached id
> > = 0 ; item uid = "MDg5MjIwMDc5Mzg2MDE1MDg3NzY6MDoxODUyMjExNjE0" ;
> > calendar = "" ; existed in cache = false ; storageCollection.id() = 24
> > ;
> > parentCollection.id() = 24 ; hasParent = false ; knowParent = false
> > 
> >  plasma-desktop(5193)/plasma: Possible cause is that the resource isn't
> > 
> > explicitly setting an uid ( and a random one is generated )
> > 
> > This makes me assume  that I am supposed to replace the generic ID by my
> > own, yet I don't know how :)
> 
> Even a generic ID in the payload should be fine for whatever is looking at
> the payload.
> Usually the application creating an event is setting the UID.
> Most resources don't need to change the payload at all (they just save and
> load the data as it is).

The problem with payload UID is that when user changes the event via Google 
Calendar web interface and then synchronizes the resource, the UID is updated 
as well together with the other informations . And that's not OK, I think that 
UID should remain constant for the lifetime of the event, not changed after 
first synchronization.

> 
> I think this is unrelated to your other problem. For this one check if the
> payload has an UID. If not whatever program created it should have set one.

OK, I'll investigate this later, when the first issue is resolved :)

Cheers,
Dan

> 
> Cheers,
> Kevin
-- 
---
Dan Vrátil
www.progdan.cz
dan at progdan.cz
Jabber: progdan at jabber.cz

Tento email neobsahuje žádné viry, protože odesílatel nepoužívá
Windows. / This email does not contain any viruses because the sender does not 
use  Windows.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111124/304da5fa/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/