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 |
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.
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.
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.
5545 looks (modulo the PERCENT-COMPLETE). That example gives a
completed todo with a STATUS:NEEDS-ACTION...
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.
5545 looks (modulo the PERCENT-COMPLETE). That example gives a
completed todo with a STATUS:NEEDS-ACTION...
http://lists.osafoundation.org/pipermail/ietf-calsify/2010-January/002234.html
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.
State ⇒ Not A Bug
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?
_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
that the rpc.php dumps all queries into a log?
Horde::logMessage($input, __FILE__, __LINE__, PEAR_LOG_ERR);
(or whatever your minimum error log level is) to rpc.php, right before
the getResponse() call.
discussed before and that they determined that horde was the culprit.
if no one actually reports it back to us.
"accpeting" those changes.
console show the actually iCalendar object that is being sent to
Horde, or can you grab it with a network logger?
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
State ⇒ Feedback
"accpeting" those changes.
console show the actually iCalendar object that is being sent to
Horde, or can you grab it with a network logger?
Patch ⇒ No
State ⇒ Unconfirmed
Milestone ⇒
Queue ⇒ Nag
Summary ⇒ %-completion on tasks submitted by Kontact/Akonadi is not accepted
Type ⇒ Bug
Priority ⇒ 1. Low
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.