users and groups:
* No: Every user can invite other users and groups (default and old
behavior)
* Groups: other users can allways be invited, only groups require an invite_grant
* Users + groups: inviting both allways requires an invite grant
One need to keep in mind, that setting an invitation ACL via a group,
gives each groupmember the right to invite the group / create a group
event. So the last option propable only works, if users manage
invitations grants on their own, or admin only sets it in small working
groups, where every member is allowed to invite the whole group.
--> calendar backend code removes participants a user is not allowed
to invite
- new "only groupevents" filter, showing only real groupenvents not
events of groupmembers (added tooltips to explain filters)
Please note: timestamps in egw_cal* tables are in server-time,
tz_id / timezone is only used to (re-)calculate recurrences and to
export in iCals (NOT yet implemented)
- timezone data is imported from SQLite DB from Thunderbird Lighting 1.0pre
- contains iCal VTIMEZONE component
- also contains not yet used latitude and longitude for timezone
- methods to convert between TZID string, nummeric tz_id and VTIMEZONE
iCal component
--> preparation to store timezone information for each events
(using tz_id as foreing key into egw_cal_timezones table)
- Not rejected
- Accepted
- Invitations
- Tentative
- Rejected
- Owner too: display also events you own, not only ones you participate
- All incl. rejected
- Hide private infos: as usual
--> filter is stored in the user prefs (survives logouts)
--> old "show events you rejected" preference got removed
Also added a hook allowing applications supplying resources to modify
calendar search with SQL.
currently not settable via GUI, but GUI leaves them untouched
- showing quantity for resources in brackets behind resource name
- docu and formatting updates all over the place
doublicates from failed sync
- added cal_recurrences timestamp for exceptions (ts of original
recurrence), for existing exceptions update script uses
the closest recur_exception date/time for it
- using uid of original series for new recurrence exceptions,
update script does NOT update the uid's of existing exceptions
- displaying (maybe temporary) these data in the recurrence tab
