| Summary | Add support for recurring tasks |
| Queue | Nag |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Assigned |
| Priority | 1. Low |
| Owners | Gunnar Wrobel <p (at) rdus (dot) de> |
| Requester | kevin_myer (at) iu13 (dot) org |
| Created | 06/17/2005 (1477 days ago) |
| Due | |
| Updated | 11/05/2008 (240 days ago) |
| Assigned | 11/05/2008 (240 days ago) |
| Resolved | |
| Attachments | HK-GW-Recurrence[3].patch ![]() |
| Milestone | 3.0 |
| Patch | No |
Assigned to Gunnar Wrobel
State ⇒ Assigned
State ⇒ Feedback
renderer still includes HTML code that doesn't belong there. Field
renderers must only contain the code for the actual fields. You add
all kind of form row layout that is the job of the form renders (as
opposed to the field renderer). If you want to add more then one
(html) field in the form field renderer, separate them by simple
breaks, or what ever fit your needs, but don't re-use or interrupt the
regular form rendering with tables (because other renderers than the
default might use a different rendering technique than tables).
New Attachment: HK-GW-Recurrence[3].patch
State ⇒ Assigned
I added the required JavaScript functionality now. So the patch should
be complete feature wise.
I'm still a layman when it comes to JS and Horde Forms. So there might
be some JS corrections necessary. As usual I'm open to suggestions :)
Thanks!
New Attachment: HK-GW-Recurrence[2].patch
There are some java script issues left and the whole recurrence part
should only be shown if there exists a due date for the task. Maybe it
is already okay for a first commit and some polishing in CVS.
http://cvs.horde.org/co.php/nag/lib/Recurrence.php?r=1.1
Util::getFormData() and Nag_Recurrence instead of
Horde_Date_Recurrance. And we probably have to use different
constant names to avoid collisions when showing tasks in Kronolith.
I just see you already did this, but you don't use them everywhere
yet.
Either you need different form fields for the different recurrence
settings, or you have to implement the complete widget in a single
cell, like any other form field.
renderers work.
instance. Instead, you should store the completion of a single
recurrence, similar to how exceptions are stored at the moment. And
of course we should (at some point, not necessarily from the start)
add the ability to actually create exceptions.
New Attachment: HK-GW-Recurrence[1].patch
instance. Instead, you should store the completion of a single
recurrence, similar to how exceptions are stored at the moment. And
of course we should (at some point, not necessarily from the start)
add the ability to actually create exceptions.
support in recurrences as
bug #7029Patch ⇒ 1
Milestone ⇒ 3.0
State ⇒ Feedback
Util::getFormData() and Nag_Recurrence instead of
Horde_Date_Recurrance. And we probably have to use different constant
names to avoid collisions when showing tasks in Kronolith. I just see
you already did this, but you don't use them everywhere yet.
The varrenderers won't work the way you implemented them though.
Either you need different form fields for the different recurrence
settings, or you have to implement the complete widget in a single
cell, like any other form field.
And you shouldn't create new tasks when completing one recurrence
instance. Instead, you should store the completion of a single
recurrence, similar to how exceptions are stored at the moment. And of
course we should (at some point, not necessarily from the start) add
the ability to actually create exceptions.
But beside that, it looks very promising, nice work!
New Attachment: HK-GW-Recurrence.patch
for the kolab driver so far. Does this go into the right direction?
Summary ⇒ Add support for recurring tasks
Type ⇒ Enhancement
Priority ⇒ 1. Low
State ⇒ New
Queue ⇒ Nag
to use the recurrence portion of the iCalendar spec.