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)
- show status of participants in border style of event
+ solid: all participants accepted
+ dotted: all participants answered, but not all accepted
+ dashed: not all participants answered
- mark invitations (of current user, not calendar selected)
+ white background color (not category based color)
+ show blue questionmark icon in event header
(it would be nice, if there's a simple method to find out if two different timezones switch at identical times, eg. Europe/Berlin and Europe/Paris do so, so we can avoid the recalculation)"
- Implemented two new monthly rrules: last day of month and last weekday (eg. workday) of month
- The constructor accepts times only as DateTime (or decendents like egw_date) to work timezone-correct.
- The timezone of the event is determined by timezone of the startime, other times get converted to that timezone.
- There's a static factory method calendar_rrule::event2rrule(array $event,$usertime=true), which converts an event read by calendar_bo::read() or calendar_bo::search() to a rrule iterator.
- The rrule iterator object can be casted to string, to get a human readable describtion of the rrule.
- There's an interactive test-form, if the class get's called directly: http://localhost/egroupware/calendar/inc/class.calendar_rrule.inc.php
--> next step will be to use the rrule iterator in calendar_bo::insert_all_repetions() to calculate the recurences"
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)
installation time --> nice user experience and cleaner look (by hiding
exotic prefs by focing them to a usual value):
- settings returned from settings hook can contain values for keys
'default' or 'forced'
- if settings hook require part of api or application, which are not
available during installation time: use a method hook (instead of
an old $app/inc/hook_settings.inc.php file), and check if
$hook_param['setup'] is true
- default prefs created so far in setup/admin_account.php got removed
- common prefs in preferences_hooks::settings() got reworked to set
default and forced prefs
- calendar prefs in calendar_hooks::settings() got reworked to set
default and forced prefs
--> I will rework prefs of all our (default) applications according to a
best practice list of Stylite consultants
--> recogniced it's so old and dusty, it does not make sense any more
--> moved content_header() method to html class
- fixed calls of browser->content_header to use html::content_header
instead
calendar, plus a first calendar implemenation.
This implementation just replaces following calendar_bo methods:
- date2ts($date,$user2server=False)
- date2array($date,$server2user=False)
- date2string($date,$server2user=False,$format='Ymd')
- format_date($date,$format='')
which static methods from egw_time.
If your server is in same timezone as the user, you should experience no
difference. As a small test, you can switch to an other timezone (eg.
UTC) to recognice on a weekly repeating event (which still repeats on
equal server time!) that it moves by one hour when daylight saving
changes. This switching to a TZ with different daylight saving rules,
was not working before.
Happy testing :-)
- 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.
