6.0.0-beta1
7/8/25

[#8703] %-completion on tasks submitted by Kontact/Akonadi is not accepted
Summary %-completion on tasks submitted by Kontact/Akonadi is not accepted
Queue Nag
Queue Version FRAMEWORK_3
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester bugs.horde.org (at) sjau (dot) ch
Created 11/12/2009 (5717 days ago)
Due
Updated 04/09/2010 (5569 days ago)
Assigned 11/12/2009 (5717 days ago)
Resolved 11/30/2009 (5699 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
04/09/2010 08:53:26 AM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #13 Reply to this comment
Well, right now it's not interoperable. That's the whole thing. Both 
parties say they do it right yet in the real world it does not work 
although both parties say they do it right. The effect is that it's 
not working because both parties think they do it right.
03/17/2010 04:12:49 PM Jan Schneider Comment #12 Reply to this comment
This has nothing to do with the will to go one step ahead. It's about 
interoperability. If we change it to make it work with Akonadi, it's 
going to break with other clients. Btw, the only response on the RFC 
mailing list interprets the RFC like I do.
03/11/2010 02:29:10 PM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #11 Reply to this comment
Any news on this?

The problem I face right now is that the Horde people say it's 
Akonadi's fault. They don't do it correctly. And the Akonadi people 
say it's Horde's fault. They don't do it correctly.

In the end the result is, that it just doesn't work because neither 
party is willing to go one step ahead and make it work.
01/13/2010 02:47:22 PM Jan Schneider Comment #10 Reply to this comment
This is exactly how the example at the end of section 3.6.2 of RFC 
5545 looks (modulo the PERCENT-COMPLETE). That example gives a 
completed todo with a STATUS:NEEDS-ACTION...
Of course, it's coming from Akonadi. ;-)

I still think the example is wrong and contradicts what is written 
earlier in the RFC. Let's see if anything come out of the mailing list 
message. Thanks for writing that message.
01/13/2010 02:22:13 PM reinhold (at) kainhofer (dot) com Comment #9 Reply to this comment

[Show Quoted Text - 17 lines]
This is exactly how the example at the end of section 3.6.2 of RFC 
5545 looks (modulo the PERCENT-COMPLETE). That example gives a 
completed todo with a STATUS:NEEDS-ACTION...

01/13/2010 01:55:17 PM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #8 Reply to this comment
A request for clarification on how a task should be marked as completed:

http://lists.osafoundation.org/pipermail/ietf-calsify/2010-January/002234.html
01/13/2010 01:45:46 PM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #7 Reply to this comment
[14:39] <reinhold> hyper_ch: Regarding your STATUS:COMPLETED vs. 
PERCENT-COMPLETE:100, the rfcs 2445 and  5545 (the successor to RFC 
2445) do not require STATUS:COMPLETED to be set. Actually, it does not 
specify at all how completion should be indicated. There are three 
completion settings: STATUS:COMPLETED, COMPLETED:Date-Time, 
PERCENT-COMPLETE:100
[14:41] <reinhold> hyper_ch: Actually, the example at the end of 
section 3.6.2 shows a completed todo with STATUS:NEEDS-ACTION... See 
http://pastebin.org/75500
[14:41] <reinhold> hyper_ch: That might be an oversight, though.
11/30/2009 01:01:52 PM Jan Schneider Comment #6
State ⇒ Not A Bug
Reply to this comment
Re-reading RFC 2445 again, I'm pretty sure that Akonadi is wrong. They 
use the PERCENT-COMPLETE property to indicate the task status instead 
of the STATUS property like Nag does. RFC 2445 says:

Property Name: PERCENT-COMPLETE
Purpose: This property is used by an assignee or delegatee of a to-do 
to convey the percent completion of a to-do to the Organizer.

Property Name: STATUS
Purpose: This property defines the overall status or confirmation for 
the calendar component.
Description: In a group scheduled calendar component, the property is 
used by the "Organizer" to provide a confirmation of the event to the 
"Attendees".

So the difference is that PERCENT-COMPLETE is used by attendees to be 
consumed by organizers, while STATUS is used by organizers to be 
consumed by attendees. Editing and saving a task on the (Nag) server 
is done by the task organizer (or anyone with the same permissions) 
and authoritative for anyone consuming this task. This is *not* an 
update from an attendee sent to the organizer. The RFC even explicitly 
mentions that PERCENT-COMPLETE is per attendee, so that attendees can 
report back different completion states for their parts of the task. 
It is *not* to be stored with the task. How should that work anyway if 
this a property of the VTODO component but can be different for each 
attendee?
11/12/2009 02:08:38 PM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #5 Reply to this comment
After having put that into the rpc.php and into the nag api.php (at 
_nag_import() and _nag_put() ) I finally got this in the log:

BEGIN:VTODO
DTSTAMP:20091112T140441Z
ORGANIZER:MAILTO:email@email.address
CREATED:20091112T075928Z
UID:libkcal-1455987314.377
SEQUENCE:1
LAST-MODIFIED:20091112T140416Z
SUMMARY:test task
STATUS:NEEDS-ACTION
PRIORITY:5
DUE:20091118T230000Z
COMPLETED:20091112T140416Z
PERCENT-COMPLETE:100
END:VTODO

11/12/2009 01:20:42 PM Jan Schneider Comment #4 Reply to this comment
If I knew how to grab it with a network logger or is there  a way 
that the rpc.php dumps all queries into a log?
Try adding:

Horde::logMessage($input, __FILE__, __LINE__, PEAR_LOG_ERR);

(or whatever your minimum error log level is) to rpc.php, right before 
the getResponse() call.
As far as I was told in the akonadi channel is, that this has been 
discussed before and that they determined that horde was the culprit.
Great for them if this has been discussed before, but it doesn't help 
if no one actually reports it back to us.
11/12/2009 01:10:29 PM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #3 Reply to this comment
In #akonadi on freenode I was told that it's horde's fault for not
"accpeting" those changes.
Only if Akonadi is correctly sending the completion state. Does the 
console show the actually iCalendar object that is being sent to 
Horde, or can you grab it with a network logger?
If I knew how to grab it with a network logger or is there  a way that 
the rpc.php dumps all queries into a log?

As far as I was told in the akonadi channel is, that this has been 
discussed before and that they determined that horde was the culprit.

[Wednesday, 11. November 2009] [13.51:57] <volker|office>       this 
has been discussed here before, IIRC horde ignores the percent-done 
field apparently
[Wednesday, 11. November 2009] [13.52:30] <bbroeksema|offic>     
well...... then go bug horde people =:)
[....]
[Wednesday, 11. November 2009] [14.04:14] <bbroeksema|offic>    well, 
than see volkers comments =:)
[Wednesday, 11. November 2009] [14.04:30] <bbroeksema|offic>    this 
seem to been discussed before
[Wednesday, 11. November 2009] [14.05:47] <hyper_ch>    ok
[Wednesday, 11. November 2009] [14.08:29] <bbroeksema|offic>     
hyper_ch: The best you can do is contacting horde developers and check 
if this is a known issue for your version of the horde server

11/12/2009 12:59:46 PM Jan Schneider Comment #2
State ⇒ Feedback
Reply to this comment
In #akonadi on freenode I was told that it's horde's fault for not 
"accpeting" those changes.
Only if Akonadi is correctly sending the completion state. Does the 
console show the actually iCalendar object that is being sent to 
Horde, or can you grab it with a network logger?
11/12/2009 07:56:32 AM bugs (dot) horde (dot) org (at) sjau (dot) ch Comment #1
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ Nag
Summary ⇒ %-completion on tasks submitted by Kontact/Akonadi is not accepted
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
I currently use Kontact 4.3.3 and I have setup webdav on the Horde server.

In Akonadi I can either chose eiterh "ICal Calendar File" (which uses 
Akonadi directly) or "KDE Calendar (traditional)" (which uses KCal 
IIRC). For either one I set the resource file like:

webdav://www.domain.com/horde/rpc.php/nag/USER/USER.ics

What works:
- I can add new tasks in Kontact and they will get added to horde
- I can delete tasks in Kontact and they will get added to horde
- I can edit tasks and the changes will be transmitted to horde

What does not work:
When check the box in Kontact that the task is done, it transmits it 
to Akonadi (check with Akonadi console) and it vanishes from my 
filtered list (Akonadi sets it as 100%). However this change is not 
being transmitted to horde. In Horde the task still remains as 
"active" / "undone". When then Akonadi syncs again with the Horde data 
it will unset that task and it appears in kontact undone again.

In #akonadi on freenode I was told that it's horde's fault for not 
"accpeting" those changes.

Saved Queries