Previously have applying a change, the screen would be refreshed
and the email address would still be getting edited. This correctly
refreshes the screen to show that the email address editing is finished.
Groups really only exist in the davical web interface, CALDAV clients
discover principals and collections based on GRANTs such as the
DAV::read privilege, so use that for the web interface as well.
Also, not listing users is nice, actually blocking access to those users
(which can be enumerated with the id GET parameter) is a lot better.
unfortunately, $id is a principal_id, not a user_no - these match only
for admin. Similar changes will be necessary for adding and updating an
email address.
changing the "primary" address does not work and may need some thought
wrt/ UNIQUE
the 'usr' table is actually from AWL, and no-one has done any schema
management there yet; however there's precedent in davical's
dba/patches/1.1.4.sql that that was just upgraded from davical...
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.
http://php.net/manual/en/function.setlocale.php says "Different systems
have different naming schemes for locales." This seems to be true for
platforms (eg Win vs. Linux), but on Debian AFAIR locales were always at
least two-part (de_DE), never just one (de). This seems to have been
broken in 504651a3, likely by mistake.
Also, switch locale immediately, even before writing to the database.
BTW, what happens when system default locale is configured to e.g. fr_FR
and the user selects "English" - does that work?
Same with external URLs
Also restrict Delete buttons on incoming binds to Admins: these binds
will usually live in other people's namespace, which we should not
alter, and may be restricted to default privileges (e.g. freebusy)
anyway
Previously, only the Admin or the principal herself could delete a
collection. Deletion is immediate and irreversible, so there is a risk
in allowing this. But it doesn't make sense to allow the creation of a
test collection and then block the subsequent clean-up.
* Changed the end-of-line encodings of all non-Windows-related and non-autogenerated text files to use UNIX LF (lots of them had mixed LF/CRLF).
Conflicts:
inc/caldav-PUT-functions.php
Correct logic for auto-creating addressbook for new user.
Fix non-creation of default addressbook.
Fix principal/collection edit to allow write of no privileges.
Fix collection edit timezone list to use new table.
Update davical & libawl version in always.php.
Regression test changes with update to davical.sql.
This is a significant refactoring, replacing the old getUserBy*()
functions with a new Principal class, and replacing the old
CalDAVPrincipal class with a new DAVPrincipal class which extends
the Principal class.
At this point all regression tests pass (again) but there could
well be issues for people who use alternative authenticators
such as LDAP, although I have endeavoured to resolve those
potential issues.
Signed-off-by: Andrew McMillan <andrew@morphoss.com>
