Bug 321394

Summary:	Tasks without a start date generate invalid iTIP invitations
Product:	[Applications] kdepimlibs	Reporter:	Andre Heinecke <aheinecke>
Component:	kcalcore	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	smartins, winter
Priority:	NOR
Version:	GIT (master)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	Invitation to a todo without a dtstart as generated by Kontact / KOrganizer

Description Andre Heinecke 2013-06-19 16:03:36 UTC

If you create a task in kOrganizer without a start date and invite someone else to this task the invitation generated is not conformat to RFC5546 because it does not contain a DTSTART ( http://tools.ietf.org/html/rfc5546#section-3.4.1 ).

According to rfc2445 section 4.6.2 and the Kolab (at least v2 Format) Tasks may not have a DTSTART so I am unsure what the correct fix for this is for those tasks. Should there be dtnow() as start or should the due date be the start, or should the due date - duration be the start date?

Reproducible: Always

Steps to Reproduce:
1. Create an task without a start date (disable the start checkbox in the incidenceditor)
2. Add an attendee to this task and send him a mail
3. Check out the mail



Problem also exists in the golden e 3.5 series ;)

Comment 1 Andre Heinecke 2013-06-19 16:13:17 UTC

Created attachment 80640 [details]
Invitation to a todo without a dtstart as generated by Kontact / KOrganizer

Comment 2 Sergio Martins 2013-07-10 21:08:43 UTC

maybe itip messages should simply not be sent for to-dos without DTSTART ?

Comment 3 Allen Winter 2013-07-12 00:14:20 UTC

or at least we need to warn and give the user the opportunity to add a DTSTART.

"you are attempting to email a TODO without a starting datetime to a group of people. You can't do that". would you like to add a starting datetime to this TODO now?  Saying No means this  TODO will not be sent.

Comment 4 Denis Kurz 2016-09-24 20:55:16 UTC

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kdepim (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.

Comment 5 Denis Kurz 2017-01-07 22:11: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.