Test that other users can't delete:
- collections
- tickets
- bindings
No significant change, just return an error message rather than assume that
things worked.
There is now a Perl script that'll generate tests and result files to a
wide variety of dates. From this we currently don't support < 1 AD or >
9999 AD.
run_regressions is modified to remove the UNTIL option as I want to use a
character after the test number to allow "subtests".
postgresql is fussy about dates before 1900. Add a test with a recuring
event startting before 1900.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
There is potential to leak information when viewing the principal
page for another principal. I think it makes more sense to just
not include all of this information unles the user can change the
principal.
Previously PHP was escaping things like ampersands, which then caused
us to have broken URLs.
These aren't displayed anywhere in the UI, so no need to encode them anywhere.
Closes#314.
Previously something like this would be logged if debugging is enabled:
davical: LOG: Principal: Query: DBGQ: SELECT * FROM collection WHERE user_no= :user_no
davical: LOG: Principal: Query: DBGQ: ":user_no" => ""
davical: BUG: :DAViCal Fatal Error: [42883] SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer = boolean\nLINE 1: SELECT * FROM collection WHERE user_no= FALSE\n ^\nHINT: No operator matches the given name and argument types. You might need to add explicit type casts. at /home/puck/work/Calendar/awl/inc/AwlDatabase.php:94
And this would be returned as a response:
DAViCal Fatal Error
user_no doesn't get set when construction the Collection for the external
bind, so, just handle that instead of sending the empty string to the
database as a user_no.
Modify the tests from ccc7e182ba4cbfba66a4fe96e1c0620e46390b95 to tickle the
bug.
Closes#175.
This is to tickle #291. The only test that is actually required is
2603-GET-resource-confidential, but I want to make sure all the options were
correct.
In this commit 2603-GET-resource-confidential is expected to fail.
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.
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.
