We want to store the calculated dtstart and dtend in the database so we can
use SQL to fetch records. However, we also need what the user sent us so we
can allow prop-filters to be used as well.
So we store what the user sends us in dtstart_orig and dtend_orig and only
use for relevant prop-filter reports.
As specified in RFC5545 the CLASS field is optional, and if it isn't present
is treated as PUBLIC. To allow a is-not-defined prop-filter to find
resources without CLASS set, we need to not store in the database. This
turns out to be okay, because to enforce privacy we always check to see if
it is PRIVATE or CONFIDENTIAL. We never check to see if it is PUBLIC.
Closes#284.
- only some event attributes modified by the organizer get also modified in attendees' instances of the event,
- revoked invitations mark the according attendee's event appropriately,
- a changed event time resets all attendees' PARTSTAT to NEEDS-ACTION.
Previously if an addressbook was an external resource, then all local
info was deleted, and all the remote addressbook entries were
re-inserted, potentially creating new sync tokens.
This change only updates modified records.
DTSTART/DTEND can be DATE values instead of DATE-TIME. Our database uses
TIMESTAMP WITH TIME ZONE as field type, which seems to accept 19011224
but not values before 1900, such as 18961224. This patch changes values
between 1000 and 1900 to DATE-TIME by adding "T000000Z"
Patch contributed by Benedikt Spranger <b.spranger@linutronix.de>
Patch limited to dates between 1000 and 1900 by Florian Schlichting
<fsfs@debian.org>
* Changed the end-of-line encodings of all non-Windows-related and non-autogenerated text files to use UNIX LF (lots of them had mixed LF/CRLF).
Conflicts:
inc/caldav-PUT-functions.php
Only applies to PUT of a collection. This will mean that only events
after that date (or absolute duration prior to today). All repeating
events will still be included.
Hi,
this proposed patch does the following:
- When an attendee (not the organizer) modifies an object, these modifications should be applied completely to that user's instance of the object. However, the organizer's and other attendees' instances should not be modified in most aspects: Only the attendee's own PARTSTAT modification should be distributed to the organizer's and other attendees' instances. E.g. modifications on VALARMs or TRANSP settings are individual to that single user that sends the modification.
However, I have doubts whether the organizer should be able to apply such modifications on all attendees' instances, once they exist for other attendees. Currently, I did not yet change this behavior.
- When a user receives an invitation in his schedule-default-calendar, he might move it to another calendar. When a subsequent modification to the event arrives, another instance (with the same UID!), is created in the schedule-default-calendar. This patch makes the server search for an instance of the event in any of the receiving user's calendar, so that no event duplicates are created.
I am not really familiar with the code as a whole, so that the way I implemented these changes is probably not "correct".
Regards,
-frank
This adds another hook, and makes log_caldav_action() regular
across both PUT and DELETE (in a transaction), adding post_commit_hook()
as a method with the same signature which is called after the actual
commit, and also matches in both cases.
We only write events which differ, and only delete events which aren't
present in the new upload. If done in append mode then events which
already exist will be updated more cleanly too.
