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.
If we force setting DTSTART, then you can't use prop-filter to find VTODOs
with a DUE set and DTSTART unset. And, well, why should DTSTART be set to DUE?
This was introduced in 18150d702d91fa1a687801baa582d967e79fff8d .
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.
Gosh, this was completely broken previously. A number of different scenarios now work.
I have used some of the state I've seen in a largish production database with the
presence of NULL and empty strings. I've assumed that empty string should be treated
as is-not-defined. Happy to be talked out of that.
Closes#281.
This was causing binding/1038-PROPFIND-Depth-2 to fail as the getctag that
was found didn't match what was expected. Looking at how bound collections
are handled, there is a lot of metadata that we're missing.
Preferably we'd cache or otherwise restore that metadata, but I'm going
to leave that as a future enhancement. ;)
The test regression-suite/0549-iCal-REPORT was failing due to us not
keeping track of the proxy information when storing/fetching collections
from the cache.
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.
With complex rules, it make take more than 10 expansions to find the
next valid date. Increase this to 100, it doesn't slow things down too
much.
I've also added some additional error logging if this issue occurs
again.
Closes#268.
Previously the logic only set Pacific/Auckland if the date.timezone setting
on the PHP ini files wasn't set. Let's just always set it if we're processing
the test suite.
PHP 8.2 deprecates dynmically adding properties. See:
https://php.watch/versions/8.2/dynamic-properties-deprecated
This arbitary copying of all fields tickles these deprecation
warnings, and just below we copy exactly the fields we need.
I reckon this loop is redundant.
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.
