The todo item added in 0514-iCal-PUT-VTODO.test was apparently not picked up by
the PL/pgSQL functions, which as far as I can tell is an error, since the event
is in the 2006-2007 range covered by the query. The new
first_instance_start/last_instance_end method for determining freebusy
information now allows the todo to appear in freebusy.
I think these remaining changes are due to AWLs vCalendar->GetItip()
creating a "minimal iTIP version" of events, and Jan Mate's "various
scheduling related fixes" in 31af435c and 92f48f38
Normalize results so tests work with newer and older versions
This change is similar to e565cc0a5e4af0330fe5a1ab6f2476be7fb10df4 and
following
From the Apache 2.4.35 changelog:
*) http: Enforce consistently no response body with both 204 and 304
statuses. [Yann Ylavic]
dead_properties is an assoc.array from name to value, but it was being merged
with simple arrays of property names.
This means that tests 0824 and 0828 now actually return the dead properties, so
I've updated those result files.
Signed-off-by: Jamie McClymont <jamiemcclymont@catalyst.net.nz>
Gitlab CI has a different collection_id for US Holidays than running
the tests locally. We don't actually care about ID for this test,
just the fact that the binding is present is enough for us.
In the GitLab CI environment, the command:
@header("Content-Type: text/plain");
Generates the Content-Type line of:
Content-Type: text/plain; charset=UTF-8
But on my workstation it generates this:
Content-Type: text/plain;charset=UTF-8
By adding that charset to our call to @header, we receive a
predictable result.
Primary fix is the search_path to ensure that the collection table
is in the search path so that the copy into dav_binding (and
possibly others) will work.
I also suppressed the warning about plpgsql.
- 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.
Otherwise we cannot be sure if the resource we are looking at is a
proxy. Looking at the request as we did in DAVPrincipal is wrong, as one
request can result in several resources to be examined, only some of
which may be proxies.
BTW looking at the regression test changes, I'm not sure having
calendar-proxy-read-for on proxy principals is correct, but caldav-proxy
seems to have nothing to say on that so we leave it for now.
and a few more bits inspired by CalDAV/aclreports.xml:
- strict Depth header checking
- principal-match: match on dav_name if not $match_self
- principal-match can "alternatively" return resources in a collection
that belong to a principal, like a user's calendars when we query
the principal URI
