This is to be consistent with group_mapping_field. The code is backwards
compatible with mapping_field.
In sync_LDAP_groups assign user_mapping once, not for every group.
Usinger "username" for the group name is confusing and misleading. Just
use name, but support our users who still have username.
We don't use fullname, drop it from the example.
The phpversion check was backwards. For PHP >= 5.4.0 we should be
using session_status() === PHP_SESSION_ACTIVE not < 5.4.0.
But in fact, we only support >= 5.4.0, so this check is now redundant.
The RepeatRuleDateTime constructor extracts the date's time zone then
passes it to the parent class DateTime. Because PHP's DateTime has full
support for time zones, it compensates for them when parsing a string.
Normally this isn't a problem, because the opposite occurs when a
DateTime is converted back into a string; the two adjustments cancel
each other.
Davical often converts a time to UTC by negating the time zone offset
and adding it to the underlying DateTime (keeping the time zone intact).
A problem occurs when the result is on the other side of a daylight-
saving-time transition. In that case the adjustments do not cancel and
an incorrect time string is returned.
This bug is tricky because the problem doesn't manifest during the DST
transition iself, but hours earlier or later depending on the original
time zone. For example, 2022-03-12T18:30:00-08:00 (America/Los_Angeles)
is 2022-03-13T02:30:00Z. Since 2022-03-13 is a 23-hour day in the Los
Angeles time zone (the 2AM-3AM hour is skipped) this becomes
2022-03-13T03:30:00-07:00 after adding the negated offset. FloatOrUTC()
would strip the new offset and simply return "20220313T033000".
To allow for correct expansion of recurring confidential information
we also need to retain EXDATE, RECURRENCE-ID and SEQUENCE, otherwise
client side expansion may well be wrong.
Closes#291
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.
