despite its name, $c->do_not_sync_from_ldap did not stop accounts in
LDAP from being created in Davical, it only stopped accounts not in LDAP
from being deactived in Davical (like a local admin account)
The calendar-sync REPORT fetches the collection as a DAVResource, then
instantiates a DAVResource for each event in the collection.
Unfortunately, ByRow in DAVResource fetches the resource's collection from the
database!
This commit populates each DAVResource's collection field with the
already-fetched collection when performing calendar-sync queries.
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
PHP 7.1 throws an exception when a user-defined function is called with
too few arguments: http://php.net/manual/en/migration71.incompatible.php
As explained in the comments, collection_privilege_format_function and
principal_privilege_format_function take three arguments because of
their use as a rendering callback, however the latter two of them are
never used and thus can be ommitted in other uses.
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.
