Bug 328846 - Kolab agent doesnt download information about recurring task due
Summary: Kolab agent doesnt download information about recurring task due
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Kolab Resource (show other bugs)
Version: unspecified
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL: http://bugs.debian.org/cgi-bin/bugrep...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-15 20:59 UTC by Franz Schrober
Modified: 2017-01-07 22:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Franz Schrober 2013-12-15 20:59:55 UTC
I've just installed a new machine and added my IMAP server and kolab agent to
akonadi. It downloaded all resources but when I've started to edit some tasks
I've noticed that the due data was missing. Also entering it again resulted in
missing due dates (like it was never entered) on all other machines also using
the same IMAP server with kolab. Interestingly the date was correctly stored
on the server

The important part here seems to be that the task was recurring.

Ways to reproduce: create an imap account in akonadi (using KDE systemsettings
or so), add a kolab agent with the default settings (v3) using this imap
server, press "create folders", create a new task in the activated task
folder in korganizer, add a start date, due date, mark it as all-day and
recurrance (monthly on the 1th) save it.
Now open the mail on the imap server and check for the due information. It
should everything be there.

akonadiconsole on this machine shows following information in the "raw payload"
view of the kolab task folder item:

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VTODO
DTSTAMP:20131215T191632Z
CREATED:20131215T191632Z
UID:89e18570-25e1-4708-a8b5-2321bac3243a
LAST-MODIFIED:20131215T191632Z
SUMMARY:asd
RRULE:FREQ=MONTHLY;BYMONTHDAY=1
DUE;VALUE=DATE:20131215
DTSTART;VALUE=DATE:20131201
PERCENT-COMPLETE:0
X-KDE-LIBKCAL-DTRECURRENCE;VALUE=DATE-TIME:20131201T201600
END:VTODO

END:VCALENDAR


Up to here everything seems to be fine. But now add the same imap server/kolab
on another account/machine and download the task items there. The due information
completely disappeared and it looks in the overview like there is no "due: at all
(not marked red). The akonadiconsole show following output in the raw payload
information:

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
X-KDE-ICAL-IMPLEMENTATION-VERSION:1.0
BEGIN:VTODO
DTSTAMP:20131215T191632Z
CREATED:20131215T191632Z
UID:89e18570-25e1-4708-a8b5-2321bac3243a
LAST-MODIFIED:20131215T191632Z
SUMMARY:asd
RRULE:FREQ=MONTHLY;BYMONTHDAY=1
DTSTART:20131117T000000
PERCENT-COMPLETE:0
END:VTODO

END:VCALENDAR

So the DUE is missing, the DTSTART is now with time (and wrong) instead of
all-day and this X-KDE-LIBKCAL-DTRECURRENCE is now missing (I don't know
what this is). Interestingly the DTSTART date is also stored on the server
and is not what I've entered. I will create an extra bug for that later

I've used the 1th of December as start date and the 15th of december as due date.
I was happy that the item was marked red (because today it is the 15th) on the
main machine and when I clicked on the item and marked it as complete then the
"Due Date/Time" jumped from 01.12.2013 to 01.01.2014. This functionality is
completely missing on the non-main machine which only downloaded the information
over kolab.

Reproducible: Always
Comment 1 Denis Kurz 2016-09-24 20:44:00 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 2 Denis Kurz 2017-01-07 22:48:28 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.