forked from pool/python-caldav
- Add drop-python2-support.patch to remove python-six dependency
gh#python-caldav/caldav#228 - Remove python_module macro definition - Update to 0.10.0 ## Quick summary * Work on a universal search method * Refactoring, consolidated lots of slightly duplicated code into one method to rule them all * Support for things needed by the calendar-cli utility, like search by categories * Support for completion of recurring tasks * More utilities for tasks * Uncomplete-method ... for undoing the complete (recurrences not supported though) * get/set duration/dtstart/dtend (arguably this belongs to vobject and/or icalendar) * Other improvements: * picklable URLs * display_name convenience method * possible to set child/parent relationships * Potential bugfix: sequence number may need to be increased when saving something to the calendar (not backported, this may have side effects) ## Search method Calendar now has a method search. Here is some information from the docstring: Parameters supported: * xml - use this search query, and ignore other filter parameters * comp_class - set to event, todo or journal to restrict search to this resource type. Some server implementations require this to be set. * todo - sets comp_class to Todo, and restricts search to pending tasks, OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-caldav?expand=0&rev=24
This commit is contained in:
@@ -1,3 +1,81 @@
|
||||
-------------------------------------------------------------------
|
||||
Thu Nov 3 17:38:12 UTC 2022 - Daniel Garcia <daniel.garcia@suse.com>
|
||||
|
||||
- Add drop-python2-support.patch to remove python-six dependency
|
||||
gh#python-caldav/caldav#228
|
||||
- Remove python_module macro definition
|
||||
- Update to 0.10.0
|
||||
## Quick summary
|
||||
* Work on a universal search method
|
||||
* Refactoring, consolidated lots of slightly duplicated code into one
|
||||
method to rule them all
|
||||
* Support for things needed by the calendar-cli utility, like search by
|
||||
categories
|
||||
* Support for completion of recurring tasks
|
||||
* More utilities for tasks
|
||||
* Uncomplete-method ... for undoing the complete (recurrences not supported
|
||||
though)
|
||||
* get/set duration/dtstart/dtend (arguably this belongs to vobject and/or
|
||||
icalendar)
|
||||
* Other improvements:
|
||||
* picklable URLs
|
||||
* display_name convenience method
|
||||
* possible to set child/parent relationships
|
||||
* Potential bugfix: sequence number may need to be increased when saving
|
||||
something to the calendar (not backported, this may have side effects)
|
||||
|
||||
## Search method
|
||||
Calendar now has a method search. Here is some information from the
|
||||
docstring:
|
||||
|
||||
Parameters supported:
|
||||
* xml - use this search query, and ignore other filter parameters
|
||||
* comp_class - set to event, todo or journal to restrict search to this
|
||||
resource type. Some server implementations require this to be set.
|
||||
* todo - sets comp_class to Todo, and restricts search to pending tasks,
|
||||
unless the next parameter is set ...
|
||||
* include_completed - include completed tasks
|
||||
* event - sets comp_class to event
|
||||
* text attribute search parameters: category, uid, summary, omment,
|
||||
description, location, status
|
||||
* expand - do server side expanding of recurring events/tasks
|
||||
* start, stop: do a time range search
|
||||
* filters - other kind of filters (in lxml tree format)
|
||||
* sort_keys - list of attributes to use when sorting
|
||||
|
||||
not supported yet:
|
||||
* negated text match
|
||||
* attribute not set
|
||||
|
||||
## Completed tasks
|
||||
While the RFCs do support recurring tasks, they are not very clear on the
|
||||
details. In v0.10 there are three different ways to complete a task. The
|
||||
first one is to ignore the RRULE property and mark the task as completed.
|
||||
This is the backwards-compatibility mode - though, according to my
|
||||
understanding of a "recurring task" this is the wrong way to do it.
|
||||
|
||||
The two other modes considers the task to be "interval based" is no BY-rules
|
||||
are specified in the RRULE - meaning that if a task is supposed to be done
|
||||
weekly, then a week should pass from it was completed and until one needs to
|
||||
start with it again - no matter the DTSTART of the original instance - but
|
||||
the standards may also be interpreted so that if the original task was to be
|
||||
started at a Tuesday 10:00, then all recurrences should be started at a
|
||||
Tuesday 10:00.
|
||||
|
||||
Both the modes stores a copy of the completed task, for the record. The
|
||||
"safe" mode stores the copy as a completely independent task, and modifies
|
||||
the DTSTART/DUE of the original task - so the completed task is not linked up
|
||||
to the recurring task. (One may eventually try to make a link by
|
||||
establishing a "parent task").
|
||||
|
||||
The "thisandfuture"-mode will establish the completed task as a separate
|
||||
recurrence in a recurrence set. The non-completed task is also duplicated
|
||||
with a new DTSTART set and range set to THISANDFUTURE. As I understand the
|
||||
RFC, this is the way to handle interval-based tasks, future recurrences will
|
||||
then base their starting time on the DTSTART of the THISANDFUTURE task. For
|
||||
fixed tasks the THISANDFUTURE recurrence is moot, so I'm considering to
|
||||
create a third mode as well.
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Thu Oct 13 17:50:47 UTC 2022 - Axel Braun <axel.braun@gmx.de>
|
||||
|
||||
|
Reference in New Issue
Block a user