1
0
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:
2022-11-03 17:41:50 +00:00
committed by Git OBS Bridge
parent a935d5ae4d
commit 46e714b95a
5 changed files with 359 additions and 8 deletions

View File

@@ -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>