icalsrv 0.9.04-bg01 minor bugfix and doc update

This commit is contained in:
Jan v. Lieshout 2006-03-06 14:25:54 +00:00
parent 8cc0f09457
commit e6b0e63066
3 changed files with 91 additions and 135 deletions

View File

@ -4,44 +4,45 @@
* @file
* Icalsrv: Export and Import Egw events and task as ICalendar over http
*
* @desc purp egw remote ical-over-http server interface that can import and export vevents,
* and vtodos. Possible clients include Mozilla Calendar/Sunbird, Korganizer, Apple Ical
* Possible clients include Mozilla Calendar/Sunbird, Korganizer, Apple Ical
* and Evolution.
* @note <b> THIS IS STILL EXPERIMENTAL CODE </b> do not use in production.
* @note this script is supposed to be at: egw-root/icalsrv.php
*
*
* @version 0.9.02
* @date 20060214
* @author Jan van Lieshout <jvl (at) xs4all.nl> Rewrite and extension for egw 1.2.
* (see: http://www.egroupware.org )
* $Id$
* (see: @url http://www.egroupware.org )
*
* Based on some code from:
* @author RalfBecker@outdoor-training.de (some original code base)
* @author bbeckmann (at) optaros.com (some modificationas)
* @author l.tulipan (at) mpwi.at (Additional Modifications for egw 1.2).
*
* @license
* <b>license:</b><br>
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*
* @since 0.9.00 use of the new egwical class for iCalendar handling with WURH
* according to WURH pattern
* TODO list:
* @todo incorporate this icalsrv.php script in
* standard egroupware access url, via a setup routine or so.
* @todo make this 'ical-service' enabled/disabled from the egw
* admin interface
* @todo make some parameters of this 'ical-service' interface user
* specific configurable, for example the vevent and vtodo export
* period (define search filters..) or overwrite or duplicate mode
* etc.
* @todo for ical GET: get the agent name from the http header
* and use to set the ical product field when exporting.
*/
// TODO list:
// - incorporate this icalsrv.php script in standard egroupware access url
// - make this 'ical-service' enabled/disabled from the egw admin interface
// - make some parameters of this 'ical-service' interface user specific configurable
// for example the vevent and vtodo export period (define search filters..)
// overwrite or duplicate mode etc.
// Build a html interface for this. I guess this goes into $GLOBALS....['preferences']...
// CAN SOMEBODY HELP WITH THIS? (not my piece of pudding ....)
#$logdir = false; // set to false for no logging
$logdir = '/tmp'; // set to a valid (writable) directory to get log file generation
$logdir = false; // set to false for no logging
#$logdir = '/tmp'; // set to a valid (writable) directory to get log file generation
# WHY THIS? IS IT NEEDED?
$GLOBALS['phpgw_info'] =
@ -266,12 +267,6 @@ function fail_exit($msg){
$GLOBALS['egw']->common->egw_exit();
}
/* dummy fail_exit */
function fail_exit($msg){
// log the error in the http server error logging files
error_log($msg);
return;
}

View File

@ -1,4 +1,7 @@
/*! \page bugandtodopage BUGS and TODOS
/*! \page pageicalsrvbugandtodo BUGS and TODOS
@note This is an early list of bugs and todos. Probably a little bit
deprecated now. (see new todo page in relatedpages)
<PRE>
Know BUGS and things todo
@ -10,84 +13,30 @@ FAIl means: known failure to provide (not easily to be done/fixed
(note: this list is probably not quite up todate)
release: VERSION 0.7.80 NEED TO UPDATE THIS!!
release: VERSION 0.9.00 NEED TO UPDATE THIS!!
new in V0.7.78 versus v0.7.70:
bovevents:
+ whole day events import/export seems to work nice
+ continue on erroneous overwrites (errors only visible in errorlog)
+ no error messages for forbidden overwrite events of non owned events
+ errormessages (when activated) only shows problematic events
++ basic (multiple) VALARM import and export, working! (without action select)
+ allow for vevents with either DTEND or DURATION
+ provided (horde iCalendar) patch to prevent segfaults on some bad iCal inputs
1) general (V0.7)
1) general (V0.9)
----------------
1.1 TODO build egw install/setup system for icalsrv
1.2 TODO get it nicely into egw cvs
1.3 TODO build user preferences (export/import period setting) gui
[ ]1.7 TODO/WISH allow for import of ATTENDEEs not in Egw yet (create new addressbook entry?)
(ad hoc solution: add CN and mailto to description)
1.4 TODO check and generate source code documentation(phpdoc or doxygen)
[+/-]1.4 TODO check and generate source code documentation(phpdoc or doxygen)
1.5 TODO test these routines in use for syncml import/export
1.6 TODO/WISH: nothing done yet for vfreebusy, vjournal, notes, components
3.6 TODO/WISH: nothing done yet for vfreebusy, vjournal, notes, components
only vevents and vtodos are supported.
2) icalsrv.php (V0.7)
2) icalsrv.php (V0.9)
--------------------
[+]2.1 BUG/CHECK repair/improve the http error return (403) (seems to work)
2.2 TODO integrate with 1.3 TODO
[+]2.3 TODO handle (V)alarms
[ ]2.4 TODO(for v0.7.80 ?) for expor: get the agent name from the http header and use
[ ]2.3 TODO build user preferences (export/import period setting) gui
[ ]2.4 TODO(for v0.9.01 ?) for export: get the agent name from the http header and use
to set the ical product field. Then in egwical use it to set the supportedfields()
3) egwical (V0.7.75)
--------------------
[+?]3.1 TODO check/implement correct timezone handling (seems ok)
3.2 TODO/WISH handle location (GEO), link(?), url, delegation, ()CONTACT?
3.3 TODO set and use the productid in the ical, and use it to
setsupportedFields() (for mozilla, korganizer etc. ... with a default of.. )
4) calendar.bovevents (V0.7.75)
------------------------------
[+?]4.1 TODO check/implement correct timezone handling (related 3.1)
[ ]4.2 FAIL rrule-COUNT import not implemented in egw?
[+]4.2 BUG!!!! rrule-BYDAY import goes wrong. FIXED (v0.7.76)
[+]4.3 TODO check and improve ORGANIZER,ATTENDEE<-> participants mapping
ATTENDEE s import and export (appears to work oke >= V0.7.71)
[+]4.4 TODO handle import and export of ALARMS
[ ]4.7 TODO (ad hoc) add non egw known attendees to description on import
4.9 see 3.2
5) infolog.bovtodos (V0.7.x)
----------------------------
5.1 TODO check/implement correct timezone handling (related 3.1)
5.3 FAIL import/export more than 1 category per task (egw doesnot allow)
5.3 TODO check and improve ORGANIZER,ATTENDEE<-> info_responsible etc mapping
5.4 TODO handle import and export of ALARMS
5.5 TODO rewrite code into supportedFields structure (for next version)
5.9 see 3.2
10.) in used routines from others:
10.1 BUG Horde_iCalendar(1.2rc6): EXDATE bug

View File

@ -1,25 +1,28 @@
/*! @mainpage Ical Service for Egroupware
@NOTE: this text is not up to date
@version 0.9.01
@note this is still <b>EXPERIMENTAL, USE AT YOUR OWN RISK! </b> and better not yet in a
production environment.
@version 0.9.01R1
@author jvl
@date 2006022
@section secinstall SHORT experimental Install How-To:
- Install the icalsrv package by either checking out the icalsrv module from cvs
or untarring some tarball icalsrv-vx.y.x.tgz of the package (when available).
- @note: The IcalSrv package depends on the availability of an
- Install the icalsrv package by either checking out the icalsrv stuff from cvs
or untarring some tarball icalsrv-vx.y.x.tgz of the package (when available).
At the moment (200602xx) the icalsrv is partly in cvs module <i>egroupware</i> and
partly (the documentation only) in module <i>phpgwapi</i>. So be sure to update at least the first one!
- @note The IcalSrv package depends on the availability of an
EgwIcal (>= 0.9.x) package. So if you dont have this already, be sure
to install that too.
to install that too. Likewise this can be installed by untarring an appropiate
egwical-vx.y.z.tgz tarball or by checking out the <i> egwical</i> module from cvs (HEAD).
- Take care that icalsrv.php is .../egroupware/icalsrv.php (and the
other files from the icalsrv package also in their appropiate places)
- Take care that icalsrv.php is <code>.../egroupware/icalsrv.php</code>
(and the other files from the icalsrv package also in their appropiate places)
- Append something like the following onto your apache httpd.conf part for
egroupware (assuming that your standard egroupware root path is e.g in
/var/www/egroupware and with a http alias 'egroupware' pointing to
it):
<code>/var/www/egroupware</code> and with a http alias <code>egroupware</code> pointing to it):
<PRE>
<Location /egroupware/icalsrv.php>
Script PUT /var/www/egroupware/icalsrv.php
@ -44,8 +47,8 @@ it):
@section secdeletions Deleting Calendars, events or todos
deletion of the whole remote calendar is not supported see the @ref
webcaldiscusspage webcal protocol discussion.
deletion of the whole remote calendar is not supported see the webcal protocol discussion in
@ref pagewebcaldiscussion
Individual calendar events or todos cannot be deleted either by just
deleting them on the client and then hoping that this propagates to
@ -53,7 +56,7 @@ Egroupware on publish. There are various reasons for why this is not
implemented.
But, you can though delete items by simply renaming them to
<code>X-DELETE</code>. I you do so they will get deleted in Egw on
<code>X-DELETE</code>. I you do so, they will get deleted in Egw on
publishing. When you later dowload ("reload"/"refresh") the remote
calendar in your client you should notice that the event is gone..
@ -62,12 +65,14 @@ calendar in your client you should notice that the event is gone..
This is tested with egw1.2rc6 and clients:
* Korganizer (3.3.2,(read) 3.4.2, 3.5.0 (READ+WRITE))
* Mozilla calendar (2004040813-cal) (READ+WRITE)
* Evolution 2.2 (READ)
- Korganizer (3.3.2,(read) 3.4.2, 3.5.0 (READ+WRITE))
- Mozilla calendar (2004040813-cal) (READ+WRITE)
- Evolution 2.2 (READ)
- Apple Ical, is reported to be working too. (READ+WRITE)
For further use and experience with these clients see @ref
pageicalsrvclients IcalSrvClients page.
For further use and experience with these clients and supported features see @ref
pageicalsrvclients
<i>Now with screenshots too!</i>
@ -90,53 +95,60 @@ it is very likely that a lot of problems, deficiencies and bugs will
appear.
Thus to get error feedback for it is a healthy thing. You should best
do this --as with any egw application-- using the sourcforge.net
buglist and the dedicated egroupware forums or mailinglist (see the
egroupware wiki for more instructions on this).
do this --as with any egw application-- by following the guidelines
See the egroupware wiki at @url http://www.egroupware.org/bug-reports
for more instructions on this)
This will point you to the sourceforge.net Egroupware buglist at @url
https://sourceforge.net/tracker/?group_id=78745&atid=554338 and the
dedicated egroupware forums or mailinglist at @url
http://www.egroupware.org/forum/?page_name=forum
What to report? Well you should realize that IcalSrv is --currently--
on it self just a rather simple http interface script, that relies for
it connection to the egw backends heavily on the new (re) written
its connection to the egw backends heavily on the new (re) written
EgwIcal package. This means that problems with in and export of
iCalendar data will mostly have their source in that (i.e. EgwIcal)
package! So in case of errors allways report info on that package and
when debugging try the debug tools for that package.
@subsection subsecdebugtools Debugging of IcalSrv.
IcalSrv does not generate webpages, so to see any error or debug
information you there a jsut three other places to look at:
information, there a just three other places to look at:
+ If you have a really problematic error, IcalSrv will answer your http
request with a 403 error and --hopefully-- a short message. In some
clients (like Korganize) this is reported back via a popup with a
silly message that "exporting went wrong or access denied" or so, instead of displaying
this message it got together with the 403 error. Note: Sunbird does
display the message. Unfortunately at the moment this will be mostly
"VEVENTS import ERROR" or so..
+ The httpd errorlog file/stream. Most problematic errors are reported
to this file of the egw server. So this is indeed the best source for
debug info. But to read it, you need access to the
server and to this log file. So only egw administrators are likely
the only ones for who this can be of help.
+ The ical.log files and ical.exportxxxx plus ical.importxxxx
files. If you did install the icalsrv.php file with the variable
$logdir set to folder where the httpd is allowed to write, you will
get a detailed log in file ical.log of all uploads and downloads via
IcalSrv furhtermore for each of these the associated iCalendar data
will be logged in ical.exportXXXXXX files with XXXX the utime of the
action. These files reside on the egw server, mostly in /tmp. So again
to read them you will need access to this server directory.
Off course this feature needs to be disabled in a production setting:
the file growth and the security issues of it demand it.
-# The HTTP error message. <br>
If you have a really problematic error, IcalSrv will answer your http
request with a 403 error and --hopefully-- a short message. In some
clients (like Korganize) this is reported back via a popup with a
silly message that "exporting went wrong or access denied" or so, instead of displaying
this message it got together with the 403 error. Note: Sunbird does
display the message. Unfortunately at the moment this will be mostly
"VEVENTS import ERROR" or so..
-# The httpd errorlog file/stream. <br>
Most problematic errors are reported
to this file of the egw server. So this is indeed the best source for
debug info. But to read it, you need access to the
server and to this log file. So only egw administrators are likely
the only ones for who this can be of help.
-# The ical.log files and ical.exportxxxx plus ical.importxxxx <br>
files.
If you did install the icalsrv.php file with the variable
$logdir set to folder where the httpd is allowed to write, you will
get a detailed log in file ical.log of all uploads and downloads via
IcalSrv furhtermore for each of these the associated iCalendar data
will be logged in ical.exportXXXXXX files with XXXX the utime of the
action. These files reside on the egw server, mostly in /tmp. So again
to read them you will need access to this server directory.
Of course this feature needs to be disabled in a production setting:
the file growth and the security issues of it demand it.
@section secbugandtodo BuG and todo list
-see BUGs and TODOs in @ref pageicalsrvbugandtodopage
-see BUGs and TODOs in @ref pageicalsrvbugandtodo
-see Todo page in ..