- 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
