Gosh. The logic was saying, if the modified date has a day of the
month > 28, change it to 28. Which is rather odd. Don't do that.
This closes#248. It also fixes a bug with FREQ=MONTHLY;BYMONTHDAY=-1
as it turns out.
RFC 4791 clearly states in 7.10:
Only VEVENT components without a TRANSP property or with the TRANSP
property set to OPAQUE, and VFREEBUSY components SHOULD be considered
in generating the free busy time information.
Looking at fa67ef987e, this used to be VFREEBUSY until the refactoring, and
0886-REPORT-freebusy.test still had that.
Apparently we're not (yet) considering VAVAILABILITY (RFC 7953) here.
Turns out it was returning a sorted list based on a generated uuid, which
could be different in different regression environments. When I was
running tests locally I was always using the same initial.dbdump
file. The tests now pass even with a truely fresh regression DB.
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.
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>
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.
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
From version 10, Postgresql does not allow set-returning functions in
CASE statements. As we're using the functions recursively, we cannot
use LATERAL as suggested in the error message, but we can switch the
condition inside-out with only a limited amount of repetition.
Changed line wrapping in awl is one major reason for etag changes.
With this commit, all tests in regression-suite, binding and carddav
pass for me, using the configuration outlined in README.regression_tests
