From bernhard at intevation.de Wed Apr 1 09:10:44 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 1 Apr 2009 09:10:44 +0200 Subject: [Kolab-devel] infrastructure: tracker cleanup (planned) In-Reply-To: <200903311554.48065.alex@ap-consulting.co.uk> References: <200903311540.02149.bernhard@intevation.de> <200903311634.45304.itsef-admin@brightsight.com> <200903311554.48065.alex@ap-consulting.co.uk> Message-ID: <200904010910.45132.bernhard@intevation.de> Am Dienstag, 31. M?rz 2009 16:54:47 schrieb Alex Potter: > On Tuesday 31 March 2009 15:34:45 ITSEF Admin wrote: > > Hm... What makes a "User" out of a "Provisional user"? I know my account > > changed status from provisional to "full" some time in February, but > > without me ever doing anything for it - nor was I aware that this change > > was possible at all... > > I wondered that too. How would the user know? Some documentation is already in the Wiki: http://wiki.kolab.org/index.php/Kolab_Issue_Tracker | To be able to comment other issues, you need to get your role upgraded | from "Provisonal User" to "User". One common way of doing this is to ask on | one of the mailinglists. Make sure you add your roundup id to the request. | Role "User" is granted to anybody that shows sanity (easy) and wants to | comment several issues. So currently one of the admins (e.g. me) is doing the switch of the user roles manually. Provisional Users can create issues and comment on issues they have created. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090401/c9c2e964/attachment-0001.bin From kolab-issues at intevation.de Wed Apr 1 12:18:22 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 10:18:22 +0000 Subject: [Kolab-devel] [issue3520] calendar with certain entries does not display in web client Message-ID: <1238581102.33.0.865914254257.issue3520@intevation.de> New submission from Thomas Arendsen Hein : Current CVS kolab_2_2_branch, i.e. kolab-webclient-1.2.0-20090327 Kolab_Server-0.4.0-20090224 Kolab_Format-1.0.0-20081212 Kolab_Storage-0.4.0-20090224 A user with fresh webclient settings (i.e. never logged in since settings were switched from LDAP to file) opens the Calendar folder (which contains >400 mails), but the part of the page which should show the calendar stays white. /kolab/var/kolab/www/client/log/php-errors.log contains: [01-Apr-2009 11:53:52] PHP Fatal error: Call to undefined method PEAR_Error::has_child_nodes() in /kolab/var/kolab/www/client/lib/Horde/Kolab/Format/XML.php on line 423 Other users' calendar folders work. ---------- assignedto: wrobel messages: 19379 nosy: martin, thomas, wilde, wrobel priority: urgent status: unread title: calendar with certain entries does not display in web client topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 12:34:47 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 10:34:47 +0000 Subject: [Kolab-devel] [issue3521] kolabmailboxfilter does not accept mail for user+extension@example.com Message-ID: <1238582087.4.0.905754744576.issue3521@intevation.de> New submission from Thomas Arendsen Hein : Kolab_Filter-0.1.4-20090320 (current kolab_2_2_branch) Sending mail to user+extension at example.com does not work. /kolab/var/kolab-filter/log/filter.log contains: Mar 31 19:47:49 Kolab Filter [debug] [horde] User user+extension at example.com does not exist! [on line 209 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"] Mar 31 19:47:49 Kolab Filter [error] [horde] Specify either the UID or a search result!; Code: 323 [on line 179 of "/kolab/lib/php/Horde/Kolab/Server/Object.php"] postfix.log contains: Mar 31 19:47:49 cipactli postfix/pipe[22065]: 12FC83408F44: to=, relay=kolabmailboxfilter, delay=0.46, delays=0.01/0.11/0/0.34, dsn=5.1.1, status=bounced (user unknown) It worked at least in 2.2.0-rc2. The corresponding code line in Incoming.php is: $dn = $server->uidForIdOrMail($recipient); ---------- assignedto: wrobel messages: 19380 nosy: martin, thomas, wilde, wrobel priority: critical status: unread title: kolabmailboxfilter does not accept mail for user+extension at example.com topic: filter, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 12:39:49 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 10:39:49 +0000 Subject: [Kolab-devel] [issue3522] No logrotate for kolab-filter.log and friends Message-ID: <1238582389.14.0.323539016139.issue3522@intevation.de> New submission from Thomas Arendsen Hein : /kolab/var/kolab-filter/log/filter.log grows fast and is not rotated. Logrotate was previously handled by /kolab/etc/rc.d/rc.kolabd, but the autoconf variables were not updated: %config kolabd_enable="$openpkg_rc_def" kolabd_log_resmgr_logfile="@resmgr_logfile@" kolabd_log_resmgr_owner="kolab-n" kolabd_log_resmgr_group="kolab-n" kolabd_log_resmgr_prolog="true" kolabd_log_resmgr_epilog="true" kolabd_log_resmgr_numfiles="10" kolabd_log_resmgr_minsize="1M" kolabd_log_resmgr_complevel="9" kolabd_log_freebusy_logfile="@freebusy_logfile@" kolabd_log_freebusy_owner="kolab-n" kolabd_log_freebusy_group="kolab-n" kolabd_log_freebusy_prolog="true" kolabd_log_freebusy_epilog="true" kolabd_log_freebusy_numfiles="10" kolabd_log_freebusy_minsize="1M" kolabd_log_freebusy_complevel="9" kolabd_log_fbview_logfile="/kolab/var/resmgr/fbview.log" kolabd_log_fbview_owner="kolab-n" kolabd_log_fbview_group="kolab-n" kolabd_log_fbview_prolog="true" kolabd_log_fbview_epilog="true" kolabd_log_fbview_numfiles="10" kolabd_log_fbview_minsize="1M" kolabd_log_fbview_complevel="9" Seeing kolabd_log_freebusy* I suspect that the same problem exists there, too. After kolab-filter.log reaches 2GB, no additional lines are added, but it still works, therefore it only needs to be fixed in HEAD. ---------- assignedto: wrobel messages: 19382 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: No logrotate for kolab-filter.log and friends topic: server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 12:57:40 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Wed, 01 Apr 2009 10:57:40 +0000 Subject: [Kolab-devel] [issue3523] Cannot open a link in a mail Message-ID: <1238583460.23.0.693812630029.issue3523@intevation.de> New submission from Ludwig Reiter : Kontact Installer 20090220 Test: 1. Send a test mail with an URL in its text to a test account. 2. Sync and look at that mail. 3. Double click on the URL and select a browser. Expect the browser to open the url. But the url is not opened, because the url is not exact reported to the browser, and the browser try to open a local file. ---------- assignedto: allen messages: 19383 nosy: allen, bh, ludwig priority: bug status: unread title: Cannot open a link in a mail topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 13:04:37 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Wed, 01 Apr 2009 11:04:37 +0000 Subject: [Kolab-devel] [issue3524] tool selection dialog: Checkbox "open all files with this format with selected program" doesn't have an effect. Message-ID: <1238583876.93.0.987430834976.issue3524@intevation.de> New submission from Ludwig Reiter : Kontact Installer 20090220 Test: 1.Try to open an attachment. => A tool selection dialog pops up. 2. Select a tool and activate the checkbox "open all files with this format with selected program". 3. Press okay. 4. Close the opened attachment. 5. Try to open the attachment once more. => Again the user is asked to select a program. Expect: Because of the selection of a program for all files of this format, he shouldn't be asked to select a program. ---------- assignedto: allen messages: 19384 nosy: allen, bh, ludwig priority: minor bug status: unread title: tool selection dialog: Checkbox "open all files with this format with selected program" doesn't have an effect. topic: enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 14:31:06 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 12:31:06 +0000 Subject: [Kolab-devel] [issue3525] free/busy regeneration aborts in server 2.2.1 without printing folder Message-ID: <1238589066.21.0.239505885648.issue3525@intevation.de> New submission from Thomas Arendsen Hein : When regenerating f/b for all folders as described in 1st.README, the script aborts with exit code 255 and without printing anything. (with a different server the list of folders is printed at the very end, not immediately after generating f/b for one folder) /kolab/var/kolab-freebusy/log/ php-error.log contains: [01-Apr-2009 12:49:24] PHP Warning: DOMDocument::loadXML(): Input is not proper UTF-8, indicate encoding ! Bytes: 0xFC 0x62 0x62 0x65 in Entity, line: 5 in /kolab-2.2/lib/php/Horde/DOM.php on line 126 [01-Apr-2009 12:49:24] PHP Fatal error: Call to a member function hasChildNodes() on a non-object in /kolab-2.2/lib/php/Horde/DOM.php on line 357 0xFC 0x62 0x62 0x65 obviously is latin1 (?bbe) instead of utf8 Looking at the cache directory, only 22 of 50 event folders have entries, so kolab/issue2905 (generatefb.php should skip invalid folders instead of aborting) did not kick in to keep following folders happy. ---------- assignedto: wrobel messages: 19387 nosy: martin, thomas, wilde, wrobel priority: critical status: unread title: free/busy regeneration aborts in server 2.2.1 without printing folder topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From thomas at intevation.de Wed Apr 1 16:28:55 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 1 Apr 2009 16:28:55 +0200 Subject: [Kolab-devel] TODO list for Kolab Server 2.2.1 final In-Reply-To: <20090320171347.GB30222.thomas@intevation.de> References: <20090313121409.GB28681.thomas@intevation.de> <20090320171347.GB30222.thomas@intevation.de> Message-ID: <20090401142855.GB485.thomas@intevation.de> Hi! * Thomas Arendsen Hein [20090320 17:13]: > * Thomas Arendsen Hein [20090313 13:14]: > > - Document a way to work around kolab/issue3138 (problems with > > server upgrade from sarge to etch). Since we have a real fix for kolab/issue3130 (Perl Error on Upgrade) now, the detailed documentation for moving all data from and old installation to a new one is less important now. You can still install e.g. ix68-debian3.1 binaries created in a sarge chroot or on a different machine on an etch or lenny server. So I'll propably drop this TODO for 2.2.1 to have more time for testing. During the final tests some issues showed up, so the remaining TODOs for 2.2.1 in the kolab_2_2_branch are: kolab/issue2535 (group:distributionlist at example.com doesn't work for Cyrus IMAP ACLs) kolab/issue3520 (calendar with certain entries does not display in web client) kolab/issue3521 (kolabmailboxfilter does not accept mail for user+extension at example.com) kolab/issue3525 (free/busy regeneration aborts in server 2.2.1 without printing folder) This means Kolab Server 2.2.1 is very close, but we missed our appointed date of release. I adjusted the roadmap page for this. Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090401/80ec07ad/attachment.bin From kolab-issues at intevation.de Wed Apr 1 16:44:54 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Wed, 01 Apr 2009 14:44:54 +0000 Subject: [Kolab-devel] [issue3526] Folder type not recognised after shared folder was gone for a while. Message-ID: <1238597094.34.0.866773931124.issue3526@intevation.de> New submission from Bernhard Reiter : For a while a few shared folders for calenders were not available from the Server. (It was a test from Kolab Server close to 2.2.1 release, revealing a group ACL problem.) After displaying the users again, now given right by single user not by a group, for some users the type is not recognise, thus the contacts are not displayed in the contacts view. For some other users it worked. e35 20090226 for some that worked and do not work. e25 20090313 for me that did not work. Rebuilding the index, refreshing the cache, restarting Kontact all does not help. You could set the type to contact again which helps. So the detection fails. Ludwig, can you try to reproduce? ---------- assignedto: ludwig messages: 19399 nosy: allen, bernhard, ludwig, thomas, till priority: bug status: need-eg title: Folder type not recognised after shared folder was gone for a while. topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 16:49:16 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 14:49:16 +0000 Subject: [Kolab-devel] [issue3527] no immediately printing of folders during freebusy cache regeneration Message-ID: <1238597356.29.0.670369765404.issue3527@intevation.de> New submission from Thomas Arendsen Hein : Split out from kolab/issue3525 (free/busy regeneration aborts for unparsable events): FreeBusy.php builds an array of lines and prints it at the very end ... This is plainly wrong: not only when trying to find the error, but it also makes it unusable as a progress indicator when uses interactively. Additionally it should unconditionally print the folder name before starting to generate f/b for it, maybe like with some init scripts: 'Regenerating calendar "user/user/Calendar at example.com" ...' (no '\n') and then 'OK\n' when finished or 'FAILED:\n(The reason)\n' otherwise. ---------- assignedto: wrobel messages: 19400 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: no immediately printing of folders during freebusy cache regeneration topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 1 17:05:39 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 01 Apr 2009 15:05:39 +0000 Subject: [Kolab-devel] [issue3528] Events with broken encoding should work Message-ID: <1238598339.77.0.306961751262.issue3528@intevation.de> New submission from Thomas Arendsen Hein : Split out from kolab/issue3520 (calendar with certain entries does not display in web client) and kolab/issue3525 (free/busy regeneration aborts for unparsable events): Events may be stored with other encodings than UTF8, but due to client bugs this is not indicated in the xml encoding value, e.g.: KOrganizer 3.3 (proko2 branch), Kolab resource libkcal-816818875.662 ...?bbe... ^ latin1 Currently the event causes free/busy and webclient calendar to abort. If above issues are fixed it will still cause this event to be skipped. Such events should be displayed with e.g. a question mark instead of the undecodable character and free/busy should be handled correctly. ---------- assignedto: wrobel messages: 19403 nosy: martin, thomas, wilde, wrobel priority: feature status: unread title: Events with broken encoding should work topic: freebusy, server, web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 2 10:20:32 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Thu, 02 Apr 2009 08:20:32 +0000 Subject: [Kolab-devel] [issue3529] timestamps in the debug output of kontact Message-ID: <1238660432.04.0.537295996235.issue3529@intevation.de> New submission from Ludwig Reiter : It would be nice, if a timestamp is in the debug output at the begin and the end of a sync process. So that syncing time can be measured. ---------- assignedto: allen messages: 19420 nosy: allen, bh, ludwig priority: wish status: unread title: timestamps in the debug output of kontact topic: enterprise35, enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From ludwig.reiter at intevation.de Thu Apr 2 14:37:10 2009 From: ludwig.reiter at intevation.de (Ludwig Reiter) Date: Thu, 2 Apr 2009 14:37:10 +0200 Subject: [Kolab-devel] e35 20090313.938853 is unstable again Message-ID: <200904021437.10571.ludwig.reiter@intevation.de> Hi, I moved Kontact enterprise35 20090313.938853 back to "unstable" on apt.intevation.de. I did a lot of testing of dimap sync and think the risk of a regression , because of the flag sync change, is low. The tests also show a small improvement of the sync speed. Regards, Ludwig -- Intevation GmbH, Osnabr?ck Firmensitz: Neuer Graben 17, 49074 Osnabr?ck Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From itsef-admin at brightsight.com Thu Apr 2 15:37:46 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Thu, 2 Apr 2009 15:37:46 +0200 Subject: [Kolab-devel] e35 20090313.938853 is unstable again In-Reply-To: <200904021437.10571.ludwig.reiter@intevation.de> References: <200904021437.10571.ludwig.reiter@intevation.de> Message-ID: <200904021537.47079.itsef-admin@brightsight.com> On Thursday 2 April 2009 14:37:10 Ludwig Reiter wrote: > I moved Kontact enterprise35 20090313.938853 back to "unstable" on > apt.intevation.de. > I did a lot of testing of dimap sync and think the risk of a regression , > because of the flag sync change, is low. The tests also show a small > improvement of the sync speed. Well, it has been in use here for almost a week now (as I saw Bernhard's mail too late...) with 30 users. So far, none of them has been yelling at me yet - or at least not for this reason... :-} Cheerio, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From thomas at intevation.de Thu Apr 2 17:30:37 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 2 Apr 2009 17:30:37 +0200 Subject: [Kolab-devel] TODO list for Kolab Server 2.2.1 final In-Reply-To: <20090401142855.GB485.thomas@intevation.de> References: <20090313121409.GB28681.thomas@intevation.de> <20090320171347.GB30222.thomas@intevation.de> <20090401142855.GB485.thomas@intevation.de> Message-ID: <20090402153037.GB12159.thomas@intevation.de> * Thomas Arendsen Hein [20090401 16:29]: > During the final tests some issues showed up, so the remaining TODOs > for 2.2.1 in the kolab_2_2_branch are: > > kolab/issue2535 (group:distributionlist at example.com doesn't work for Cyrus IMAP ACLs) > kolab/issue3520 (calendar with certain entries does not display in web client) > kolab/issue3521 (kolabmailboxfilter does not accept mail for user+extension at example.com) > kolab/issue3525 (free/busy regeneration aborts in server 2.2.1 without printing folder) > > This means Kolab Server 2.2.1 is very close, but we missed our > appointed date of release. I adjusted the roadmap page for this. Above issues are solved in kolab_2_2_branch now and I already installed the packages on some production servers. Additionally I'm running clamav 0.95 on these servers to see if it works fine under real load. If no further critical problems show up, I'll release them during the next week. Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090402/f215a88e/attachment.bin From bernhard at intevation.de Thu Apr 2 17:44:43 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 2 Apr 2009 17:44:43 +0200 Subject: [Kolab-devel] e35 20090313.938853 is unstable again In-Reply-To: <200904021537.47079.itsef-admin@brightsight.com> References: <200904021437.10571.ludwig.reiter@intevation.de> <200904021537.47079.itsef-admin@brightsight.com> Message-ID: <200904021744.43481.bernhard@intevation.de> Am Donnerstag, 2. April 2009 15:37:46 schrieb ITSEF Admin: > On Thursday 2 April 2009 14:37:10 Ludwig Reiter wrote: > > I moved Kontact enterprise35 20090313.938853 back to "unstable" on > > apt.intevation.de. > > I did a lot of testing of dimap sync and think the risk of a regression , > > because of the flag ?sync change, is low. The tests also show a small > > improvement of the sync speed. > > Well, it has been in use here for almost a week now (as I saw Bernhard's > mail too late...) with 30 users. So far, none of them has been yelling at > me yet - or at least not for this reason... :-} Again, thanks for testing and the feedback, we were pretty sure there is no problem, but we wanted to be even more confident. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090402/1ea4d2ae/attachment.bin From kolab-issues at intevation.de Fri Apr 3 11:45:57 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Fri, 03 Apr 2009 09:45:57 +0000 Subject: [Kolab-devel] [issue3532] Kmail configuration dialog hangs in contact of sieve scripts. Message-ID: <1238751957.42.0.8582254389.issue3532@intevation.de> New submission from Ludwig Reiter : enterprise4 Windows 20090313.938844 Test: 1. Start kontact. 2. Active an vacation script. 3. Close kontact and restart it without logoff. 4. Enter the kwallet password. 5. Choose to edit the vacation script. 6. Deactivate the vacation script and press okay. 7. Open and close the "manage sieve" dialog 8. Try to open the Kmail configuration dialog. =>In this case kontact hangs. DebugView Output: ---------- assignedto: allen files: output-20090403.log messages: 19475 nosy: allen, bh, ludwig priority: urgent status: unread title: Kmail configuration dialog hangs in contact of sieve scripts. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: output-20090403.log Type: application/octet-stream Size: 2855 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090403/293c6d58/output-20090403.exe From kolab-issues at intevation.de Fri Apr 3 16:19:33 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 03 Apr 2009 14:19:33 +0000 Subject: [Kolab-devel] [issue3533] Display xfb information in free/busy when creating invitations Message-ID: <1238768373.62.0.200031204268.issue3533@intevation.de> New submission from Thomas Arendsen Hein : Related to kolab/issue3372 (pxfb-readable-for implementation for xfb permissions (Z61)): kontact should request and display xfb information if available, e.g. as popup. ---------- assignedto: allen messages: 19486 nosy: allen, laurent, ludwig, thomas, till, tmcguire, vkrause priority: feature status: unread title: Display xfb information in free/busy when creating invitations topic: enterprise35, enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 3 17:25:51 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 03 Apr 2009 15:25:51 +0000 Subject: [Kolab-devel] [issue3534] freebusy/regenerate.php as manager keeps manager read acl Message-ID: <1238772351.39.0.537573996924.issue3534@intevation.de> New submission from Thomas Arendsen Hein : Tested with kolab_2_2_branch as of 20090402 (nearly 2.2.1), but only needs to be fixed in HEAD: When starting f/b cache regeneration using freebusy/regenerate.php via command line or via web as manager, all calendar folders will retain an ACL "manager lrs". It should be removed and was removed in earlier versions of the script, e.g. in CVS/utils/admin/generatefb.php ---------- assignedto: wrobel messages: 19490 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: freebusy/regenerate.php as manager keeps manager read acl topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 3 17:30:03 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 03 Apr 2009 15:30:03 +0000 Subject: [Kolab-devel] [issue3535] xfb list contains latin1 instead of utf8 Message-ID: <1238772603.38.0.507969185602.issue3535@intevation.de> New submission from Thomas Arendsen Hein : kolab_2_2_branch as of 20090402 (nearly 2.2.1), HEAD not tested: When retrieving an extended f/b list via web client or via this URL: curl -k -u user at example.com 'https://kolab.example.com/freebusy/user2%40example.com.xfb' At least the X-SUMMARY is latin1 encoded (after decoding base64) instead of utf8. LC_CTYPE of the server is de_DE at euro (i.e. latin1), I haven't verified on a system which natively runs utf8. ---------- assignedto: wrobel messages: 19491 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: xfb list contains latin1 instead of utf8 topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 3 17:39:13 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 03 Apr 2009 15:39:13 +0000 Subject: [Kolab-devel] [issue3536] web client does not completely delete pxfb-readable-for annotation Message-ID: <1238773153.04.0.781504660599.issue3536@intevation.de> New submission from Thomas Arendsen Hein : Tested with kolab_2_2_branch as of 20090402 (nearly 2.2.1), but only needs to be fixed in HEAD: When removing the last acl for pxfb-readable-for via the web client, cyradm info shows "pxfb-readable-for: ". When using "mboxcfg user/user/Calendar at example.com /vendor/kolab/pxfb-readable-for" then the pxfb-readable-for line is not shown with the info command. It seems as if the web client does not delete the annotation completely, but it should. ---------- assignedto: wrobel messages: 19492 nosy: martin, thomas, wilde, wrobel priority: minor bug status: unread title: web client does not completely delete pxfb-readable-for annotation topic: freebusy, web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 3 17:53:42 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 03 Apr 2009 15:53:42 +0000 Subject: [Kolab-devel] [issue3537] Allowing xfb access to groups does not work Message-ID: <1238774022.08.0.326570601501.issue3537@intevation.de> New submission from Thomas Arendsen Hein : Tested with kolab_2_2_branch as of 20090402 (nearly 2.2.1), not tested with HEAD: Allowing xfb access to groups (i.e. distribution lists) does not work. The code in /kolab/lib/php/Horde/Kolab/FreeBusy/Cache.php in function _allowExtended is: /* Check if the calling user has access to the extended information of * the folder we are about to integrate into the free/busy data. */ $groups = $access->user_object->getGroups(); if (is_a($groups, 'PEAR_Error')) { return $groups; } $groups[] = $access->user; foreach ($groups as $id) { if ($xaclcache->has($file, $id)) { return true; } } $groups contains the elements cn=distlist1 at example.com,cn=internal,dc=example,dc=com cn=distlist2 at example.com,cn=internal,dc=example,dc=com user at example.com This is important for 2.2.1 and I guess the fix is easy. ---------- assignedto: wrobel messages: 19493 nosy: martin, thomas, wilde, wrobel priority: critical status: unread title: Allowing xfb access to groups does not work topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Sat Apr 4 18:55:23 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Sat, 04 Apr 2009 16:55:23 +0000 Subject: [Kolab-devel] [issue3538] Cannot log into Horde on 2.2.1rc1 Message-ID: <1238864123.73.0.766941894088.issue3538@intevation.de> New submission from Albrecht Dre? : I installed 2.2.1rc1 on a Ubuntu 8.04 LTS x86_64 box as explained in the instructions and created 2 test users using the admin interface. However, I cannot log in into Horde (using the "old" Horde uri "/horde" which is then re-directed to "/client/imp/login.php") using Firefox. After entering the account information, the Browser starts loading, but the login window appears again. If I enter a wrong password, the system doesn't tell me it was wrong, but silently displays the login window again. I *can* log into fbview using the same user/password, and if I enter a wrong Password here it tells me "Verbindung zum LDAP-Server als cn=Test 1 Benutzer,dc=my-domain,dc=com konnte nicht hergestellt werden!" (slightly confusing, maybe something like "wrong user name or password" would be better?). BTW, even if I log in multiple times, it always says "Letzte Anmeldung: Noch nie" which is obviously wrong. Any idea what went wrong? Maybe a 64-Bit glitch? A package of logs is attached. ---------- files: Kolab-2.2.1.tar.gz messages: 19500 nosy: albrecht.dress priority: bug status: unread title: Cannot log into Horde on 2.2.1rc1 ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Kolab-2.2.1.tar.gz Type: application/x-tar Size: 1889 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090404/d09d70af/Kolab-2.2.1.tar.tar From kolab-issues at intevation.de Mon Apr 6 11:32:06 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 06 Apr 2009 09:32:06 +0000 Subject: [Kolab-devel] [issue3539] folder vanishes Message-ID: <1239010326.69.0.744675754596.issue3539@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090313 Test: 1. Create folder "testA" under the inbox, sync and restart kontact. 2. Create folder "abc" under the inbox. 3. Move folder "abc" under folder "testA" with D'n'D. 4. Copy folder "abc" to the inbox with D'n'D. => Now "abc" under testA is selected. 5. RMB on this folder and choose delete folder. Even as "abc" is selected, the user is asked to delete "testA". If he just clicks on delete, the testA(!) folder vanishes. ---------- assignedto: allen messages: 19502 nosy: allen, bh, ludwig priority: urgent status: unread title: folder vanishes topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 6 12:16:19 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 06 Apr 2009 10:16:19 +0000 Subject: [Kolab-devel] [issue3540] Todo: The buttons Back, Today and Forward seem to be without function. Message-ID: <1239012979.61.0.0466200807611.issue3540@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090313.938844 Test: 1. Switch to Todos component. 2. Create three test todos. 3. Select one. 4. Click on Back, Today and Forward, but nothing happens. What should happen here? ---------- assignedto: allen messages: 19503 nosy: allen, bh, ludwig priority: minor bug status: unread title: Todo: The buttons Back, Today and Forward seem to be without function. topic: enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 6 14:35:05 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 06 Apr 2009 12:35:05 +0000 Subject: [Kolab-devel] [issue3541] Use of "Switch Application Language..." doesn't change the language of the navigation bar Message-ID: <1239021305.79.0.382039427366.issue3541@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090313.938844 Test: 1. Install a German kontact 2. Start kontact. 3. Switch the application language from German to English(US) 4. Close and restart kontact. => The language of the buttons on the left navigation bar are still German. I also expect them to be changed to English. ---------- assignedto: allen messages: 19512 nosy: allen, bh, ludwig priority: bug status: unread title: Use of "Switch Application Language..." doesn't change the language of the navigation bar topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 6 16:39:51 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Mon, 06 Apr 2009 14:39:51 +0000 Subject: [Kolab-devel] [issue3542] confusing usage of 'uid' for DN in php-kolab packages Message-ID: <1239028791.45.0.00207781818359.issue3542@intevation.de> New submission from Thomas Arendsen Hein : In the patch for kolab/issue3537 (Allowing xfb access to groups does not work) I noticed the use of an array $uid_groups to store a list of group DNs. Gunnar said that he used 'uid' to not use LDAP specific terms, but as 'uid' already has a different meaning for us, this is confusing. I vote for changing this to 'dn', because 1. currently we are LDAP specific, so it is not wrong 2. even when using a different backend, the term is unique (distinguishable) enough to not be confused with similar terms 3. the trivial alternatives are problematic, e.g. "identification" (too long), "unique_id" (almost "uid"), "badge" (slightly off the mark), "primary_key" (SQL term, needs additional reference to "table" to be correct, easily confused with "primary email address"), "key" (too generic) Or is there a better alternative? ---------- assignedto: wrobel messages: 19524 nosy: martin, thomas, wilde, wrobel priority: wish status: unread title: confusing usage of 'uid' for DN in php-kolab packages topic: filter, freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 6 17:51:19 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Mon, 06 Apr 2009 15:51:19 +0000 Subject: [Kolab-devel] [issue3543] Display of pure HTML email very clunky, claimed to be no displayable part Message-ID: <1239033079.58.0.889762283971.issue3543@intevation.de> New submission from Bernhard Reiter : Pure HTML emails cannot easily be displayed with the Kolab Webclient coming with Kolab Server/OpenPKG (veryvery close to 2.2.1). Displaying such an email will state: 1 unnamed 0 KB There are no parts that can be displayed inline. Clicking or double clicking on the "0 KB" link will usually download the HTML and start a browser instance. There probably will be an upstream issue for this as well. And the question how is it solved with our webmailers giving the security risks of the email contents. It is kkc to search and link for the upstream issue and to make a suggestion how to solve this. ---------- assignedto: wrobel messages: 19527 nosy: bernhard, thomas, wilde, wrobel priority: bug status: unread title: Display of pure HTML email very clunky, claimed to be no displayable part topic: kkc, web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 6 17:52:01 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Mon, 06 Apr 2009 15:52:01 +0000 Subject: [Kolab-devel] [issue3544] Cached xfb access not up to date for changed distribution lists Message-ID: <1239033121.1.0.224864271107.issue3544@intevation.de> New submission from Thomas Arendsen Hein : When testing kolab/issue3537 (Allowing xfb access to groups does not work) in nearly Kolab Server 2.2.1 I noticed the following: If a calendar folder allows (p)xfb access to a group, this generally works now since the client changing the annotation has to trigger the folder. But when users are added to or removed from the distribution list, the corresponding folders are not triggered. My test: - created user at example.com, first at example.com, second at example.com - created a distribution list dl at example.com and added first at example.com to it - added some events to user at example.com's Calendar folder - enabled xfb access for dl at example.com to the folder Calendar via the web client - curl -k -u first at example.com 'https://kolab.example.com/freebusy/user%40example.com.xfb' (yields f/b list with X-UID, X-SUMMARY and X-LOCATION -> GOOD) - curl -k -u seconds at example.com 'https://kolab.example.com/freebusy/user%40example.com.xfb' (yields simple f/b list -> GOOD) - Now add second at example.com to and remove first at example from dl at example.com - curl -k -u first at example.com 'https://kolab.example.com/freebusy/user%40example.com.xfb' (still yields f/b list with X-UID, X-SUMMARY and X-LOCATION -> BAD) - curl -k -u seconds at example.com 'https://kolab.example.com/freebusy/user%40example.com.xfb' (still yields simple f/b list -> BAD) I do not think that kolabd should trigger all relevant folders when a distribution list changes, but instead the cache format should not cache "first at example.com has access", but instead "dl at example.com has access". ---------- assignedto: wrobel messages: 19528 nosy: martin, thomas, wilde, wrobel priority: urgent status: unread title: Cached xfb access not up to date for changed distribution lists topic: freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 7 12:41:30 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Tue, 07 Apr 2009 10:41:30 +0000 Subject: [Kolab-devel] [issue3545] Event icons not recognizable on certain background colors Message-ID: <1239100890.29.0.148767488963.issue3545@intevation.de> New submission from Thomas Arendsen Hein : Split out from kolab/issue2609 (minor visual problems with birthday events (and maybe others)) which Bernhard renamed to kolab/issue2609 (Event text not using full space): Originally noticed with Kontact Version 1.2.9 (enterprise 20080321.788244), still the same behavior with enterprise35 20090226.932370 Birthday events have a red background color in my (default?) configuration. They are annotated with four icons: calendar, bell, rotating arrows, crossed out pencil The crossed out pencil isn't recognizable, because the red bar has the same color as the background. Bernhard suggested: We could potentially make sure all the icons have a border that will set them apart independently from the background color. ---------- assignedto: allen messages: 19539 nosy: allen, bernhard, laurent, ludwig, thomas, till, tmcguire, vkrause priority: minor bug status: unread title: Event icons not recognizable on certain background colors topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 7 14:27:32 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Tue, 07 Apr 2009 12:27:32 +0000 Subject: [Kolab-devel] [issue3546] Mail: View unread count after folder view: The direct way to deactivate this option doesn't work Message-ID: <1239107252.36.0.455099094997.issue3546@intevation.de> New submission from Ludwig Reiter : enterprise35 20090326.945022 Test: 1. KMail: Activate option View->Unread Count-> View after folder. => This option should be activated. 2. RMB on View and select this option again to deactivate it. => Nothing happens. Expection: The option becomes deactivated. ---------- assignedto: allen messages: 19542 nosy: allen, bh, ludwig priority: minor bug status: unread title: Mail: View unread count after folder view: The direct way to deactivate this option doesn't work topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From thomas at intevation.de Tue Apr 7 18:33:14 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Tue, 7 Apr 2009 18:33:14 +0200 Subject: [Kolab-devel] Kolab Server 2.2.1 Final Release Message-ID: <20090407163314.GA10254.thomas@intevation.de> Hi! I just uploaded the final release of Kolab Server 2.2.1, which contains about 20 enhancements and fixes compared to the previous release candidate. This release contains a new version of the Kolab web client (providing traditional, minimalistic and dynamic interfaces and SyncML support in beta state), restructured packages and many important fixes to the previous stable release. Please make sure to follow the upgrade instructions in 1st.README, because there have been some changes in the LDAP schema. Many thanks to all the people who contributed to this! Documentation and OpenPKG packages are available from http://files.kolab.org/server/release/kolab-server-2.2.1/ as shown on http://kolab.org/download.html and from the mirrors listed on http://kolab.org/mirrors.html http://files.kolab.org/RSYNC.txt explains how to get (or mirror) the files via rsync. All files updated since 2.2.1-rc1 are available in the directory server/development-2.2/20090407-since-20090305/ You can check the integrity of the downloaded files with: $ gpg --keyserver hkp://subkeys.pgp.net --recv-key 5816791A or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc (the same key that I used to sign this email) $ gpg --verify SHA1SUMS.sig $ sha1sum -c SHA1SUMS Binary packages for Debian GNU/Linux (etch/oldstable) on x86 platforms can be found in the ix86-debian4.0 directory next to the sources. For install instructions and more information about this release, look at http://files.kolab.org/server/release/kolab-server-2.2.1/sources/1st.README and http://files.kolab.org/server/release/kolab-server-2.2.1/sources/release-notes.txt Please report any problems you encounter in our issue tracker: https://issues.kolab.org/ Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090407/ac6e088d/attachment.bin From ml at radoeka.nl Tue Apr 7 21:53:09 2009 From: ml at radoeka.nl (Richard Bos) Date: Tue, 7 Apr 2009 21:53:09 +0200 Subject: [Kolab-devel] Kolab Server 2.2.1 Final Release In-Reply-To: <20090407163314.GA10254.thomas@intevation.de> References: <20090407163314.GA10254.thomas@intevation.de> Message-ID: <200904072153.10673.ml@radoeka.nl> Op dinsdag 07 april 2009 18:33:14 schreef Thomas Arendsen Hein: > I just uploaded the final release of Kolab Server 2.2.1, which > contains about 20 enhancements and fixes compared to the previous > release candidate. Congratulations to everybody involved to get this release out the door. Although it seems only a minor release upgrade (2.2.0 -> 2.2.1) lost of things has changed and hence this release has been a major development! Hopefully it brings all the goods that we expect of it! :) -- Richard From alex at ap-consulting.co.uk Wed Apr 8 05:35:00 2009 From: alex at ap-consulting.co.uk (Alex Potter) Date: Wed, 8 Apr 2009 04:35:00 +0100 Subject: [Kolab-devel] Kolab Server 2.2.1 Final Release In-Reply-To: <20090407163314.GA10254.thomas@intevation.de> References: <20090407163314.GA10254.thomas@intevation.de> Message-ID: <200904080435.00696.alex@ap-consulting.co.uk> On Tuesday 07 April 2009 17:33:14 Thomas Arendsen Hein wrote: Thanks very much. You may like to know that the upgrade from 2.2.0/Openpkg to 2.2.1/Openpkg on an Ubunto 8.04.1 server with 2.6.24-23-server #1 SMP Wed Apr 1 22:14:30 UTC 2009 x86_64 GNU/Linux compiled from sources and completed without incident. Regards Alex From alex at ap-consulting.co.uk Wed Apr 8 10:00:49 2009 From: alex at ap-consulting.co.uk (Alex Potter) Date: Wed, 8 Apr 2009 09:00:49 +0100 Subject: [Kolab-devel] kolab/issue3547 (OpenSSL CVE-2009-0590 and CVE-2009-0789: ASN.1 invalid memory access) Editing Message-ID: <200904080900.50139.alex@ap-consulting.co.uk> May I draw your attention to this issue? Regards Alex From thomas at intevation.de Wed Apr 8 12:29:09 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 8 Apr 2009 12:29:09 +0200 Subject: [Kolab-devel] kolab/issue3547 (OpenSSL CVE-2009-0590 and CVE-2009-0789: ASN.1 invalid memory access) Editing In-Reply-To: <200904080900.50139.alex@ap-consulting.co.uk> References: <200904080900.50139.alex@ap-consulting.co.uk> Message-ID: <20090408102909.GA8599.thomas@intevation.de> * Alex Potter [20090408 10:00]: > May I draw your attention to this issue? Yes, answered in the issue. For those curious about why the issue was not automatically announced on this list: Alex did not provide a message text when originally submitting the issue, so roundup did not bother to send a mostly empty mail. Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kolab-issues at intevation.de Wed Apr 8 15:00:25 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Wed, 08 Apr 2009 13:00:25 +0000 Subject: [Kolab-devel] [issue3548] D'n'D a contact with umlauts, doesn't create a wrong "to"-header in a mail. Message-ID: <1239195625.68.0.853999256495.issue3548@intevation.de> New submission from Ludwig Reiter : enterprise35 rev. 20090406.950008 Test: 1. Create a contact with some umlauts in the name. 2. D'n'D this contact on the mail icon in the sidebar. 3. Look mail in the composer. => The umlauts have the wrong encoding in the "To"-field of the mail. ---------- assignedto: allen messages: 19565 nosy: allen, bh, ludwig priority: minor bug status: unread title: D'n'D a contact with umlauts, doesn't create a wrong "to"-header in a mail. topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 8 16:21:20 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Wed, 08 Apr 2009 14:21:20 +0000 Subject: [Kolab-devel] [issue3549] append_dot_mydomain allows circumventing kolabfilter-verify-from-header Message-ID: <1239200480.09.0.0766814587638.issue3549@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.0 and 2.2.1: Sending an email with "From: boss at invalid" will be rewritten by postfix's append_dot_mydomain to "From: boss at invalid.example.com" and then masqueraded to "From: boss at example.com". It will not be marked as UNTRUSTED, because kolab_smtpdpolicy checks are done before rewriting. append_at_myorigin does not seem to be a problem, maybe the policy filter already is aware of this. I see various ways of solving this: 1. "append_dot_mydomain = no" in main.cf.template (instead of the default "yes") 2. "local_header_rewrite_clients = permit_mynetworks" (instead of the default "permit_inet_interfaces") 3. make the policy filter aware of this I think I would prefer 2. Any opinions? ---------- assignedto: thomas messages: 19575 nosy: bernhard, martin, thomas, wilde, wrobel priority: critical status: unread title: append_dot_mydomain allows circumventing kolabfilter-verify-from-header topic: filter, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 9 14:15:06 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Thu, 09 Apr 2009 12:15:06 +0000 Subject: [Kolab-devel] [issue3550] Address Book function broken in fbview Message-ID: <1239279306.46.0.324499460178.issue3550@intevation.de> New submission from Thomas Arendsen Hein : As mentioned by rbos in msg19497 in kolab/issue2317 (Resource overview feature request similar to freebusy): Kolab Server 2.2.1 When clicking on "Address Book" in fbview, the error page "The requested URL /fbview/kronolith/contacts.php was not found on this server." is shown. It should either work or the button should be removed. ---------- assignedto: wrobel messages: 19606 nosy: martin, rbos, thomas, wilde, wrobel priority: bug status: unread title: Address Book function broken in fbview topic: fbview, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 10 10:44:58 2009 From: kolab-issues at intevation.de (BOURIAUD) Date: Fri, 10 Apr 2009 08:44:58 +0000 Subject: [Kolab-devel] [issue3551] various fbview things that don't work as expected Message-ID: <1239353098.06.0.665248644803.issue3551@intevation.de> New submission from BOURIAUD : Hi ! I'm new to kolab and all related stuff, so I test all I can before launching all this to my co-workers. So far, I'm testing fbview and many things don't work as expected. Here is a list of these : - the "Adress book" icon links to a popup that complains that "The requested URL /fbview/kronolith/contacts.php was not found on this server" - The "last seen" displayed on top of the page always says "Never seen" which is false indeed - The "Save attendee list" button always says that "Successfully saved attendee list" but once you log out of fbview all datas are lost. - when you go to calendars and click on the first url in the table displayed, you get a 404 once again ("The requested URL /fbview/kronolith/month.php was not found on this server.") - The second url doesn't do much, in konqueror at least. Here are all things I've found in fbview. Please, read my mail as it is, and don't understand that I'm here to critisize the work that has been done by all the persons behind kolab and the software provided. I only wish that the above will help to have a better product, not less, not more. ---------- assignedto: wrobel messages: 19622 nosy: bouriaud, martin, thomas, wilde, wrobel priority: bug status: unread title: various fbview things that don't work as expected topic: fbview, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From soliva at comcept.ch Mon Apr 13 10:17:58 2009 From: soliva at comcept.ch (ComCept Soliva) Date: Mon, 13 Apr 2009 10:17:58 +0200 Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Installation Successful Notes/Comments/Info/Wiki/Horde Message-ID: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> Hello finally I got Kolab2 V2.2.1 Final up and running. I posted the overall documentation in Wiki: http://wiki.kolab.org/index.php/Solaris with the link: http://www.comcept.ch/kolab2/solaris_10_kolab2_2.2.1_install.txt Regarding the overall installation some notes/info/questions: http://www.mail-archive.com/openpkg-users at openpkg.org/msg03468.html This issue regarding not useable TLS/SSL libraries is based on the check how this is determed. I used newest openssl-0.9.8k-20090326.src.rpm openpkg package as apache-2.2.11-20090201.src.rpm and with the new apache package it works. To cover the compilation from beginning I manipulated 00INDEX.rdf. https://www.intevation.de/roundup/kolab/issue2924 . For this I received a link and a comment "Please try install-kolab.sh from CVS HEAD". http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/install-kolab.s h . I tested and it seems to work without error but this is not included within the final release and because of this I documented in this way that the -maxdepth/-mindepth has to be completly removed from the install-kolab.sh. https://www.intevation.de/roundup/kolab/issue1809 .This issue I'm only able to solve if I include in the .spec file "--enabled-shared=yes" after the compilation fails as to install the package manually. As a pity I was not able to build in this option in 00INDEX.rdf which would be nice. Any hints appriciated how this can be performed. https://www.intevation.de/roundup/kolab/issue3315 . This issue still exists and is still the case for following packages: PEAR-Horde-Channel "install: pear.horde.org.xml was not found anywhere!" PEAR-PHPUnit-Channel "install: pear.phpunit.de.xml was not found anywhere!" Workaround for external authentication has to be still implemented and is based on behaviour of Solairs http://www.postfix.org/SMTPD_POLICY_README.html After Installation "and correct generating the cert" following appears in the apache log: [warn] RSA server certificate CommonName (CN) `kolab2.mydomain.ch' does NOT match server name!? [notice] Digest: generating secret for digest authentication ... [notice] Digest: done [notice] Apache/2.2.11 (OpenPKG/CURRENT) mod_ssl/2.2.11 OpenSSL/0.9.8k PHP/5.2.8 configured -- resuming normal operations This is based how you configure httpd.conf.template. Solaris 10 does not like within a Zone that to localhost is pointed and it seems that in this way the host name can not be anymore correct defined. I changed to IP and the warning dissapeared: Listen xxx.xxx.xxx.xxx:80 Listen xxx.xxx.xxx.xxx:443 Finally I tested everything and also looked through the logs. From functions point of view all is working now issues found but there are some questions from my site which would be intressting to be verified or commented on your site: Even all works I have in the logs for impad following: ==> /kolab/var/imapd/log/cyr_db.log <== Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: done checkpointing cyrus databases I do not know where this log entries are coming from....I checked the log permisssion and if I set to 777 (which is of course not visible) the error does not disappear. The warning regarding DB4 I was also not able to identify...can you give me some hints specially regarding DB4 which seems to be configured with a local path instead of absolut one?! Regarding Horde following questions/notes I configured /kolab/etc/kolab/templates/slapd.conf.template in and activated: include /kolab/etc/openldap/schema/horde.schema as defined in /kolab/var/kolab/www/horde/config/conf.php "$conf['auth']['admins'] = array('user at mydomain.ch');" . In this way I'm able to manipulate Horde from this defined user but this seems not be the right way? What are here the rules specially because I saw that in the template dir a lot of horde stuff appears. I saw that under the global config of Horde the Tab Kolab appears but the fields are used with example stuff. I changed and after applying the Konfig everything failed and I had to roll-back. At the moment I do not understand the system here used meaning is it visible to manipulate horde over web? Even horde seems to work for a normal user I have a lot of funny stuff within the log like: Apr 13 09:54:32 HORDE [debug] [horde] IMAP errors: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN SECURITY PROBLEM: insecure server advertised AUTH=PLAIN [pid 17129 on line 175 of "/opt/kolab/var/kolab/www/client/imp/lib/IMAP.php"] [13-Apr-2009 09:58:34] PHP Notice: Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN (errflg=1) in Unknown on line 0 Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_remote_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_external_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [nag] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [nag] Hook _prefs_change_hook_display_tasklists in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [mnemo] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [mnemo] Hook _prefs_change_hook_display_notepads in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:32 HORDE [debug] [horde] Max memory usage: 14942208 bytes [pid 17129 on line 339 of "/opt/kolab/var/kolab/www/client/lib/Horde/Registry.php"] What I have also to say is that Horde is very slow...any ideas to speed up. My server has 4 CPUS and 4 GB Memory as is using the fast ZFS Filesystem!? Also that Horde cache's within tmp is not a good idea meaning if I understood all correct this cache files will nobody clean up correct? I hope this gives you a overview and would be nice to have some feedback regarding the comments/notes/info etc. Mit freundlichen Gr?ssen Andrea Soliva Mail: soliva at comcept.ch From kolab-issues at intevation.de Mon Apr 13 10:18:01 2009 From: kolab-issues at intevation.de (Andrea) Date: Mon, 13 Apr 2009 08:18:01 +0000 Subject: [Kolab-devel] [issue3552] Solaris 10 Sparc Kolab V2.2.1 Installation Successful Notes/Comments/Info/Wiki/Horde Message-ID: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> New submission from Andrea : Hello finally I got Kolab2 V2.2.1 Final up and running. I posted the overall documentation in Wiki: http://wiki.kolab.org/index.php/Solaris with the link: http://www.comcept.ch/kolab2/solaris_10_kolab2_2.2.1_install.txt Regarding the overall installation some notes/info/questions: http://www.mail-archive.com/openpkg-users at openpkg.org/msg03468.html This issue regarding not useable TLS/SSL libraries is based on the check how this is determed. I used newest openssl-0.9.8k-20090326.src.rpm openpkg package as apache-2.2.11-20090201.src.rpm and with the new apache package it works. To cover the compilation from beginning I manipulated 00INDEX.rdf. https://www.intevation.de/roundup/kolab/issue2924 . For this I received a link and a comment "Please try install-kolab.sh from CVS HEAD". http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/install-kolab.s h . I tested and it seems to work without error but this is not included within the final release and because of this I documented in this way that the -maxdepth/-mindepth has to be completly removed from the install-kolab.sh. https://www.intevation.de/roundup/kolab/issue1809 .This issue I'm only able to solve if I include in the .spec file "--enabled-shared=yes" after the compilation fails as to install the package manually. As a pity I was not able to build in this option in 00INDEX.rdf which would be nice. Any hints appriciated how this can be performed. https://www.intevation.de/roundup/kolab/issue3315 . This issue still exists and is still the case for following packages: PEAR-Horde-Channel "install: pear.horde.org.xml was not found anywhere!" PEAR-PHPUnit-Channel "install: pear.phpunit.de.xml was not found anywhere!" Workaround for external authentication has to be still implemented and is based on behaviour of Solairs http://www.postfix.org/SMTPD_POLICY_README.html After Installation "and correct generating the cert" following appears in the apache log: [warn] RSA server certificate CommonName (CN) `kolab2.mydomain.ch' does NOT match server name!? [notice] Digest: generating secret for digest authentication ... [notice] Digest: done [notice] Apache/2.2.11 (OpenPKG/CURRENT) mod_ssl/2.2.11 OpenSSL/0.9.8k PHP/5.2.8 configured -- resuming normal operations This is based how you configure httpd.conf.template. Solaris 10 does not like within a Zone that to localhost is pointed and it seems that in this way the host name can not be anymore correct defined. I changed to IP and the warning dissapeared: Listen xxx.xxx.xxx.xxx:80 Listen xxx.xxx.xxx.xxx:443 Finally I tested everything and also looked through the logs. From functions point of view all is working now issues found but there are some questions from my site which would be intressting to be verified or commented on your site: Even all works I have in the logs for impad following: ==> /kolab/var/imapd/log/cyr_db.log <== Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no absolute path for the current directory: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing log files: Permission denied Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive /kolab/var/imapd/db: cyrusdb error Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: done checkpointing cyrus databases I do not know where this log entries are coming from....I checked the log permisssion and if I set to 777 (which is of course not visible) the error does not disappear. The warning regarding DB4 I was also not able to identify...can you give me some hints specially regarding DB4 which seems to be configured with a local path instead of absolut one?! Regarding Horde following questions/notes I configured /kolab/etc/kolab/templates/slapd.conf.template in and activated: include /kolab/etc/openldap/schema/horde.schema as defined in /kolab/var/kolab/www/horde/config/conf.php "$conf['auth']['admins'] = array('user at mydomain.ch');" . In this way I'm able to manipulate Horde from this defined user but this seems not be the right way? What are here the rules specially because I saw that in the template dir a lot of horde stuff appears. I saw that under the global config of Horde the Tab Kolab appears but the fields are used with example stuff. I changed and after applying the Konfig everything failed and I had to roll-back. At the moment I do not understand the system here used meaning is it visible to manipulate horde over web? Even horde seems to work for a normal user I have a lot of funny stuff within the log like: Apr 13 09:54:32 HORDE [debug] [horde] IMAP errors: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN SECURITY PROBLEM: insecure server advertised AUTH=PLAIN [pid 17129 on line 175 of "/opt/kolab/var/kolab/www/client/imp/lib/IMAP.php"] [13-Apr-2009 09:58:34] PHP Notice: Unknown: SECURITY PROBLEM: insecure server advertised AUTH=PLAIN (errflg=1) in Unknown on line 0 Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_remote_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_external_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _prefs_change_hook_display_cals in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [nag] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [nag] Hook _prefs_change_hook_display_tasklists in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [mnemo] Hook _horde_hook_share_init in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:31 HORDE [debug] [mnemo] Hook _prefs_change_hook_display_notepads in application horde not called. [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] Apr 13 09:54:32 HORDE [debug] [horde] Max memory usage: 14942208 bytes [pid 17129 on line 339 of "/opt/kolab/var/kolab/www/client/lib/Horde/Registry.php"] What I have also to say is that Horde is very slow...any ideas to speed up. My server has 4 CPUS and 4 GB Memory as is using the fast ZFS Filesystem!? Also that Horde cache's within tmp is not a good idea meaning if I understood all correct this cache files will nobody clean up correct? I hope this gives you a overview and would be nice to have some feedback regarding the comments/notes/info etc. Mit freundlichen Gr?ssen Andrea Soliva Mail: soliva at comcept.ch ---------- messages: 19632 nosy: kolab-devel1, soliva, wilde, wrobel status: unread title: Solaris 10 Sparc Kolab V2.2.1 Installation Successful Notes/Comments/Info/Wiki/Horde ___________________________________________________ Kolab issue tracker ___________________________________________________ From bernhard at intevation.de Tue Apr 14 11:09:27 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 14 Apr 2009 11:09:27 +0200 Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Installation Successful Notes/Comments/Info/Wiki/Horde In-Reply-To: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> References: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> Message-ID: <200904141109.34394.bernhard@intevation.de> Am Montag, 13. April 2009 10:17:58 schrieb ComCept Soliva: > finally I got Kolab2 V2.2.1 Final up and running. I posted the overall > documentation in Wiki: Andrea, congratulations and thanks for giving detailed feedback! > http://wiki.kolab.org/index.php/Solaris with the link: > http://www.comcept.ch/kolab2/solaris_10_kolab2_2.2.1_install.txt > ==> /kolab/var/imapd/log/cyr_db.log <== > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no > absolute path for the current directory: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing > log files: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive > /kolab/var/imapd/db: cyrusdb error > I do not know where this log entries are coming from....I checked the log > permisssion and if I set to 777 (which is of course not visible) the error > does not disappear. Run of ctl_cyrusdb are configured in kolab/etc/imapd/cyrus.conf maybe they produce the messages. "kolab-r" "kolab" should be the right users. > The warning regarding DB4 I was also not able to > identify...can you give me some hints specially regarding DB4 which seems > to be configured with a local path instead of absolut one?! I'd try the commands above manually with the right users. -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090414/bdf6621a/attachment.bin From kolab-issues at intevation.de Tue Apr 14 15:53:19 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Tue, 14 Apr 2009 13:53:19 +0000 Subject: [Kolab-devel] [issue3553] Offline warning comes up twice Message-ID: <1239717199.36.0.148684235034.issue3553@intevation.de> New submission from Bernhard Reiter : A small defect, which is a regression from proko2: If someone goes offline while "check mail on startup" is enabled, there are two warnings (questions) that Kontact is in offline mode now and if I want to continue in offline mode. reproduced with Kontact Version 1.2.9 (enterprise35 20090326.945022). Can we fix this easily? (Without breaking other stuff like the sieve check on startup an all this?) ---------- assignedto: allen messages: 19651 nosy: allen, bernhard, ludwig, till priority: minor bug status: unread title: Offline warning comes up twice topic: kde client, prokde35 ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 15 11:13:06 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Wed, 15 Apr 2009 09:13:06 +0000 Subject: [Kolab-devel] [issue3554] Mail: Shortcut "Ctrl+z" results in a crash Message-ID: <1239786785.92.0.462664801071.issue3554@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090313 A user reported that using the shortcut ctrl+z to undo after deletion of a mail results in a crash. I cannot reproduce the problem so far. So need example. Output: output-20090415.txt ---------- assignedto: allen files: output-20090415.txt messages: 19666 nosy: allen, bh, ludwig priority: bug status: need-eg title: Mail: Shortcut "Ctrl+z" results in a crash topic: enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output-20090415.txt Url: http://kolab.org/pipermail/kolab-devel/attachments/20090415/7f30674d/output-20090415.txt From kolab-issues at intevation.de Wed Apr 15 14:12:39 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Wed, 15 Apr 2009 12:12:39 +0000 Subject: [Kolab-devel] [issue3555] [2.2.1] unable to save filter settings more than once Message-ID: <1239797559.11.0.838087610494.issue3555@intevation.de> New submission from Albrecht Dre? : On Kolab 2.2.1, self-compiled on Ubuntu 8.04.2/i386, I cannot save the filter settings in the web client more than once. Reproducible as follows, with user "test1": 1. run "rm /kolab/var/kolab/www/client/storage/test1 at my-domain.com.prefs" 2. Log into horde with the traditional UI as user "test1". Horde says "Last login: Never". 3. Select "Spam filter" on the log-on page, set the level to 4 and select a folder. Then click "Save and enable". The filter script looks fine, both in Horde and in sieveshell. 4. Log off, and log on again with the same account. Again, select "Spam filter", and now change the spam level to, say, 1 and click Save. Again, the script looks fine in Horde and in sieveshell. 5. Log off, and log on again with the same account, select "Spam filter". The spam filter settings are back to those from step 3. If I click the "Script" button *without saving the filter before*, Horde shows a script reflecting the settings from step 3, but sieveshell still reports those from step 4. The same seems to happen with *all* filters, e.g. instead of the spam filter, I tried to set different recipients for forwarding. The first time, Horde saves the value, any subsequent fails. ---------- messages: 19669 nosy: albrecht.dress priority: bug status: unread title: [2.2.1] unable to save filter settings more than once topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From alar.sing at err.ee Wed Apr 15 16:45:58 2009 From: alar.sing at err.ee (Alar Sing) Date: Wed, 15 Apr 2009 17:45:58 +0300 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) Message-ID: <49E5F326.6090405@err.ee> Hello, I'm trying to get kolab nativly installed on openSuSE but I ran to troble with freebusy. The Problem is that no data is provided when freebusy config parameter $conf['fb']['use_acls'] is set to true. With freebusy test script log freebusy log shows Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Starting generation of free/busy data for user alar at sise.etv.ee [on line 190 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Free/busy data of owner alar at sise.etv.ee on server https://linux.sise.etv.ee/freebusy requested by user alar at sise.etv.ee. [on line 203 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Starting generation of free/busy data for user alar at sise.etv.ee [on line 190 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Free/busy data of owner alar at sise.etv.ee on server https://linux.sise.etv.ee/freebusy requested by user alar at sise.etv.ee. [on line 203 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Starting generation of partial free/busy data for folder alar at sise.etv.ee/Calendar [on line 96 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Partial free/busy data of owner alar at sise.etv.ee on server https://linux.sise.etv.ee/freebusy requested by user alar at sise.etv.ee. [on line 110 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Creating free/busy information from 1239742800 to 1244926800 [on line 329 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy/Imap.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Starting generation of partial free/busy data for folder alar at sise.etv.ee/Calendar [on line 96 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Partial free/busy data of owner alar at sise.etv.ee on server https://linux.sise.etv.ee/freebusy requested by user alar at sise.etv.ee. [on line 110 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Starting generation of partial free/busy data for folder alar at sise.etv.ee/Calendar [on line 96 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] Apr 15 17:43:35 Kolab Free/Busy [debug] [horde] Partial free/busy data of owner alar at sise.etv.ee on server https://linux.sise.etv.ee/freebusy requested by user alar at sise.etv.ee. [on line 110 of "/usr/share/php5/PEAR/Horde/Kolab/FreeBusy.php"] And php-error.log show's nothing When I change parameter $conf['fb']['use_acls'] to false then I userA can see his own freebusy information, but not userB's freebusy information From martin.konold at erfrakon.de Wed Apr 15 18:58:28 2009 From: martin.konold at erfrakon.de (Martin Konold) Date: Wed, 15 Apr 2009 18:58:28 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <49E5F326.6090405@err.ee> References: <49E5F326.6090405@err.ee> Message-ID: <200904151858.29283.martin.konold@erfrakon.de> Am Mittwoch, 15. April 2009 16:45:58 schrieb Alar Sing: Hi, > When I change parameter $conf['fb']['use_acls'] to false then I userA > can see his own freebusy information, but not userB's freebusy information Are you sure that you installed kolab and not a normal cyrus imapd? Yours, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From alar.sing at err.ee Wed Apr 15 19:12:12 2009 From: alar.sing at err.ee (Alar Sing) Date: Wed, 15 Apr 2009 20:12:12 +0300 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <200904151858.29283.martin.konold@erfrakon.de> References: <49E5F326.6090405@err.ee> <200904151858.29283.martin.konold@erfrakon.de> Message-ID: <49E6156C.9090903@err.ee> Martin Konold wrote: > Am Mittwoch, 15. April 2009 16:45:58 schrieb Alar Sing: > > Hi, > > >> When I change parameter $conf['fb']['use_acls'] to false then I userA >> can see his own freebusy information, but not userB's freebusy information >> > > Are you sure that you installed kolab and not a normal cyrus imapd? > > Yours, > -- martin > > I think I installed kolab cyrus imapd rpm -qa | grep cyrus gives cyrus-sasl-saslauthd-2.1.22-182.1 cyrus-sasl-digestmd5-2.1.22-182.1 cyrus-sasl-devel-2.1.22-182.1 cyrus-sasl-crammd5-2.1.22-182.1 cyrus-sasl-2.1.22-182.1 cyrus-sasl-plain-2.1.22-182.1 cyrus-imapd-kolab-2.3.13-63.1 <-- this looks like kolab package cyrus-sasl-gssapi-2.1.22-182.1 And when I looked with cyradm info about users Calendar folder {user/alar/Calendar at sise.etv.ee}: condstore: false duplicatedeliver: false lastpop: lastupdate: 14-Apr-2009 19:58:42 +0300 partition: default sharedseen: false size: 1617 folder-type: event.default <-this should be only possible with kolab package From kolab-issues at intevation.de Wed Apr 15 23:54:59 2009 From: kolab-issues at intevation.de (Michael Imhof) Date: Wed, 15 Apr 2009 21:54:59 +0000 Subject: [Kolab-devel] [issue3556] Horde login won't work Message-ID: <1239832499.68.0.562856750113.issue3556@intevation.de> New submission from Michael Imhof : I've updated to Kolab 2.2.1. The Hostname differ from Name witch i would use for the webaccess: Hostname foo.example.com URL mail.example.com So i can't login when i use https://mail.example.com/client but it work when i use https://foo.example.com/client. The Problem is, that the SSL certifacte belongs to mail.example.com. ---------- messages: 19673 nosy: ghoja priority: bug status: unread title: Horde login won't work ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 16 11:33:41 2009 From: kolab-issues at intevation.de (Sascha Wilde) Date: Thu, 16 Apr 2009 09:33:41 +0000 Subject: [Kolab-devel] [issue3557] Configurable extra columns in mailbox view Message-ID: <1239874420.97.0.875565828575.issue3557@intevation.de> New submission from Sascha Wilde : It would be good to have configurable extra columns in the mailbox view (the window where all mails of an specific mailbox are listed) for additional header information. Currently Date:, From: (To: if the Sender is the current account) and Subject: are shown. There should be a way to have To: shown, too -- this is useful if a user gets mails via various addresses and wants the information at hand where the mail in question was send. Even better would be a possibility to configure arbitrary additional headers to show, like it is already possible for the message view. ---------- assignedto: wrobel messages: 19676 nosy: martin, thomas, wilde, wrobel priority: feature status: unread title: Configurable extra columns in mailbox view topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 16 12:19:44 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 10:19:44 +0000 Subject: [Kolab-devel] [issue3558] whole-day events broken for resources Message-ID: <1239877184.35.0.303856443395.issue3558@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.1, needs to be fixed in kolab_2_2_branch: Inviting a resource for a whole-day event yields the resource accepting the invitation, but the event stored in its calendar contains an empty /kolab/var/kolab-filter/log/fatal.log contains: [16-Apr-2009 12:11:50] PHP Notice: Undefined index: hour in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Notice: Undefined index: minute in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Notice: Undefined index: second in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Notice: Undefined index: hour in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Notice: Undefined index: minute in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Notice: Undefined index: second in /kolab/lib/php/Horde/Kolab/Resource.php on line 1075 [16-Apr-2009 12:11:50] PHP Warning: gmstrftime() expects parameter 2 to be long, array given in /kolab/lib/php/Horde/Kolab/Format/Date.php on line 111 [16-Apr-2009 12:11:50] PHP Warning: gmstrftime() expects parameter 2 to be long, array given in /kolab/lib/php/Horde/Kolab/Format/Date.php on line 111 [16-Apr-2009 12:11:50] PHP Warning: gmstrftime() expects parameter 2 to be long, array given in /kolab/lib/php/Horde/Kolab/Format/Date.php on line 111 ---------- assignedto: wrobel messages: 19678 nosy: martin, thomas, wilde, wrobel priority: critical status: unread title: whole-day events broken for resources topic: filter, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 16 12:28:16 2009 From: kolab-issues at intevation.de (Sascha Wilde) Date: Thu, 16 Apr 2009 10:28:16 +0000 Subject: [Kolab-devel] [issue3559] HTML signatures for the webclient Message-ID: <1239877695.85.0.557681737145.issue3559@intevation.de> New submission from Sascha Wilde : It should be possible to create or at least use HTML signatures in HTML mails. This is needed for companies which wand to put elements from their corporate design in there. Especially requested are: hyper links, css formatting and at least one embed-able picture for an company logo. For creation of the HTML signature input or upload of HTML-Code would be sufficient (this would need some way to reference the embedded logo, though), maybe better would be the use of the HTML-editor as used during mail creation. Another interesting idea might be to have some kind of html-tmplate with variables for the data from the user vcard (like Name, email, pone etc). In any case the signature should be shown and editable in the HTML editor when writing an mail. ---------- assignedto: wrobel messages: 19680 nosy: martin, thomas, wilde, wrobel priority: feature status: unread title: HTML signatures for the webclient topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 16 12:49:07 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 10:49:07 +0000 Subject: [Kolab-devel] [issue3560] php error when inviting outside of free/busy interval Message-ID: <1239878946.83.0.724270449717.issue3560@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.1 (Kolab_Filter-0.1.4-20090401), but probably CVS HEAD, too: When inviting a resource more than 60 days (or whatever value was set for kolabFreeBusyFuture) in the future, it accepts tentatively. During this an error is logged: Apr 16 12:32:10 Kolab Filter [error] [horde] PHP Error: Undefined variable: conflict; Code: 0 [on line 543 of "/kolab/lib/php/Horde/Kolab/Resource.php"] The current (simplified) code is: if ($vfbstart && $dtstart > $this->convert2epoch ($vfbend)) { $outofperiod=1; } else { $conflict = ...; } if ($conflict) { ...manual or reject... } It should be: if ($vfbstart && $dtstart > $this->convert2epoch ($vfbend)) { $outofperiod=1; } else { $conflict = ...; if ($conflict) { ...manual or reject... } } This clutters the log, but otherwise poses no problem, so only needs to be fixed for CVS HEAD. ---------- assignedto: wrobel messages: 19681 nosy: martin, thomas, wilde, wrobel priority: minor bug status: unread title: php error when inviting outside of free/busy interval topic: filter, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From wrobel at pardus.de Thu Apr 16 14:15:50 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 16 Apr 2009 14:15:50 +0200 Subject: [Kolab-devel] LDAP attribute kolabHomeServerOnly Message-ID: <20090416141550.18581kjws91wghog@webmail.pardus.de> Hi Thomas! Guess I'm somewhat slow in reviewing code these times as these are changes from February: http://kolab.org/pipermail/kolab-commits/2009q1/009163.html http://kolab.org/pipermail/kolab-commits/2009q1/009165.html Can you explain in more detail why this LDAP schema change was necessary and what the functionality is about? My gut feeling would be that a new LDAP attribute might be too much and I feel we already packed too many such attributes in our schema. So I felt the need to understand this change. I probably overlooked the references where this was explained in more detail so a hint would be great. Thanks! Gunnar -- ____ http://www.pardus.de[1] _________________ http://gunnarwrobel.de[2] _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- Links: ------ [1] http://www.pardus.de [2] http://gunnarwrobel.de ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090416/b04f6755/attachment.bin From thomas at intevation.de Thu Apr 16 14:47:25 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 14:47:25 +0200 Subject: [Kolab-devel] LDAP attribute kolabHomeServerOnly In-Reply-To: <20090416141550.18581kjws91wghog@webmail.pardus.de> References: <20090416141550.18581kjws91wghog@webmail.pardus.de> Message-ID: <20090416124724.GA9750.thomas@intevation.de> * Gunnar Wrobel [20090416 14:16]: > Guess I'm somewhat slow in reviewing code these times as these are changes from February: > > http://kolab.org/pipermail/kolab-commits/2009q1/009163.html > http://kolab.org/pipermail/kolab-commits/2009q1/009165.html > > Can you explain in more detail why this LDAP schema change was necessary and what the functionality > is about? My gut feeling would be that a new LDAP attribute might be too much and I feel we already > packed too many such attributes in our schema. So I felt the need to understand this change. Regarding the functionality: Not all IMAP clients need the dummy inbox on the other servers and you only need it anyway if users on one Kolab server need to access shared/published folders on a different Kolab server in a master/slave setup. The functionality was requested by a client who does not want to clutter the IMAP spool directories with directories which are not used in his setup. Regarding the LDAP change: It is only a schema extension, so it will not affect existing installations. The reason for adding it to LDAP is to have identical behavior on all servers. The reason for adding it as a user attribute instead of a global attribute is that you still might want to have certain users with mailboxes on all servers, because you know they have IMAP clients needing the additional inboxes. Like some other LDAP attributes it is not wired to the web admin interface, so that does not even get cluttered with bells&whistles that most people do not need. > I probably overlooked the references where this was explained in more detail so a hint would be > great. Thanks! There was no public discussion about this. Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090416/2a73a1a7/attachment.bin From kolab-issues at intevation.de Thu Apr 16 17:27:39 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 15:27:39 +0000 Subject: [Kolab-devel] [issue3561] global kolabFreeBusyFuture setting should be configurable via web admin Message-ID: <1239895659.46.0.0103094484169.issue3561@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.1: Currently kolabFreeBusyFuture can only be configured per user when only using the web admin interface, but the kolab configuration object allows this value, too. I haven't tested it, but it should override the current default of 60 days, if kolabFreeBusyFuture isn't set for the user. If it works, it should be available next to kolabFreeBusyPast via the web admin interface. ---------- assignedto: thomas messages: 19686 nosy: martin, thomas, wilde, wrobel priority: feature status: unread title: global kolabFreeBusyFuture setting should be configurable via web admin topic: freebusy, server, web admin ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 16 18:02:28 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Thu, 16 Apr 2009 16:02:28 +0000 Subject: [Kolab-devel] [issue3562] tentative answer when inviting outside of free/busy interval is confusing Message-ID: <1239897748.19.0.857875349088.issue3562@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.1 and before: As a solution (workaround?) for kolab/issue1171 (Auto resource handling conflict in the future) the Kolab filter code was changed to tentatively accept the invitation. For people knowing what that means this might be ok, but for most users this is just confusing: 1. Two people can book the same resource at the same time, if they do it early enough. 2. The reason for the tentative acceptance isn't stated in the reply. For REJECT_IF_CONFLICTS I'd rather send a reject with a comment why it was rejected (try later), for MANUAL_IF_CONFLICTS manual might be the better choice, too. Alternatively the code could trigger free/busy generation for the corresponding date interval as the calendar user should already have write permission for the corresponding Calendar folder. The risk of introducing a DoS by triggering large f/b calculations should be considered for this, though. Bernhard, what do you think? ---------- assignedto: bernhard messages: 19688 nosy: bernhard, martin, thomas, wilde, wrobel priority: bug status: unread title: tentative answer when inviting outside of free/busy interval is confusing topic: filter, freebusy, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 17 05:24:57 2009 From: kolab-issues at intevation.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 03:24:57 +0000 Subject: [Kolab-devel] [issue3563] Make kronolith email reminders/alarms work Message-ID: <1239938697.06.0.297862390377.issue3563@intevation.de> New submission from Gunnar Wrobel

: As noted here: http://kolab.org/pipermail/kolab-users/2009-April/009685.html e-mail notifications and/or alarms are not working properly in kronolith. ---------- assignedto: wrobel messages: 19690 nosy: bernhard, martin, thomas, wilde, wrobel priority: feature status: chatting title: Make kronolith email reminders/alarms work topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 17 06:09:15 2009 From: kolab-issues at intevation.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 04:09:15 +0000 Subject: [Kolab-devel] [issue3564] Enable the Horde admin section so that it works or disable it completely Message-ID: <1239941355.67.0.987826929483.issue3564@intevation.de> New submission from Gunnar Wrobel

: Correct. It is not possible to use the Horde configuration system via the web with the kolab-webadmin. I'm still in favor of simply removing the complete admin section of the horde installation for Kolab. Currently we just disabled it by setting "$conf['auth']['admins'] = array();" so that there are no admin users. But of course it is easy for people to find out how to add admins there, not knowing that they might kill their Horde installation this way. The problem is that the Horde configuration is a rather complex topic as you have many options. Some of these options are simply required for Kolab to work and should not be changed. Hm, though actually it might not be hard to change that. We could just remove the critical config variables, write them via templates and offer the web admin for all the rest. ---------- assignedto: wrobel messages: 19691 nosy: bernhard, martin, thomas, wilde, wrobel priority: bug status: chatting title: Enable the Horde admin section so that it works or disable it completely topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From wrobel at pardus.de Fri Apr 17 06:11:19 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 06:11:19 +0200 Subject: [Kolab-devel] Solaris 10 Sparc Kolab V2.2.1 Installation Successful Notes/Comments/Info/Wiki/Horde In-Reply-To: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> References: <8E7C5C6E97AE4B31AEBFAF550D53D24F@comcept.ch> Message-ID: <20090417061119.14662re8bkur6hkw@webmail.pardus.de> Quoting ComCept Soliva : > Hello > > finally I got Kolab2 V2.2.1 Final up and running. I posted the overall > documentation in Wiki: > > http://wiki.kolab.org/index.php/Solaris with the link: > > http://www.comcept.ch/kolab2/solaris_10_kolab2_2.2.1_install.txt > > Regarding the overall installation some notes/info/questions: > > http://www.mail-archive.com/openpkg-users at openpkg.org/msg03468.html This > issue regarding not useable TLS/SSL libraries is based on the check how this > is determed. I used newest openssl-0.9.8k-20090326.src.rpm openpkg package > as apache-2.2.11-20090201.src.rpm and with the new apache package it works. > To cover the compilation from beginning I manipulated 00INDEX.rdf. > > https://www.intevation.de/roundup/kolab/issue2924 . For this I received a > link and a comment "Please try install-kolab.sh from CVS HEAD". > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/*checkout*/server/install-kolab.s > h . I tested and it seems to work without error but this is not included > within the final release and because of this I documented in this way that > the -maxdepth/-mindepth has to be completly removed from the > install-kolab.sh. > > https://www.intevation.de/roundup/kolab/issue1809 .This issue I'm only able > to solve if I include in the .spec file "--enabled-shared=yes" after the > compilation fails as to install the package manually. As a pity I was not > able to build in this option in 00INDEX.rdf which would be nice. Any hints > appriciated how this can be performed. > > https://www.intevation.de/roundup/kolab/issue3315 . This issue still exists > and is still the case for following packages: > > PEAR-Horde-Channel "install: pear.horde.org.xml was not found > anywhere!" > > PEAR-PHPUnit-Channel "install: pear.phpunit.de.xml was not found > anywhere!" As far as I can see the problematic option -p has been removed from the spec file. So is there an additional problem? Can you add a comment about it in the bug? Thanks! > > > Workaround for external authentication has to be still implemented and is > based on behaviour of Solairs > http://www.postfix.org/SMTPD_POLICY_README.html > > > After Installation "and correct generating the cert" following appears in > the apache log: > > [warn] RSA server certificate CommonName (CN) `kolab2.mydomain.ch' does NOT > match server name!? > [notice] Digest: generating secret for digest authentication ... > [notice] Digest: done > [notice] Apache/2.2.11 (OpenPKG/CURRENT) mod_ssl/2.2.11 OpenSSL/0.9.8k > PHP/5.2.8 configured -- resuming normal operations > > This is based how you configure httpd.conf.template. Solaris 10 does not > like within a Zone that to localhost is pointed and it seems that in this > way the host name can not be anymore correct defined. I changed to IP and > the warning dissapeared: > > Listen xxx.xxx.xxx.xxx:80 > Listen xxx.xxx.xxx.xxx:443 > > > > Finally I tested everything and also looked through the logs. From functions > point of view all is working now issues found but there are some questions > from my site which would be intressting to be verified or commented on your > site: > > Even all works I have in the logs for impad following: > > > ==> /kolab/var/imapd/log/cyr_db.log <== > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no > absolute path for the current directory: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing > log files: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive > /kolab/var/imapd/db: cyrusdb error > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no > absolute path for the current directory: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing > log files: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive > /kolab/var/imapd/db: cyrusdb error > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR db4: no > absolute path for the current directory: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: error listing > log files: Permission denied > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: DBERROR: archive > /kolab/var/imapd/db: cyrusdb error > Apr 13 09:40:16 sphaere ctl_cyrusdb[19070]: done checkpointing > cyrus databases > > I do not know where this log entries are coming from....I checked the log > permisssion and if I set to 777 (which is of course not visible) the error > does not disappear. The warning regarding DB4 I was also not able to > identify...can you give me some hints specially regarding DB4 which seems to > be configured with a local path instead of absolut one?! > > > Regarding Horde following questions/notes > > > I configured /kolab/etc/kolab/templates/slapd.conf.template in and > activated: > include /kolab/etc/openldap/schema/horde.schema as defined in > /kolab/var/kolab/www/horde/config/conf.php "$conf['auth']['admins'] = > array('user at mydomain.ch');" . In this way I'm able to manipulate Horde from > this defined user but this seems not be the right way? What are here the > rules specially because I saw that in the template dir a lot of horde stuff > appears. I saw that under the global config of Horde the Tab Kolab appears > but the fields are used with example stuff. I changed and after applying the > Konfig everything failed and I had to roll-back. At the moment I do not > understand the system here used meaning is it visible to manipulate horde > over web? Correct. It is not possible to use the Horde configuration system via the web with the kolab-webadmin. I'm still in favor of simply removing the complete admin section of the horde installation for Kolab. Currently we just disabled it by setting "$conf['auth']['admins'] = array();" so that there are no admin users. But of course it is easy for people to find out how to add admins there, not knowing that they might kill their Horde installation this way. The problem is that the Horde configuration is a rather complex topic as you have many options. Some of these options are simply required for Kolab to work and should not be changed. Hm, though actually it might not be hard to change that. We could just remove the critical config variables, write them via templates and offer the web admin for all the rest. I'll have to think about it :) -> https://www.intevation.de/roundup/kolab/issue3564 Cheers, Gunnar > > Even horde seems to work for a normal user I have a lot of funny stuff > within the log like: > > Apr 13 09:54:32 HORDE [debug] [horde] IMAP errors: SECURITY PROBLEM: > insecure server advertised AUTH=PLAIN SECURITY PROBLEM: insecure server > advertised AUTH=PLAIN [pid 17129 on line 175 of > "/opt/kolab/var/kolab/www/client/imp/lib/IMAP.php"] > > [13-Apr-2009 09:58:34] PHP Notice: Unknown: SECURITY PROBLEM: insecure > server advertised AUTH=PLAIN (errflg=1) in Unknown on line 0 > > Apr 13 09:54:30 HORDE [debug] [kronolith] Hook _horde_hook_share_init in > application horde not called. [pid 17129 on line 1683 of > "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:30 HORDE [debug] [kronolith] Hook > _prefs_change_hook_display_remote_cals in application horde not called. [pid > 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:30 HORDE [debug] [kronolith] Hook > _prefs_change_hook_display_external_cals in application horde not called. > [pid 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:30 HORDE [debug] [kronolith] Hook > _prefs_change_hook_display_cals in application horde not called. [pid 17129 > on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:31 HORDE [debug] [nag] Hook _horde_hook_share_init in > application horde not called. [pid 17129 on line 1683 of > "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:31 HORDE [debug] [nag] Hook > _prefs_change_hook_display_tasklists in application horde not called. [pid > 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:31 HORDE [debug] [mnemo] Hook _horde_hook_share_init in > application horde not called. [pid 17129 on line 1683 of > "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > Apr 13 09:54:31 HORDE [debug] [mnemo] Hook > _prefs_change_hook_display_notepads in application horde not called. [pid > 17129 on line 1683 of "/opt/kolab/var/kolab/www/client/lib/Horde.php"] > > > Apr 13 09:54:32 HORDE [debug] [horde] Max memory usage: 14942208 bytes [pid > 17129 on line 339 of > "/opt/kolab/var/kolab/www/client/lib/Horde/Registry.php"] > > What I have also to say is that Horde is very slow...any ideas to speed up. > My server has 4 CPUS and 4 GB Memory as is using the fast ZFS Filesystem!? > Also that Horde cache's within tmp is not a good idea meaning if I > understood all correct this cache files will nobody clean up correct? There should still be a number of possibilities to speed it up. It is currently not yet using an optimal configuration set. I hope to be able to dig deeper into that soon. Thanks for you feedback! Cheers, Gunnar > > I hope this gives you a overview and would be nice to have some feedback > regarding the comments/notes/info etc. > > Mit freundlichen Gr?ssen > > Andrea Soliva > > Mail: soliva at comcept.ch > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090417/4b4d7d05/attachment.bin From kolab-issues at intevation.de Fri Apr 17 15:04:51 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Fri, 17 Apr 2009 13:04:51 +0000 Subject: [Kolab-devel] [issue3565] Kleopatra: Configuration of the gnupg-system throws: operation not permitted error message and failed. Message-ID: <1239973491.16.0.0524235780065.issue3565@intevation.de> New submission from Ludwig Reiter : Kontact Installer 20090410 gpg4win 1.9.15 beta Test: 1. Start kontact. 2. Open kleopatra. 3. Open the configuration dialog. 4. Switch to GnuPG system menu. 5. Set a option like "Reduzierte Informationen" (in German) "less information" (English) 6. Press on okay. => An error message appears: "Error from gpgconf while saving configuration: Operation not permitted." Perhaps this is a packaging problem. If I uninstall Kontact, kleopatra works with no problems. ---------- assignedto: ludwig messages: 19710 nosy: allen, bernhard, bh, ludwig priority: urgent status: unread title: Kleopatra: Configuration of the gnupg-system throws: operation not permitted error message and failed. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Fri Apr 17 16:17:42 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Fri, 17 Apr 2009 14:17:42 +0000 Subject: [Kolab-devel] [issue3566] A new created event vanshes after restart Message-ID: <1239977862.52.0.157948016829.issue3566@intevation.de> New submission from Ludwig Reiter : Kontact Installer 20090410.951807 Test: 1. Switch to calendar view. 2. Create a new appointment. 3. Sync. 4. Restart kontact => The new created appointment is gone. I expect the appointment to stay in the resource. Output: output-20090417.log ---------- assignedto: allen files: output-20090417.log messages: 19715 nosy: allen, bernhard, bh, ludwig priority: critical status: unread title: A new created event vanshes after restart topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: output-20090417.log Type: application/octet-stream Size: 4826 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090417/d0d78511/output-20090417.exe From kolab-issues at intevation.de Fri Apr 17 18:01:11 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Fri, 17 Apr 2009 16:01:11 +0000 Subject: [Kolab-devel] [issue3567] Migrate Horde prefs 2.2.0 -> 2.2.1 Message-ID: <1239984071.2.0.397030119146.issue3567@intevation.de> New submission from Albrecht Dre? : As Horde in Kolab 2.2.1 uses a different backend for storing the preferences it should come with a tool to migrate them from 2.2.0 (LDAP storage). I started with that task, and the attached script can be used to dump the preferences of all users which have a 'hordePerson' objectClass into separate files. I should add at this point that I have no experience in php programming, so the script is probably really ugly... Now I need an other script for 2.2.1 which does the opposite, i.e. auth as manager, read the prefs file(s), and let Horde store that data. However, I already failed with writing a 10-liner which creates an Auth object from the command line... Maybe one of the gurus can provide me with an example for that? Thanks in advance, Albrecht. ---------- files: kolab220-get-prefs.php messages: 19719 nosy: albrecht.dress priority: feature status: unread title: Migrate Horde prefs 2.2.0 -> 2.2.1 topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: kolab220-get-prefs.php Type: application/x-httpd-php Size: 2898 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090417/84a5dd0f/kolab220-get-prefs.bin From kolab-issues at intevation.de Fri Apr 17 18:08:26 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Fri, 17 Apr 2009 16:08:26 +0000 Subject: [Kolab-devel] [issue3568] umlauts broken in automatically accepted events Message-ID: <1239984506.29.0.570922775238.issue3568@intevation.de> New submission from Thomas Arendsen Hein : Kolab Server 2.2.1, kontact enterprise35 20090313.938853 An automatic resource (REJECT_IF_CONFLICTS) accepts an event sent by kontact containing german umlauts in body/summary. When using kontact to look at the resource's calendar folder, it displays "?" as "??", i.e. interprets utf-8 as latin1. The mail source in a normal user's calendar contains: Content-Transfer-Encoding: quoted-printable ...=C3=A4...

...=C3=A4... The mail source in the resource's calendar contains: Content-Transfer-Encoding: quoted-printable ...ä... ...ä... (I omitted many lines, but the main differences should be clear) Just checked with the web client included in server 2.2.1: It shows the same broken umlauts Fixing this for 2.2.2 is important unless the changes would be too big. ---------- assignedto: wrobel messages: 19720 nosy: martin, thomas, wilde, wrobel priority: urgent status: unread title: umlauts broken in automatically accepted events topic: filter, server ___________________________________________________ Kolab issue tracker ___________________________________________________ From wrobel at pardus.de Fri Apr 17 22:11:13 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 17 Apr 2009 22:11:13 +0200 Subject: [Kolab-devel] PHP LDAP library moved to Horde 4 Message-ID: <20090417221113.15493wy8fgvzl02s@webmail.pardus.de> Hi! As it might be of interest to some in the development community I wanted to provide some news on the current cutting edge development of the Kolab Server PHP libraries. This mail is concerned with the LDAP subsystem and I'm glad to get feedback from anyone interested in the Kolab LDAP schema as well as applications like the Kolab web admin. Please note that this is not about released software but only an overview on ongoing work. As mentioned here and there the PHP libraries in the Kolab Server are currently making progress towards the next Horde version (Horde 4). Horde 3 has been stable for a long period of time and thus the APIs of the different libraries were frozen. Horde 4 means that the APIs get loosened up for a while until the first application releases of the new Horde series occurs. The first package of the Kolab Server libraries that successfully made the transition is the Kolab_Server package. It abstracts all LDAP handling required for the Kolab Server. The package version currently included in the Kolab_Server resided here: http://cvs.horde.org/framework/Kolab_Server/ The next version of the library lives here: http://cvs.horde.org/framework/Kolab_Server/?rt=horde-git The API changes for the transition were actually pretty minor. The other packages depending on Kolab_Server saw some small modifications and all unit tests in the dependent packages are still running fine. On the inside of the library some important additions/changes have been made: * Schema support. The class can adapt to a certain degree to the LDAP schema that is actually being used on the server. * Use of class variables to represent objectClass attributes. This allows to quickly adapt your server to an LDAP situation where you use non-standard attribute names. * Cleaner class structure that matches the objectClass structure and also allows to represent logical object types. * Separate classes to handle the LDAP tree structure This allows quicker adaption to new or modified LDAP tree structures. * Real LDAP server unit testing. This will allow to run functionality checks on a configured server. * Added LDAP write support. This allows creating users on your Kolab server. All this concludes the migration path from the initial situation where we had LDAP specific code in the Kolab resource management, the Kolab free/busy system, the Kolab web admin as well as the Kolab web client. All subsystems can now use a central component that will hopefully allow us to adapt the code more easily to long overdue LDAP schema changes (such as the cn=... -> mail=... problem) without needing to code in many places at the same time. I also started on a very thin application layer on top of Kolab_Server that might at some point replace the Kolab web admin. The application is called "koward" and lives here: http://cvs.horde.org/koward/?rt=horde-hatchery Any input on things you always wished for in the Kolab web admin would be of interest. I know there have been some Kolab web admin changes under discussion on this list recently and I hope to be able to take them into account early on during the development process. Cheers, Gunnar -- ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090417/dc2f45d2/attachment-0001.bin From alar.sing at err.ee Sat Apr 18 12:02:01 2009 From: alar.sing at err.ee (Alar Sing) Date: Sat, 18 Apr 2009 13:02:01 +0300 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <49E6156C.9090903@err.ee> References: <49E5F326.6090405@err.ee> <200904151858.29283.martin.konold@erfrakon.de> <49E6156C.9090903@err.ee> Message-ID: <20090418130201.16905qnunm0cso4k@mail.err.ee> Quoting Alar Sing : > Martin Konold wrote: >> Am Mittwoch, 15. April 2009 16:45:58 schrieb Alar Sing: >> >> Hi, >> >> >>> When I change parameter $conf['fb']['use_acls'] to false then I userA >>> can see his own freebusy information, but not userB's freebusy information >>> >> >> Are you sure that you installed kolab and not a normal cyrus imapd? >> >> Yours, >> -- martin >> >> > I think I installed kolab cyrus imapd > rpm -qa | grep cyrus gives > cyrus-sasl-saslauthd-2.1.22-182.1 > cyrus-sasl-digestmd5-2.1.22-182.1 > cyrus-sasl-devel-2.1.22-182.1 > cyrus-sasl-crammd5-2.1.22-182.1 > cyrus-sasl-2.1.22-182.1 > cyrus-sasl-plain-2.1.22-182.1 > cyrus-imapd-kolab-2.3.13-63.1 <-- this looks like kolab package > cyrus-sasl-gssapi-2.1.22-182.1 > > And when I looked with cyradm info about users Calendar folder > > {user/alar/Calendar at sise.etv.ee}: > condstore: false > duplicatedeliver: false > lastpop: > lastupdate: 14-Apr-2009 19:58:42 +0300 > partition: default > sharedseen: false > size: 1617 > folder-type: event.default <-this should be only possible with kolab > package > > I did some debugging on this issue something is wrong in class Horde_Kolab_FreeBusy_Cache_DB function &singleton after $cachedb[$signature] = new $class($cache_dir); line there is nothing script stops here with $class($cache_dir) being Horde_Kolab_FreeBusy_Cache_DB_acl(/var/cache/freebusy) I looked /var/cache/freebusy has owner apache user and has correct chmod out put from pear list -c horde Argv 0.1.0 beta Auth 0.1.1 beta Group 0.1.0 beta Horde_Browser 0.0.2 alpha Horde_CLI 0.0.2 alpha Horde_Cache 0.0.2 alpha Horde_Cipher 0.0.2 alpha Horde_Compress 0.0.2 alpha Horde_DOM 0.1.0 alpha Horde_DataTree 0.0.3 alpha Horde_Date 0.1.0 beta Horde_Form 0.0.2 alpha Horde_Framework 0.0.2 beta Horde_History 0.0.2 alpha Horde_Identity 0.0.2 alpha Horde_LDAP 0.0.2 alpha Horde_MIME 0.0.2 alpha Horde_NLS 0.0.2 alpha Horde_Notification 0.0.2 alpha Horde_Prefs 0.0.3 alpha Horde_SQL 0.0.2 alpha Horde_Secret 0.0.2 alpha Horde_Serialize 0.0.2 alpha Horde_SessionObjects 0.0.2 alpha Horde_Text_Filter 0.0.2 alpha Horde_Token 0.0.4 beta Horde_Tree 0.0.2 alpha Kolab_Filter 0.1.5 alpha Kolab_Format 1.0.1 stable Kolab_FreeBusy 0.1.4 alpha Kolab_Server 0.4.0 alpha Kolab_Storage 0.4.0 alpha Perms 0.1.0 beta Text_reST 0.0.2 alpha Util 0.1.0 beta iCalendar 0.1.0 beta Can anybody help me with this problem, It would be nice to have opensuse native kolab installation From ml at radoeka.nl Sat Apr 18 16:44:12 2009 From: ml at radoeka.nl (Richard Bos) Date: Sat, 18 Apr 2009 16:44:12 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <20090418130201.16905qnunm0cso4k@mail.err.ee> References: <49E5F326.6090405@err.ee> <49E6156C.9090903@err.ee> <20090418130201.16905qnunm0cso4k@mail.err.ee> Message-ID: <200904181644.14442.ml@radoeka.nl> Hi Alar, Op zaterdag 18 april 2009 12:02:01 schreef Alar Sing: > I did some debugging on this issue > something is wrong in class Horde_Kolab_FreeBusy_Cache_DB function > &singleton after $cachedb[$signature] = new $class($cache_dir); line > there is nothing script stops here with $class($cache_dir) being > Horde_Kolab_FreeBusy_Cache_DB_acl(/var/cache/freebusy) > I looked /var/cache/freebusy has owner apache user and has correct chmod To exclude any problem with the permissions just make the directory 777. That way you know for sure that it should work. After the correct permission or user settings can be determined. I found a diff between the openSUSE version and the openpkg version of the file Horde/Kolab/FreeBusy/Cache.php The diff is as follows: # cat /var/tmp/Horde_Kolab_Freebusy_Cache.diff --- /usr/share/php5/PEAR/Horde/Kolab/FreeBusy/Cache.php 2009-04-10 22:45:52.000000000 +0200 +++ /var/tmp/Cache.php 2009-04-18 16:17:17.000000000 +0200 - * $Horde: framework/Kolab_FreeBusy/lib/Horde/Kolab/FreeBusy/Cache.php,v 1.17.2.3 2009/03/20 22:03:32 wrobel Exp $ + * $Horde: framework/Kolab_FreeBusy/lib/Horde/Kolab/FreeBusy/Cache.php,v 1.17 2008/12/12 15:00:07 wrobel Exp $ * * Copyright 2004-2008 Klar?lvdalens Datakonsult AB * @@ -169,8 +169,6 @@ if (is_a($result, 'PEAR_Error')) { return $result; } - } else { - $acl = null; } Horde::logMessage(sprintf("Horde_Kolab_FreeBusy_Cache::store(file=%s, relevance=%s, acl=%s, xacl=%s)", @@ -363,9 +361,27 @@ /* Check if the calling user has access to the extended information of * the folder we are about to integrate into the free/busy data. */ - $groups = $access->user_object->getGroups(); - if (is_a($groups, 'PEAR_Error')) { - return $groups; + $uid_groups = $access->user_object->getGroups(); + if (is_a($uid_groups, 'PEAR_Error')) { + return $uid_groups; + } + + global $conf; + require_once 'Horde/Kolab/Server.php'; + /* Connect to the Kolab user database */ + $db = &Horde_Kolab_Server::singleton(array('uid' => $conf['kolab'] ['ldap']['phpdn'])); + + $groups = array(); + foreach ($uid_groups as $uid) { + $group = $db->fetch($uid); + if (is_a($groups, 'PEAR_Error')) { + continue; + } + $mail = $group->get(KOLAB_ATTR_MAIL); + if (is_a($mail, 'PEAR_Error')) { + continue; + } + $groups[] = $mail; } $groups[] = $access->user; Compared to the openSUSE file, openpkg has something added to the file. It's a little weird as the openpkg seems to be a little older.... I can't determine if the different code will have impact on the problem that we see. I'll sent you the openpkg version in private. Perhaps you can test it with that one? -- Richard From kolab-issues at intevation.de Sat Apr 18 17:06:38 2009 From: kolab-issues at intevation.de (Julian G) Date: Sat, 18 Apr 2009 15:06:38 +0000 Subject: [Kolab-devel] [issue3569] Kolab-Wizard should set LDAP-Credentials Message-ID: <1240067198.66.0.415358606677.issue3569@intevation.de> New submission from Julian G : Kolab-Wizard should set user credentials for LDAP authentication. Combined with matching rules in LDAP configuration and/or subtrees for each domain (and Kolab server) LDAP access would become multidomain usable. ---------- messages: 19728 nosy: glua status: unread title: Kolab-Wizard should set LDAP-Credentials ___________________________________________________ Kolab issue tracker ___________________________________________________ From ml at radoeka.nl Sat Apr 18 20:25:46 2009 From: ml at radoeka.nl (Richard Bos) Date: Sat, 18 Apr 2009 20:25:46 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <20090418183104.11154nhd4fw8du68@mail.err.ee> References: <49E5F326.6090405@err.ee> <200904181703.35076.ml@radoeka.nl> <20090418183104.11154nhd4fw8du68@mail.err.ee> Message-ID: <200904182025.47847.ml@radoeka.nl> Op zaterdag 18 april 2009 17:31:04 schreef Alar Sing: > Hello, > > When freebusy config.php has parameter $conf['fb']['use_acls'] set to > false then cache files appear into folder /var/cache/freebusy and > freebusy works. Interesting observation... So, it must have to do something with the code that is driven / controlled by the variable $conf['fb']['use_acls'] > I also tryed setting freebusy folder 777 but this did not change anything > I tryed to compile openpkg imap lib source and this did nothing > I used openpkg source and patched for pear modules iCalendar, > Kolab_Format, Kolab_FreeBusy, Kolab_Server and Kolab_Storage and no > luck it still does not work when freebusy config.php has parameter > $conf['fb']['use_acls'] set to true You did an awful lot, very impressive! Is it possible for you to determine which '$conf['fb']['use_acls'] == true' legs are entered / used by the code? Perhaps that shows where it goes wrong? A big grep for use_acls in the Horde directory shows that the variable is only used in: Kolab/FreeBusy/Cache.php Horde # grep -Rn use_acls * Binary file Kolab/FreeBusy/.Cache.php.swp matches Kolab/FreeBusy/Cache.php:98: if (!empty($conf['fb']['use_acls'])) { Kolab/FreeBusy/Cache.php:114: if (!empty($conf['fb']['use_acls'])) Kolab/FreeBusy/Cache.php:135: if (!empty($conf['fb']['use_acls'])) Kolab/FreeBusy/Cache.php:199: if (!empty($conf['fb']['use_acls'])) { Kolab/FreeBusy/Cache.php:231: if (!empty($conf['fb']['use_acls'])) { Kolab/FreeBusy/Cache.php:280: if ($extended && !empty($conf['fb'] ['use_acls'])) { I assume that not all legs are used... -- Richard From wrobel at pardus.de Sun Apr 19 05:50:02 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 05:50:02 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <200904181644.14442.ml@radoeka.nl> References: <49E5F326.6090405@err.ee> <49E6156C.9090903@err.ee> <20090418130201.16905qnunm0cso4k@mail.err.ee> <200904181644.14442.ml@radoeka.nl> Message-ID: <20090419055002.32847grebswq3zc4@webmail.pardus.de> Quoting Richard Bos : > Hi Alar, > > Op zaterdag 18 april 2009 12:02:01 schreef Alar Sing: >> I did some debugging on this issue >> something is wrong in class Horde_Kolab_FreeBusy_Cache_DB function >> &singleton after $cachedb[$signature] = new $class($cache_dir); line >> there is nothing script stops here with $class($cache_dir) being >> Horde_Kolab_FreeBusy_Cache_DB_acl(/var/cache/freebusy) >> I looked /var/cache/freebusy has owner apache user and has correct chmod > > To exclude any problem with the permissions just make the directory > 777. That > way you know for sure that it should work. After the correct permission or > user settings can be determined. > > I found a diff between the openSUSE version and the openpkg version of the > file Horde/Kolab/FreeBusy/Cache.php > The diff is as follows: > # cat /var/tmp/Horde_Kolab_Freebusy_Cache.diff > --- /usr/share/php5/PEAR/Horde/Kolab/FreeBusy/Cache.php 2009-04-10 > 22:45:52.000000000 +0200 > +++ /var/tmp/Cache.php 2009-04-18 16:17:17.000000000 +0200 > - * $Horde: framework/Kolab_FreeBusy/lib/Horde/Kolab/FreeBusy/Cache.php,v > 1.17.2.3 2009/03/20 22:03:32 wrobel Exp $ > + * $Horde: > framework/Kolab_FreeBusy/lib/Horde/Kolab/FreeBusy/Cache.php,v 1.17 > 2008/12/12 15:00:07 wrobel Exp $ > * > * Copyright 2004-2008 Klar?lvdalens Datakonsult AB > * > @@ -169,8 +169,6 @@ > if (is_a($result, 'PEAR_Error')) { > return $result; > } > - } else { > - $acl = null; > } > > > Horde::logMessage(sprintf("Horde_Kolab_FreeBusy_Cache::store(file=%s, > relevance=%s, acl=%s, xacl=%s)", > @@ -363,9 +361,27 @@ > /* Check if the calling user has access to the extended information > of > * the folder we are about to integrate into the free/busy data. > */ > - $groups = $access->user_object->getGroups(); > - if (is_a($groups, 'PEAR_Error')) { > - return $groups; > + $uid_groups = $access->user_object->getGroups(); > + if (is_a($uid_groups, 'PEAR_Error')) { > + return $uid_groups; > + } > + > + global $conf; > + require_once 'Horde/Kolab/Server.php'; > + /* Connect to the Kolab user database */ > + $db = &Horde_Kolab_Server::singleton(array('uid' => $conf['kolab'] > ['ldap']['phpdn'])); > + > + $groups = array(); > + foreach ($uid_groups as $uid) { > + $group = $db->fetch($uid); > + if (is_a($groups, 'PEAR_Error')) { > + continue; > + } > + $mail = $group->get(KOLAB_ATTR_MAIL); > + if (is_a($mail, 'PEAR_Error')) { > + continue; > + } > + $groups[] = $mail; > } > > $groups[] = $access->user; > > Compared to the openSUSE file, openpkg has something added to the file. It's > a little weird as the openpkg seems to be a little older.... This is not that weird :) The OpenPKG version is about stability and testing. So we currently use Kolab_FreeBusy-0.1.2 with a few selected patches for Kolab-Server-2.2.1. This set has been tested for stability. If you need that stability for you system you should try to mirror the OpenPKG packages as close as possible. > I can't determine if the different code will have impact on the > problem that we see. This may well be the case. The "use_acl" section was a patch somebody submitted. It had some initial problems but I had hoped to eliminate them all. As I want to switch to the newer code (Kolab_FreeBusy-0.1.4) within Kolab Server CVS HEAD you should open an issue. I'll take a close look than. Cheers, Gunnar > I'll sent you the openpkg version in private. Perhaps you can test it with > that one? > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/c097bef8/attachment.bin From wrobel at pardus.de Sun Apr 19 05:57:46 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 05:57:46 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <200903082209.58995.ml@radoeka.nl> References: <200903071341.45223.richard@radoeka.nl> <200903072326.56610.ml@radoeka.nl> <20090308164610.6323525zxilr6zk0@webmail.pardus.de> <200903082209.58995.ml@radoeka.nl> Message-ID: <20090419055746.193486culnyvoabc@webmail.pardus.de> Hi Richard, Quoting Richard Bos : > Hi Gunnar, > > Op zondag 08 maart 2009 16:46:10 schreef Gunnar Wrobel: >> >> You can also set 'display_errors' to be 'On'. In that case PHP errors >> >> should be dumped to the browser. >> > >> > # grep errors /srv/www/htdocs/freebusy/config.php >> > ini_set('display_errors', 1); >> > >> > It looks like the logs are set correctly. I wonder why nothing gets >> > logged when line 216 >> > ($result = $this->_cache->load($access, $req_extended);) is >> > executed, hopefully you have a clue? >> >> Hm, that might make it hard to find the error. I guess you hit >> something where an '@' is used to supress error messages. These are >> problematic for the exact reason that debugging can be quite difficult. >> >> If you'd have a PHP debugger running it would be easy but I assume >> that is not the case. > > Hmm, I'm not aware that I have a PHP debugger around. How does one > get such a > beast? Is this part of php or is it a seperate application? http://wiki.kolab.org/index.php/PHP_debugging I myself use Emacs with Geben as debugging frontend. Might not be everyones favorite though :) and could be harder to setup if you don't know Emacs well. Eclipse with PDT is also a very good choice. > >> Do you use the Kolab PHP libraries on a server that has an unpatched >> PHP (meaning not patched for Kolab)? In that case the PEAR-Net_IMAP >> library might be missing. > > I was sure that I was using php5-imap-kolab (which is the patched version of > php5-imap), but it was not installed. I corrected that and now the the > package is pulled in correctly. Unfortunately, it did not solve the problem. > The same problem is still there. Anyway, would it be possible to add unit > tests, that test the correct working of the kolab patches that are added to > imap > (http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/imap/) > and php > (http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/php/) or are you > already testing these? Is this possible at all, if it is possible > it would be > very useful. I think that should be possible. Please open an issue so that I don't forget about it. My focus is currently not on Kolab_Storage and the tests belong there. But I'll return there eventually :) > > If you or someone else has an idea, to get me going a little further that > would be nice and appreciated. Does the problem still persist? I know I responded very late now. I tend to be somewhat too busy these days :( Cheers, Gunnar > > -- > Richard > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/2fc8e747/attachment-0001.bin From wrobel at pardus.de Sun Apr 19 06:41:40 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 06:41:40 +0200 Subject: [Kolab-devel] custom Kolab 2.2 patch adding new features for ISP functionality In-Reply-To: <200903091648.18160.mailinglists@tbits.net> References: <200903091648.18160.mailinglists@tbits.net> Message-ID: <20090419064140.106052cjarztcx44@webmail.pardus.de> Hi Martin! Quoting Martin Zapfl : > Hi there, > > we did some enhancements to Kolab Webamin. Cool, thanks for contributing them. > This patch is applied to Kolab version 2.2 > It adds a lot of new features mostly used in ISP environments. > > Most import changes are: > - Mange customers > - Prefixes can be used to set UIDs > - Each customers data is stored in a separate LDAP subtree > - Each customer can have its own users, address book, shared folders or > distribution lists > - Set maximum number of accounts, domain and default quotas > - Set password security and view customer password information page > - Groupware can be disabled for single customers I think this should be https://www.intevation.de/roundup/kolab/issue2207 Is that correct? > - Assign domain administrators to a customer > - Show usage of users IMAP accounts > - Users can enable vacation and e-mail forwarding at the same time > - restrict login in webadmin only to UID and deny E-Mail address login > > You may want to take a look at it: > https://www.intevation.de/roundup/kolab/issue3463 > > This is still a beta release. Do not install it on production machines!! > We are looking forward for your feedback. As Martin wrote in the issue it would be really good to provide the feature additions in different issues with one patch per feature. I looked at the large patch and I'm pretty certain we won't immediately apply it as a whole. As you saw there will probably discussions concerning the one or the other point. So this would make it a lot easier to go through the features together. As I'm currently working on Kolab_Server and started on a potential replacement for the Kolab webadmin I'd be interested in taking your feature additions into consideration at an early timepoint. Kolab_Server is the PHP LDAP library we use in the web client, the resource manager and the free/busy system. The Kolab web admin did not use the same library as it requires way more LDAP functionality than the other systems. And this has been only added now to Kolab_Server. The new library has automatic schema analysis support which might benefit your needs. The replacement for kolab webadmin is already now able to display new attributes in the forms once they have been defined in the schema. This has been a lot more difficult in the kolab web admin. Cheers, Gunnar > > best regards > Martin Zapfl > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/7f6d8287/attachment.bin From wrobel at pardus.de Sun Apr 19 07:26:53 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 07:26:53 +0200 Subject: [Kolab-devel] custom Kolab 2.2 patch adding new features for ISP functionality In-Reply-To: <200903121551.22377.mailinglists@tbits.net> References: <200903091648.18160.mailinglists@tbits.net> <20090310151530.GA21918@xs4all.nl> <200903102019.06564.martin.konold@erfrakon.de> <200903121551.22377.mailinglists@tbits.net> Message-ID: <20090419072653.62919btiskw6a3hc@webmail.pardus.de> Hi Martin, Quoting Martin Zapfl : > Hi Martin, > > slapo-ppolicy sounds pretty interesting. I just took a look at it. I have to > check some internal questions and will tell you if we are willing to code the > feature. just as a note: It is very likely that support for this will get added very soon into the Kolab_Server library (http://pear.horde.org/index.php?package=Kolab_Server). So there is probably no need for action from your side. I'll keep the issue up to date. Cheers, Gunnar > > best regards > Martin > > On Tuesday 10 March 2009 08:19:05 pm Martin Konold wrote: >> Am Dienstag, 10. M?rz 2009 16:15:30 schrieb Richard Bos: >> > On Tue, Mar 10, 2009 at 02:26:15PM +0100, Martin Konold wrote: >> > > Am Dienstag, 10. M??rz 2009 13:56:24 schrieb Martin Zapfl: >> > > >> > > Hi Martin, >> > > >> > > > > So the idea is that it is easier to guess the email address than >> > > > > the uid which is supposed to provide extra security? >> > > > >> > > > Yes, the idea is to protect users with a weak password. >> > > >> > > I consider it a valid requirement to protect users from weak passwords. >> > > >> > > IMHO Kolab should support this. >> > >> > Isn't this already requested and covered in issue: >> > https://www.intevation.de/roundup/kolab/issue3025 >> >> Yes, it is already covered there. >> >> I already proposed the same solution back then but nobody took the effort >> of actually integrating this option. No big coding is required because the >> feature is already part of OpenLDAP since a while. It is mainly an >> integration task so that it is setup with reasonable defaults, documented >> and >> configurable. >> >> Yours, >> -- martin > > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/4f79c2fd/attachment.bin From wrobel at pardus.de Sun Apr 19 08:02:03 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 08:02:03 +0200 Subject: [Kolab-devel] LDAP attribute kolabHomeServerOnly In-Reply-To: <20090416124724.GA9750.thomas@intevation.de> References: <20090416141550.18581kjws91wghog@webmail.pardus.de> <20090416124724.GA9750.thomas@intevation.de> Message-ID: <20090419080203.43051kz0jix9w50g@webmail.pardus.de> Quoting Thomas Arendsen Hein : > * Gunnar Wrobel [20090416 14:16]: >> Guess I'm somewhat slow in reviewing code these times as these are >> changes from February: >> >> http://kolab.org/pipermail/kolab-commits/2009q1/009163.html >> http://kolab.org/pipermail/kolab-commits/2009q1/009165.html >> >> Can you explain in more detail why this LDAP schema change was >> necessary and what the functionality >> is about? My gut feeling would be that a new LDAP attribute might >> be too much and I feel we already >> packed too many such attributes in our schema. So I felt the need >> to understand this change. > > Regarding the functionality: > > Not all IMAP clients need the dummy inbox on the other servers and > you only need it anyway if users on one Kolab server need to access > shared/published folders on a different Kolab server in a > master/slave setup. > > The functionality was requested by a client who does not want to > clutter the IMAP spool directories with directories which are not > used in his setup. > > Regarding the LDAP change: > > It is only a schema extension, so it will not affect existing > installations. The reason for adding it to LDAP is to have identical > behavior on all servers. The reason for adding it as a user > attribute instead of a global attribute is that you still might want > to have certain users with mailboxes on all servers, because you > know they have IMAP clients needing the additional inboxes. > > Like some other LDAP attributes it is not wired to the web admin > interface, so that does not even get cluttered with bells&whistles > that most people do not need. Hm, that is true. But the schema itself gets just another attribute linked to some functionality that is not really obvious. I've raised this issue before and I'm actually still opposed to adding new attributes for functionality offered by a single client application. I'd rather have an attribute "kolabdPreferences" that can occur multiple times and carries values such as "home_server_only=true". There are other attributes just relevant for postfix and new attributes have been proposed solely for features one might add to the web admin. I consider this a broken approach. I know others disagree and maybe new attributes are indeed necessary. I'd like to ask though that they get more documentation in the schema. There are already now many attributes where I don't know what they were meant for and if there are Kolab server subsystems that might use this attribute. Yes, one can grep through the code in Kolab CVS to find locations where the attribute may be used. But I don't consider that optimal. Another suggestion: If we really want to add such attributes to our object classes which are only relevant for a single LDAP-aware application we might group these in their own object class (e.g. kolabPreferenceKolabd) as a supplemental object class to kolabInetOrgPerson. Cheers, Gunnar > >> I probably overlooked the references where this was explained in >> more detail so a hint would be >> great. Thanks! > > There was no public discussion about this. > > Regards, > Thomas Arendsen Hein > > -- > thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: > 0x5816791A > Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, > HR B 18998 > Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/b35baa69/attachment.bin From kolab-issues at intevation.de Sun Apr 19 09:14:58 2009 From: kolab-issues at intevation.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 07:14:58 +0000 Subject: [Kolab-devel] [issue3570] Viewingg external addresses fails to display phone numbers (and potentially other values) Message-ID: <1240125298.68.0.779424177212.issue3570@intevation.de> New submission from Gunnar Wrobel

: As stated here http://kolab.org/pipermail/kolab-users/2009-April/009719.html the kolab web admin fails to display telephone numbers for external addresses. The value are actually saved just fine in LDAP but the are not displayed anymore. The problem originates from /kolab/var/kolab/www/admin/addressbook/addr.php line 37, 38. It is possible to remove the strtolower() calls and the telephone numbers will be shown. Either this has been broken for a long long time or the LDAP server/PHP suddenly returns ldap_read() results with attribute names in camel case. As I can imagine that some LDAP variants always result in lower case attribute names I guess the strtolower() should not be simply removed. Instead it might be better to lower case the keys of the ldap_read() result. ---------- assignedto: wrobel messages: 19733 nosy: bernhard, martin, thomas, wilde, wrobel priority: bug status: chatting title: Viewingg external addresses fails to display phone numbers (and potentially other values) topic: server, web admin ___________________________________________________ Kolab issue tracker ___________________________________________________ From wrobel at pardus.de Sun Apr 19 11:12:49 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Sun, 19 Apr 2009 11:12:49 +0200 Subject: [Kolab-devel] thomas: server/patches/cyrus-imapd/cyrus-imapd-2.3.13 KOLAB_cyrus-imapd-2.3.13_Groups2.patch, 1.1.2.1, 1.1.2.2 In-Reply-To: <20090406144837.7AC0C60082F@lists.intevation.de> References: <20090406144837.7AC0C60082F@lists.intevation.de> Message-ID: <20090419111249.187956qd3sxsup8o@webmail.pardus.de> Quoting cvs at kolab.org: > Author: thomas > > Update of /kolabrepository/server/patches/cyrus-imapd/cyrus-imapd-2.3.13 > In directory doto:/tmp/cvs-serv25163/cyrus-imapd-2.3.13 > > Modified Files: > Tag: kolab_2_2_branch > KOLAB_cyrus-imapd-2.3.13_Groups2.patch > Log Message: > Forgotten commit for "Final changes for kolab/issue2535: use strcasecmp ..." > > Having the imapd patches outside the imapd directory just calls for > mistakes like this one ... I don't care too much for the "patches" directory. It helps in clarifying which upstream packages need patches. But on the other hand I also see an advantage in having patches within the package directory (which I actually also do within the Kolab_* packages). And somebody trying to port the OpenPKG server to another platform will have to take a close look at the package definitions anyhow. I would like to keep the general structure though and keep track of the patches for each of the available upstream versions. I think this is vital information for native ports. Cheers, Gunnar > > > Index: KOLAB_cyrus-imapd-2.3.13_Groups2.patch > =================================================================== > RCS file: > /kolabrepository/server/patches/cyrus-imapd/cyrus-imapd-2.3.13/KOLAB_cyrus-imapd-2.3.13_Groups2.patch,v > retrieving revision 1.1.2.1 > retrieving revision 1.1.2.2 > diff -u -d -r1.1.2.1 -r1.1.2.2 > --- KOLAB_cyrus-imapd-2.3.13_Groups2.patch 1 Apr 2009 17:03:45 -0000 1.1.2.1 > +++ KOLAB_cyrus-imapd-2.3.13_Groups2.patch 6 Apr 2009 14:48:35 -0000 1.1.2.2 > @@ -148,7 +148,7 @@ > + if (!groupfile) groupfile = fopen("/etc/group", "r"); > + if (groupfile) { > + while ((grp = fgetgrent(groupfile))) { > -+ if (strcmp(grp->gr_name, name) == 0) { > ++ if (strcasecmp(grp->gr_name, name) == 0) { > + fclose(groupfile); > + return grp; > + } > @@ -207,7 +207,7 @@ > + if (groupfile) { > + while ((grp = fgetgrent(groupfile))) { > + for (mem = grp->gr_mem; *mem; mem++) { > -+ if (!strcmp(*mem, identifier)) break; > ++ if (!strcasecmp(*mem, identifier)) break; > + } > > - if (*mem || (pwd && pwd->pw_gid == grp->gr_gid)) { > > > _______________________________________________ > Kolab-commits mailing list > Kolab-commits at kolab.org > https://kolab.org/mailman/listinfo/kolab-commits > -- ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090419/30a8199e/attachment-0001.bin From bernhard at intevation.de Mon Apr 20 09:19:55 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 20 Apr 2009 09:19:55 +0200 Subject: [Kolab-devel] PHP LDAP library moved to Horde 4 In-Reply-To: <20090417221113.15493wy8fgvzl02s@webmail.pardus.de> References: <20090417221113.15493wy8fgvzl02s@webmail.pardus.de> Message-ID: <200904200919.56288.bernhard@intevation.de> Gunnar, thanks for the report. (I think you should also link it wrong a wiki overview page.) Am Freitag, 17. April 2009 22:11:13 schrieb Gunnar Wrobel: > All this concludes the migration path from the initial situation where ? > we had LDAP specific code in the Kolab resource management, the Kolab ? > free/busy system, the Kolab web admin as well as the Kolab web client. ? > All subsystems can now use a central component that will hopefully ? > allow us to adapt the code more easily to long overdue LDAP schema ? > changes (such as the cn=... -> mail=... problem) without needing to ? > code in many places at the same time. > > I also started on a very thin application layer on top of Kolab_Server ? > that might at some point replace the Kolab web admin. The application ? > is called "koward" and lives here: > > http://cvs.horde.org/koward/?rt=horde-hatchery Uh, the name somehow is a drag in several respect.... :) > Any input on things you always wished for in the Kolab web admin would ? > be of interest. I know there have been some Kolab web admin changes ? > under discussion on this list recently and I hope to be able to take ? > them into account early on during the development process. The tracker has a lot of detailed and unsorted things. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090420/7218b911/attachment.bin From kolab-issues at intevation.de Mon Apr 20 09:40:56 2009 From: kolab-issues at intevation.de (Thomas Ribbrock) Date: Mon, 20 Apr 2009 07:40:56 +0000 Subject: [Kolab-devel] [issue3571] Upgrade to newer apache version or backport fix for Apache bug 39243 Message-ID: <1240213256.63.0.774817468722.issue3571@intevation.de> New submission from Thomas Ribbrock : As we are using client certificates in conjunction with Kolab 2.2.0, we ran into Apache bug 39243 (see: https://issues.apache.org/bugzilla/show_bug.cgi?id=39243 ). In our case, the problem occurred with Squirrelmail - I have not yet seen it with Horde. Apparently, a fix/new configuration option has been provided for Apache 2.3 which is not included in Kolab 2.2.[01]. Hence the wish to upgrade to that version or alternatively consider backporting the patch to Apache 2.2. Note: The discussion of above bug also lists a potential workaround (placing the client verification in a different context in the apache config), which we have applied and which *seems* to work so far. So, this wish is probably not top-priority. ---------- messages: 19739 nosy: itsef_admin priority: wish status: unread title: Upgrade to newer apache version or backport fix for Apache bug 39243 topic: server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 20 11:55:02 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 20 Apr 2009 09:55:02 +0000 Subject: [Kolab-devel] [issue3572] Selection of a contact with two email addresses opens a select email dialog twice Message-ID: <1240221302.46.0.251625173625.issue3572@intevation.de> New submission from Ludwig Reiter : enterprise4 20090410.951807 Test: 1. Switch to contact plugin. 2. Create a new contact with two email adresses. 3. Select this new contact. => The user is asked to select a mail address twice. I expect that this dialog doesn't appear. I don't see any reason for this dialog. ---------- assignedto: allen messages: 19745 nosy: allen, bh, ludwig priority: bug status: unread title: Selection of a contact with two email addresses opens a select email dialog twice topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 20 12:02:39 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 20 Apr 2009 10:02:39 +0000 Subject: [Kolab-devel] [issue3573] The todo plugin shows the monthview, a description area and the resources on the left side. Message-ID: <1240221758.86.0.223235572289.issue3573@intevation.de> New submission from Ludwig Reiter : enterprise4 20090410.951807 Test: 1. Switch to the todo plugin => On the left side of the view is the month view of the calendar, a description area and the resource list. I don't expect this areas to appear in the todo plugin. Screenshot: todos-20090420.png ---------- assignedto: allen files: todos-20090420.png messages: 19746 nosy: allen, bh, ludwig priority: bug status: unread title: The todo plugin shows the monthview, a description area and the resources on the left side. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: todos-20090420.png Type: image/png Size: 33009 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090420/898b9052/todos-20090420-0001.png From kolab-issues at intevation.de Mon Apr 20 12:07:36 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 20 Apr 2009 10:07:36 +0000 Subject: [Kolab-devel] [issue3574] Deleted todos reappear after switching to the calendar plugin and back Message-ID: <1240222056.35.0.0678938354711.issue3574@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090410.951807 Test: 1. Switch to todos plugin. 2. Create a new todo. 3. Sync. 4. Delete this todo. 5. Switch to the calendar plugin and back to the todos plugin. => The deleted todo reappear. This is a wrong behaviour. A deleted todo shouldn't reappear. ---------- assignedto: allen messages: 19748 nosy: allen, bh, ludwig priority: urgent status: unread title: Deleted todos reappear after switching to the calendar plugin and back topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 20 12:44:33 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 20 Apr 2009 10:44:33 +0000 Subject: [Kolab-devel] [issue3575] Spellchecking doesn't work because of a missing dictionary Message-ID: <1240224273.69.0.985550061445.issue3575@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090410.951807 Test: 1. Start to create a new mail. 2. Activate Spellchecking. 3. Enter "xhjakkt" in the composer text field. => "xhjakkt" seems to be a right word. I expect that this nonsense word is underlined in red. The output says: 00000056 127.30262756 [652] Critical:kontact(652): No language dictionaries for the language : "de" so I suppose the dictiionary files are missing. Perhaps this is a packaging problem(?). ---------- assignedto: allen messages: 19751 nosy: allen, bh, ludwig priority: bug status: unread title: Spellchecking doesn't work because of a missing dictionary topic: kde client, kpilot ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 20 14:45:50 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Mon, 20 Apr 2009 12:45:50 +0000 Subject: [Kolab-devel] [issue3576] Crash in MonthViewItem::paint when switching to monthly calendar view Message-ID: <1240231550.42.0.734826676763.issue3576@intevation.de> New submission from Bernhard Reiter : Switching to monthly view of the calendar crashes Architecture: i386 Source: kdepim Version: 4:3.5.10.enterprise.0.20090410.951814-kk1 Because of #8 0xf54bdf30 in MonthViewItem::catColor (this=0xa0bef40) at komonthview.cpp:219 #9 0xf54bf961 in MonthViewItem::paint (this=0xa0bef40, p=0xff993a1c) at komonthview.cpp:254 I believe this might be a regression caused by the attempts to fix the color settings. E.g. kolab/issue2472 ("Default event color" is not used) ---------- assignedto: allen messages: 19755 nosy: allen, bernhard, ludwig, till priority: critical status: unread title: Crash in MonthViewItem::paint when switching to monthly calendar view topic: kde client, prokde35 ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 20 19:05:31 2009 From: kolab-issues at intevation.de (Bernhard Herzog) Date: Mon, 20 Apr 2009 17:05:31 +0000 Subject: [Kolab-devel] [issue3578] Unexpected crypto operations when sending non-crypto mail Message-ID: <1240247131.29.0.72402765834.issue3578@intevation.de> New submission from Bernhard Herzog : Kontact version enterprise35 20090313.938853: when sending an email and no encryption or signature has been requested, Kontact does some crypto-backend operations (gpgsm, dirmngr, gpg-agent) when the email is sent. Automatic signing of messages has been disabled in the settings dialog ("E-Mail/Security/Composing/Automatically sign messages" is not checked). Why does it do this? A problem with this is that in some cases this unexpectedly blocks Kontact completely, e.g. in the situation described in this gnupg issues: https://bugs.g10code.com/gnupg/issue999 . One would think that as a workaround, not doing any crypto-operations would avoid such lockups, but since Kontact seems to always do some crypto-operations when sending email that doesn't work. ---------- assignedto: allen messages: 19770 nosy: allen, bernhard, bh, ludwig, till priority: urgent status: unread title: Unexpected crypto operations when sending non-crypto mail topic: enterprise35, kkc ___________________________________________________ Kolab issue tracker ___________________________________________________ From mailinglists at frank-zapfl.de Mon Apr 20 22:55:18 2009 From: mailinglists at frank-zapfl.de (Martin Zapfl) Date: Mon, 20 Apr 2009 22:55:18 +0200 Subject: [Kolab-devel] custom Kolab 2.2 patch adding new features for ISP functionality In-Reply-To: <20090419064140.106052cjarztcx44@webmail.pardus.de> References: <200903091648.18160.mailinglists@tbits.net> <20090419064140.106052cjarztcx44@webmail.pardus.de> Message-ID: <1087908698.20090420225518@frank-zapfl.de> Sunday, April 19, 2009, 6:41:40 AM, you wrote: > Hi Martin! > Quoting Martin Zapfl : >> Hi there, >> >> we did some enhancements to Kolab Webamin. > Cool, thanks for contributing them. >> This patch is applied to Kolab version 2.2 >> It adds a lot of new features mostly used in ISP environments. >> >> Most import changes are: >> - Mange customers >> - Prefixes can be used to set UIDs >> - Each customers data is stored in a separate LDAP subtree >> - Each customer can have its own users, address book, shared folders or >> distribution lists >> - Set maximum number of accounts, domain and default quotas >> - Set password security and view customer password information page >> - Groupware can be disabled for single customers > I think this should be > https://www.intevation.de/roundup/kolab/issue2207 > Is that correct? No, this feature reduces the number of fields for users. If groupware is disabled for a customer only the fields - Name - Password - E-Mail Address - UID - Home Server - e-Mail Aliases - User Quota are shown >> - Assign domain administrators to a customer >> - Show usage of users IMAP accounts >> - Users can enable vacation and e-mail forwarding at the same time >> - restrict login in webadmin only to UID and deny E-Mail address login >> >> You may want to take a look at it: >> https://www.intevation.de/roundup/kolab/issue3463 >> >> This is still a beta release. Do not install it on production machines!! >> We are looking forward for your feedback. > As Martin wrote in the issue it would be really good to provide the > feature additions in different issues with one patch per feature. I > looked at the large patch and I'm pretty certain we won't immediately > apply it as a whole. As you saw there will probably discussions > concerning the one or the other point. So this would make it a lot > easier to go through the features together. > As I'm currently working on Kolab_Server and started on a potential > replacement for the Kolab webadmin I'd be interested in taking your > feature additions into consideration at an early timepoint. > Kolab_Server is the PHP LDAP library we use in the web client, the > resource manager and the free/busy system. The Kolab web admin did not > use the same library as it requires way more LDAP functionality than > the other systems. And this has been only added now to Kolab_Server. > The new library has automatic schema analysis support which might > benefit your needs. The replacement for kolab webadmin is already now > able to display new attributes in the forms once they have been > defined in the schema. This has been a lot more difficult in the kolab > web admin. That sounds pretty interesting. Currently we are splitting the patch into feature-separated single patches. We will release them step by step in the tracker. As Martin supposed we will start with the patch for the kolab ldap schema. > Cheers, > Gunnar >> >> best regards >> Martin Zapfl >> >> _______________________________________________ >> Kolab-devel mailing list >> Kolab-devel at kolab.org >> https://kolab.org/mailman/listinfo/kolab-devel >> -- Best regards, Martin mailto:mailinglists at frank-zapfl.de From mailinglists at frank-zapfl.de Mon Apr 20 22:57:24 2009 From: mailinglists at frank-zapfl.de (Martin Zapfl) Date: Mon, 20 Apr 2009 22:57:24 +0200 Subject: [Kolab-devel] custom Kolab 2.2 patch adding new features for ISP functionality In-Reply-To: <20090419072653.62919btiskw6a3hc@webmail.pardus.de> References: <200903091648.18160.mailinglists@tbits.net> <20090310151530.GA21918@xs4all.nl> <200903102019.06564.martin.konold@erfrakon.de> <200903121551.22377.mailinglists@tbits.net> <20090419072653.62919btiskw6a3hc@webmail.pardus.de> Message-ID: <1644751020.20090420225724@frank-zapfl.de> Sunday, April 19, 2009, 7:26:53 AM, you wrote: > Hi Martin, > Quoting Martin Zapfl : >> Hi Martin, >> >> slapo-ppolicy sounds pretty interesting. I just took a look at it. I have to >> check some internal questions and will tell you if we are willing to code the >> feature. > just as a note: It is very likely that support for this will get added > very soon into the Kolab_Server library > (http://pear.horde.org/index.php?package=Kolab_Server). So there is > probably no need for action from your side. I'll keep the issue up to > date. Thanks for the notice. We were just thinking about coding this feature. But now we will focus on creating the feature patches :-) > Cheers, > Gunnar >> >> best regards >> Martin >> >> On Tuesday 10 March 2009 08:19:05 pm Martin Konold wrote: >>> Am Dienstag, 10. M?rz 2009 16:15:30 schrieb Richard Bos: >>> > On Tue, Mar 10, 2009 at 02:26:15PM +0100, Martin Konold wrote: >>> > > Am Dienstag, 10. M??rz 2009 13:56:24 schrieb Martin Zapfl: >>> > > >>> > > Hi Martin, >>> > > >>> > > > > So the idea is that it is easier to guess the email address than >>> > > > > the uid which is supposed to provide extra security? >>> > > > >>> > > > Yes, the idea is to protect users with a weak password. >>> > > >>> > > I consider it a valid requirement to protect users from weak passwords. >>> > > >>> > > IMHO Kolab should support this. >>> > >>> > Isn't this already requested and covered in issue: >>> > https://www.intevation.de/roundup/kolab/issue3025 >>> >>> Yes, it is already covered there. >>> >>> I already proposed the same solution back then but nobody took the effort >>> of actually integrating this option. No big coding is required because the >>> feature is already part of OpenLDAP since a while. It is mainly an >>> integration task so that it is setup with reasonable defaults, documented >>> and >>> configurable. >>> >>> Yours, >>> -- martin >> >> >> _______________________________________________ >> Kolab-devel mailing list >> Kolab-devel at kolab.org >> https://kolab.org/mailman/listinfo/kolab-devel >> -- Best regards, Martin mailto:mailinglists at frank-zapfl.de From kolab-issues at intevation.de Thu Apr 2 15:15:33 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Thu, 02 Apr 2009 13:15:33 -0000 Subject: [Kolab-devel] [issue3530] The umlauts in the German message of "This message is encrypted" is broken. Message-ID: <1238678128.82.0.0738804439677.issue3530@intevation.de> New submission from Ludwig Reiter : enterprise4 windows tag 20090313.938844 The German messages "Die Nachricht ist verschl?sselt" und "Nachricht entschl?sseln" display the umlaut "?" in a wrong way. Test: 1. Another user sends a openpgp encrypted mail to the user. 2. He look at the mail. I expect that the "?" is displayed correct. Screenshot: encryption-message-20090402.png ---------- assignedto: allen files: encryption-message-20090402.png messages: 19441 nosy: allen, bh, ludwig priority: bug status: unread title: The umlauts in the German message of "This message is encrypted" is broken. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: encryption-message-20090402.png Type: image/png Size: 44982 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090402/21709cb9/encryption-message-20090402-0001.png From kolab-issues at intevation.de Thu Apr 2 16:13:22 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Thu, 02 Apr 2009 14:13:22 -0000 Subject: [Kolab-devel] [issue3531] Reminder trigger time is incorrect. Message-ID: <1238681597.99.0.9070670722.issue3531@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090313.938844 The trigger date/time of a reminded event is wrong. Screenshot: reminder-20090402.png Trigger time is 14:03, but it is 16:03 at the moment. Perhaps here it is in UTC time displayed. I expect it to be displayed in local time. ---------- assignedto: allen files: reminder-20090402.png messages: 19446 nosy: allen, bh, ludwig priority: bug status: unread title: Reminder trigger time is incorrect. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: reminder-20090402.png Type: image/png Size: 87324 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090402/c934b17f/reminder-20090402-0001.png From kolab-issues at intevation.de Mon Apr 20 15:28:26 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Mon, 20 Apr 2009 13:28:26 +0000 Subject: [Kolab-devel] [issue3577] S/MIME opaque signed and encrypted email without smime-type parameter suboptimal display Message-ID: <1240234106.62.0.355832695257.issue3577@intevation.de> New submission from Bernhard Reiter : An opaque signed and encrypted S/MIME which has not been decrypted and misses the smime-type=enveloped-data parameter looks like ---------- | This msg is encrypted ---------- | Signature could not be checked | XYXYXXYXX |---------- see kontact-e35-20090420-2.png Correct would be to not have the "signature" part. This is related to kolab/issue2183 (Kontact shows misleading error messages if smime-type is missing in Content-Type header) ---------- assignedto: allen files: kontact-e35-20090420-2.png messages: 19757 nosy: allen, bernhard, bh, ludwig, marc, till priority: bug status: unread title: S/MIME opaque signed and encrypted email without smime-type parameter suboptimal display topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: kontact-e35-20090420-2.png Type: image/png Size: 52761 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090420/834584ed/kontact-e35-20090420-2-0001.png From kolab-issues at intevation.de Wed Apr 22 18:40:01 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Wed, 22 Apr 2009 16:40:01 +0000 Subject: [Kolab-devel] [issue3579] Open email composer windows discarded after a few restarts (email loss) Message-ID: <1240418401.02.0.150471622141.issue3579@intevation.de> New submission from Bernhard Reiter : Open an email composer, write a few lines. Stop and restart contact. After the first time the open window comes up again. After a few restarts the window is discarded. This should not happen. Please always keep the windows indefinately (and make that default if you find a reason why it should be discarded). ---------- assignedto: allen messages: 19808 nosy: allen, bernhard, ludwig, till priority: bug status: unread title: Open email composer windows discarded after a few restarts (email loss) topic: kde client, kowi, prokde35 ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Wed Apr 22 21:22:47 2009 From: kolab-issues at intevation.de (Julian G) Date: Wed, 22 Apr 2009 19:22:47 +0000 Subject: [Kolab-devel] [issue3580] Make LDAP multidomain usable Message-ID: <1240428167.61.0.767429241881.issue3580@intevation.de> New submission from Julian G : Change LDAP hierarchy to: Kolab-Server -> Domain -> Accounts and other Items Combined with LDAP authentication and matching rules in LDAP configuration users would be able to use LDAP address book on items belonging to their domain as branch as part of the LDAP tree. ---------- messages: 19812 nosy: glua priority: wish status: unread title: Make LDAP multidomain usable ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 23 16:37:16 2009 From: kolab-issues at intevation.de (Sascha Wilde) Date: Thu, 23 Apr 2009 14:37:16 +0000 Subject: [Kolab-devel] [issue3581] Inconsistent and inflexible handling of event creators Message-ID: <1240497436.31.0.535311670871.issue3581@intevation.de> New submission from Sascha Wilde : When creating an event in the Kolab Web Client and adding attendees the creator (the user creation the event) is always shown as required attendee. Despite that, the creator is _not_ automatically added as attendee to the actual event, so the view off the creator on the attendees list differs form the view of all other attendees. It is possible for the creator to explicitly add him one self to the attendee list but in this case the creator is shown _twice_ in the "Edit attendees" dialog, and when the "Attendance" attribute is changed to "optional" the user is shown both, as "Required Attendee" and as "Optional Attendee" -- this is highly confusing to users. ---------- assignedto: wrobel messages: 19819 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: Inconsistent and inflexible handling of event creators topic: web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Thu Apr 23 20:43:32 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Thu, 23 Apr 2009 18:43:32 +0000 Subject: [Kolab-devel] [issue3582] Kontact/Win errors with too long/reserved file names Message-ID: <1240512212.8.0.74596494042.issue3582@intevation.de> New submission from Albrecht Dre? : I got errors using Kontact/Win beta 20090313 when the application tried to access a shared folder with a deep tree and long folder names. The process reported the attached errors (upper first, lower after clicking ok). The "offending" file name is apparently "C:\Dokumente und Einstellungen\adress\.kde\share\apps\kmail\dimap\.23250.directory\.user.directory\.support.directory\._Controller.directory\.OTS.directory\.__offeneFaelle.directory\Prime Optical Fiber Corp._Taiwan City sewage plant_Datenbank Probleme.directory" which exceeds Win's MAX_PATH limit. As Thomas Arendsen Hein pointed out in the mailing list, some "reserved" names will also trigger errors (he provided as reference). A possible solution could be some kind of "flattened" tree on Win32, with an extra look-up table translating the real (deep) IMAP paths into, say, a MD5 hash which can then safely be used as folder name. ---------- files: long-path-err.png messages: 19821 nosy: albrecht.dress priority: urgent status: unread title: Kontact/Win errors with too long/reserved file names ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: long-path-err.png Type: image/png Size: 24750 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090423/54b1d54d/long-path-err-0001.png From wrobel at pardus.de Thu Apr 23 23:55:56 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 23 Apr 2009 23:55:56 +0200 Subject: [Kolab-devel] Patches for cyrus imapd 2.3.14 (was: Re: thomas: server/patches/cyrus-imapd/cyrus-imapd-2.3.13 KOLAB_cyrus-imapd-2.3.13_Groups2.patch, 1.1.2.1, 1.1.2.2) In-Reply-To: <20090419111249.187956qd3sxsup8o@webmail.pardus.de> References: <20090406144837.7AC0C60082F@lists.intevation.de> <20090419111249.187956qd3sxsup8o@webmail.pardus.de> Message-ID: <20090423235556.202726oxqw3d1wjo@webmail.pardus.de> Quoting Gunnar Wrobel : > Quoting cvs at kolab.org: > >> Author: thomas >> >> Update of /kolabrepository/server/patches/cyrus-imapd/cyrus-imapd-2.3.13 >> In directory doto:/tmp/cvs-serv25163/cyrus-imapd-2.3.13 >> >> Modified Files: >> Tag: kolab_2_2_branch >> KOLAB_cyrus-imapd-2.3.13_Groups2.patch >> Log Message: >> Forgotten commit for "Final changes for kolab/issue2535: use strcasecmp ..." >> >> Having the imapd patches outside the imapd directory just calls for >> mistakes like this one ... > > I don't care too much for the "patches" directory. It helps in > clarifying which upstream packages need patches. But on the other > hand I also see an advantage in having patches within the package > directory (which I actually also do within the Kolab_* packages). > And somebody trying to port the OpenPKG server to another platform > will have to take a close look at the package definitions anyhow. > > I would like to keep the general structure though and keep track of > the patches for each of the available upstream versions. I think > this is vital information for native ports. @thomas: I still had stuff open to merge from the 2_2 branch of the imapd package which I did now. In addition I moved the whole patches directory for cyrus-imapd into the imapd package. I kept the basic structure to cope with different version numbers and ensure that old patch versions are retained. I consider this important for the native distributions that might not use the same version as we do on OpenPKG. I also converted the manual procedure I use to care for the cyrus imapd patch series into a Makefile. Mercurial is required to run that Makefile. It should try to automatically update the patch series to a new version. Conflict resolution when pushing the patch series on the new version is of course left to the programmer. The Makefile has been used to generate the patches for cyrus-imapd-2.3.14. One conflict was resolved manually. I was somehow unable to fetch the imapd-2.3.14-RPM from OpenPKG. So the package has not been updated to this newer version. Please take a look at the changes and comment. Cheers, Gunnar > > Cheers, > > Gunnar > >> >> >> Index: KOLAB_cyrus-imapd-2.3.13_Groups2.patch >> =================================================================== >> RCS file: >> /kolabrepository/server/patches/cyrus-imapd/cyrus-imapd-2.3.13/KOLAB_cyrus-imapd-2.3.13_Groups2.patch,v >> retrieving revision 1.1.2.1 >> retrieving revision 1.1.2.2 >> diff -u -d -r1.1.2.1 -r1.1.2.2 >> --- KOLAB_cyrus-imapd-2.3.13_Groups2.patch 1 Apr 2009 17:03:45 -0000 1.1.2.1 >> +++ KOLAB_cyrus-imapd-2.3.13_Groups2.patch 6 Apr 2009 14:48:35 -0000 1.1.2.2 >> @@ -148,7 +148,7 @@ >> + if (!groupfile) groupfile = fopen("/etc/group", "r"); >> + if (groupfile) { >> + while ((grp = fgetgrent(groupfile))) { >> -+ if (strcmp(grp->gr_name, name) == 0) { >> ++ if (strcasecmp(grp->gr_name, name) == 0) { >> + fclose(groupfile); >> + return grp; >> + } >> @@ -207,7 +207,7 @@ >> + if (groupfile) { >> + while ((grp = fgetgrent(groupfile))) { >> + for (mem = grp->gr_mem; *mem; mem++) { >> -+ if (!strcmp(*mem, identifier)) break; >> ++ if (!strcasecmp(*mem, identifier)) break; >> + } >> >> - if (*mem || (pwd && pwd->pw_gid == grp->gr_gid)) { >> >> >> _______________________________________________ >> Kolab-commits mailing list >> Kolab-commits at kolab.org >> https://kolab.org/mailman/listinfo/kolab-commits >> > > > > -- > ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ > > E-mail : p at rdus.de Dr. Gunnar Wrobel > Tel. : +49 700 6245 0000 Bundesstrasse 29 > Fax : +49 721 1513 52322 D-20146 Hamburg > -------------------------------------------------------------------- > >> Mail at ease - Rent a kolab groupware server at p at rdus << > -------------------------------------------------------------------- > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > -- ______ http://kdab.com _______________ http://kolab-konsortium.com _ p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090423/590b2680/attachment.bin From kolab-issues at intevation.de Fri Apr 24 11:09:34 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Fri, 24 Apr 2009 09:09:34 +0000 Subject: [Kolab-devel] [issue3583] offline s/mime signing without CRL for secret key gives unkown system error Message-ID: <1240564173.9.0.499286307973.issue3583@intevation.de> New submission from Bernhard Reiter : Architecture: powerpc Source: gnupg2 Version: 2.0.11-1kk1 Source: gpgme1.0 Version: 1.1.8-0kk1 Source: kdepim Version: 4:4.1.1.enterprise4.0.20090306.935937-kk1 Package: dirmngr Version: 1.0.1-3 Getting "Unknown System error", but the command line LANG=C gpgsm --with-validation --list-secret-keys still lists three secret keys, but Kontact does not in the identity nor the selection dialog for the identify. E.g. ID: 0x46C65E78 S/N: 06 Issuer: /CN=ZS 8/O=Intevation GmbH/C=DE Subject: /CN=Bernhard Reiter/O=Intevation GmbH/C=DE aka: bernhard at intevation.de validity: 2008-06-19 08:43:25 through 2010-06-19 08:43:25 key type: 2048 bit RSA fingerprint: 9C:F8:E2:A0:0B:1E:E4:BF:02:66:2A:69:3B:85:F7:4F:46:C6:5E:78 [the status of the certificate is unknown] [validation model used: shell] [certificate is bad: No CRL known] with Debian Lenny's python-pyme and testCMSgetkey.py v20080813: python testCMSgetkey.py 9C:F8:E2:A0:0B:1E:E4:BF:02:66:2A:69:3B:85:F7:4F:46:C6:5E:78 pyme.errors.GPGMEError: GPGME: End of file (7,16383) Looks like a crypto backend problem. Even so I hopen a report here to document the problem. Next steps: report to g10code. ---------- assignedto: bernhard messages: 19829 nosy: allen, bernhard, ludwig, marc, till priority: bug status: unread title: offline s/mime signing without CRL for secret key gives unkown system error topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From thomas at intevation.de Fri Apr 24 16:07:53 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Fri, 24 Apr 2009 16:07:53 +0200 Subject: [Kolab-devel] TODO list for Kolab Server 2.2.2 Message-ID: <20090424140753.GB28971.thomas@intevation.de> Hi! I've marked all issues that have to be fixed for Kolab Server 2.2.2 as critical: Gunnar: kolab/issue3568 (umlauts broken in automatically accepted events) kolab/issue3521 (kolabmailboxfilter does not accept mail for user+extension at example.com) Thomas: kolab/issue3513 (Clamav - new upstream version 0.95.1) kolab/issue3549 (append_dot_mydomain allows circumventing kolabfilter-verify-from-header) I think I can be easily convinced to include further fixes if the needed changes are small and indisputable. 2.2.2 should be published soon, probably in the first half of May. Regards, Thomas Arendsen Hein -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090424/c3fff606/attachment.bin From kolab-issues at intevation.de Sun Apr 26 13:52:36 2009 From: kolab-issues at intevation.de (Gunnar Wrobel) Date: Sun, 26 Apr 2009 11:52:36 +0000 Subject: [Kolab-devel] [merge86] Correction for Shared Folder Owners with Dovecot Message-ID: <1240746756.27.0.665526396489.merge86@intevation.de> New submission from Gunnar Wrobel

: This patch has not yet been merged upstream: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php-kolab/Kolab_Storage/t_framework_HK_SW_Kolab__Storage_DovecotSharedFolderOwner.patch Please add a description within the patch about what it intends to do as I don't have a dovecot installation aroung. If possible a unit test would be nice. Though not absolutely required ;) ---------- assignedto: wilde messages: 19858 nosy: thomas, wilde, wrobel priority: normal status: unread title: Correction for Shared Folder Owners with Dovecot upstream: Horde _________________________________________________ Kolab issue tracker _________________________________________________ From kolab-issues at intevation.de Sun Apr 26 14:59:57 2009 From: kolab-issues at intevation.de (Mathieu Parent) Date: Sun, 26 Apr 2009 12:59:57 +0000 Subject: [Kolab-devel] [issue3584] rfc2739 is not copyrightable nor licensable Message-ID: <1240750797.36.0.71965628478.issue3584@intevation.de> New submission from Mathieu Parent : Hi, We currently can't include rfc2739.schema as-is in Debian, because the license is not free. Precisely, this is a small issue because this type of file cannot be copyrighted. I will apply the following patch. Patch: Index: rfc2739.schema =================================================================== RCS file: /kolabrepository/server/kolabd/kolabd/rfc2739.schema,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 rfc2739.schema --- rfc2739.schema 23 Nov 2004 20:26:47 -0000 1.1.1.1 +++ rfc2739.schema 26 Apr 2009 12:53:52 -0000 @@ -1,9 +1,17 @@ -# (c) 2004 Martin Konold - # This schema is derived from RFC 2739 and may act as a substitute # when used with OpenLDAP as the original schema from RFC 2739 # is syntactically not accepted by OpenLDAP 2.2.14 # +# The conversion is from 2004 Martin Konold + +# Apart from short and obvious comments, the text of this file is purely +# a functional interface specification, which is not subject to IETF RFC +# license and is not copyrightable under US law. +# +# The license statement is retained below so as not to remove credit, but +# as best as we can determine, it is not applicable to the contents of +# this file. + # Copyright (C) The Internet Society (2000). All Rights Reserved. # # This document and translations of it may be copied and furnished to ---------- messages: 19859 nosy: martin, mathieu.parent, rbos, thomas, wrobel status: unread title: rfc2739 is not copyrightable nor licensable topic: server ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 27 15:00:43 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Mon, 27 Apr 2009 13:00:43 +0000 Subject: [Kolab-devel] [issue3585] kleopatra: GnuPG-System cannot be configured: Operation not permitted Message-ID: <1240837243.66.0.024737517732.issue3585@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090417.955403 gpg4win-1.9.15-beta It is not possible to configure the GnuPG-System with kleopatra. Test: At a windows user account try: 1. Start kontact 2. Start kleopatra 3. Open the configuration dialog and switch to Gnupg-System->GPG-Agent 4. Set "allow mark trusted" 5. Press on okay. => An error message appears: error in gpgconf while saving the configuration: operation not permitted. I expect that a user can save his configuration. This is a regression, as for the version 20090313.938844 this worked. ---------- assignedto: allen messages: 19876 nosy: allen, bh, ludwig priority: urgent status: unread title: kleopatra: GnuPG-System cannot be configured: Operation not permitted topic: crypto, kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 27 17:55:41 2009 From: kolab-issues at intevation.de (Thomas Arendsen Hein) Date: Mon, 27 Apr 2009 15:55:41 +0000 Subject: [Kolab-devel] [issue3586] number of recurrences/occurrences in format docs misleading Message-ID: <1240847741.19.0.439521194508.issue3586@intevation.de> New submission from Thomas Arendsen Hein : This is probably an issue about misleading Kolab format docs yielding a freebusy and web client implementation differing from the probably correct implementation in kontact, so I added only few kontact people to nosy. Assigning to Bernhard to decide what should be the correct reading, Martin might know, too. Tested with Kolab Server 2.2.1 and Kontact Version 1.2.9 (enterprise35 20090417.955394) (probably applies to enterprise4, too) While testing server freebusy and web client of Kolab Server 2.2.1 I noticed that both behave differently than kontact regarding recurring events with weekly cycle, more than one day of week and limited number of (recurrences|occurrences). When looking at the Kolab Storage Format document 2.0rc7 I think kontact might be the one who is wrong. Example: In kontact create an event, enable recurrence, set recurrence rule to weekly and repeat every week on Mon/Wed/Fri/Sun. Set "Recurrence Range" to "End after 3 occurrence(s)". Now kontact displays this event on three days (e.g. Mon+Wed+Fri), but when looking at the freebusy list or the web client the event lasts three weeks (i.e. on 12 different days). The corresponding event dialog in the web client says: Recurrence: Weekly: Recurs every 1 week(s) on: Mo We Fr Su Recur Until: 3 recurrences The Kolab XML object generated by kontact contains: 1 monday wednesday friday sunday 3 The format specification contains in 4.2.1. Recurrence: | weekly: Interval specifies "every X weeks". Day can be monday, tuesday | wednesday, thursday, friday, saturday, and sunday. There can be 1 to 7 of | these days. | | The range must also be present. This can be "none", which means a never | ending recurrence. Or "number", which specifies the number of times this | recurrence happens (before exclusions are subtracted). To me this reads as if freebusy and web client do it right, because the number of recurrences is specified, not the number of occurrences. But when looking at 4.2.2. Recurrence examples it seems as if kontact does it correctly: | Recurrence weekly on mondays and thursdays, until 5 has happened. No | exclusions: | | | 3 | monday | thursday | 5 | | | Same one, but this time with one exclusion. Note that the actual ending is | the same, meaning in reality only four incidences happened: | | | 3 | monday | thursday | 5 | 2005-05-04 | The "incidences" in this text indicates that the number of occurrences is meant and not the number of repeats of the recurrence section. So my guess is that the format docs have to be clarified and the freebusy and web client code have to be corrected. Important: I did not verify invitations, I saved the event in IMAP and then looked at it by using freebusy URL and web client. So invitations have to be tested, too! ---------- assignedto: bernhard messages: 19885 nosy: allen, bernhard, martin, thomas, till, wilde, wrobel priority: bug status: unread title: number of recurrences/occurrences in format docs misleading topic: format, freebusy, kde client, web client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 27 20:31:20 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Mon, 27 Apr 2009 18:31:20 +0000 Subject: [Kolab-devel] [issue3587] Kontact/Win tool helping w/ mass installation Message-ID: <1240857080.01.0.564199123585.issue3587@intevation.de> New submission from Albrecht Dre? : A tool which helps with the "mass installation" of Kontact/Win would be really helpful. Typically, in a bigger organisation a number of settings have to configured the same on each Win workstation, like server settings, signature and message templates, work hours, etc. etc. Setting them for each and every user is time-consuming. A solution might be an extended Kolabwizard, which looks in the installation folder for a file like, e.g., "kowi-local.ini" as to pre-set more values from it. Any other simplification would of course also be appreciated! ---------- messages: 19887 nosy: albrecht.dress priority: wish status: unread title: Kontact/Win tool helping w/ mass installation topic: enterprise4, kde client, kowi, windows ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Mon Apr 27 20:51:24 2009 From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=) Date: Mon, 27 Apr 2009 18:51:24 +0000 Subject: [Kolab-devel] [issue3588] Kontact/Win: mail folders on different disk/folder Message-ID: <1240858284.47.0.958637883066.issue3588@intevation.de> New submission from Albrecht Dre? : Currently, Kontact/Win stores all messages in the folder (German system) "C:\Dokumente und Einstellungen\\.kde". It would be nice if the local folders could be stored, at least partially, in a different location. Think of a "mail archive" which should live on a different disk, so it is not copied to the server through the roaming profiles mechanism. This is pretty easy on Unix (symlink), but harder on Windows (probably?). There could be an option for a folder to change the physical storage location to something else. Note that there might be some problems related to this: - the folder might just disappear temporarily (archive on external disk, user logged on different workstation with roaming profile); - the folder might be read-only (e.g. archive on a cd). ---------- messages: 19888 nosy: albrecht.dress priority: wish status: unread title: Kontact/Win: mail folders on different disk/folder topic: enterprise4, kde client, kowi, windows ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 28 11:29:22 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Tue, 28 Apr 2009 09:29:22 +0000 Subject: [Kolab-devel] [issue3589] folder view: The column size configuration changes, if a new folder is created Message-ID: <1240910962.05.0.128993676531.issue3589@intevation.de> New submission from Ludwig Reiter : enterprise4 windows 20090417.955403 Test: 1. Start kontact and switch to the mail component. 2. Resize the "folder" column and the "size" column in the folder view. 3. Create a new mail subfolder of the inbox. => The column size of the "folder" and the "size" column changes. I expect, after the creation of a new folder, the column size should stay the same. ---------- assignedto: allen messages: 19895 nosy: allen, bh, ludwig priority: bug status: unread title: folder view: The column size configuration changes, if a new folder is created topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 28 12:59:40 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Tue, 28 Apr 2009 10:59:40 +0000 Subject: [Kolab-devel] [issue3590] Folder context menu button to send and save a new email with properties of this folder Message-ID: <1240916380.58.0.339220089776.issue3590@intevation.de> New submission from Bernhard Reiter : A wish for enhancement of Kontacts Email behaviour: The folder context menu should have an action to open the composer to send a new email which will get saved in the folder. This is related to the "new email to this mailinglist" menu action and the setting "save answers in this folder". The use case is when users are keeping their email categorized in certain subfolders. Let us say all emails to Allen are saved in a folder allen. When replying this is no problem, the answer is saved in the folder if I have the corresponding setting. For a new email, I have to select the send folder manually which is hard if I have a lot of folders. So having a button: "New email with this folders properties" would be nice. IMO this would save the email in the folder. (which is something that could be affected by the "save this answer" setting.) And I also think the identify should be considered. So this button would: check if "save this answer in this folder" property if yes, set the send-folder to this folder if no, use the identify next to set the send-folder So now I can send a new email to Allen, which gets saved in /allen and with my Kolab identify with one menu action. A possible next step would be to make one button/shortcut which either does "new email to this list" or "new email with this folders properties", as I believe this is almost orthogonal. ---------- assignedto: till messages: 19899 nosy: allen, bernhard, till priority: wish status: unread title: Folder context menu button to send and save a new email with properties of this folder topic: enterprise35, enterprise4, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 28 14:32:24 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Tue, 28 Apr 2009 12:32:24 +0000 Subject: [Kolab-devel] [issue3591] Selection of a file contact resource slow, if all(500) contacts are selected Message-ID: <1240921944.36.0.444067003086.issue3591@intevation.de> New submission from Ludwig Reiter : enterprise35 20090417.955394-kk3 Test: Req: A contact kolab resource with about 500 contacts An empty file resource 1. Switch to contacts. 2. Deactivate the file resource 3. Select all contacts with Ctrl+a 4. Activate the file resource. => The user has to wait for a long time while the contacts list is empty. Because the resource is empty I wouldnot expect to wait. ---------- assignedto: allen messages: 19900 nosy: allen, bernhard, bh, ludwig priority: minor bug status: unread title: Selection of a file contact resource slow, if all(500) contacts are selected topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 28 14:38:27 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Tue, 28 Apr 2009 12:38:27 +0000 Subject: [Kolab-devel] [issue3592] List of emails jumps to the middle after selection with certain sizes Message-ID: <1240922307.08.0.232278073978.issue3592@intevation.de> New submission from Bernhard Reiter : Picture an email list above the email "preview" subwindow. I could get into a state where selecting an email make the upper windows jump after a certain delay (maybe half a second). I could reproduce this once (with Till as a witness) with Architecture: powerpc Source: kdepim Version: 4:4.1.1.enterprise4.0.20090306.935937-kk1 kdelibs5_4.1.1.enterprise4.0.20090306.935702-kk1_powerpc Trying to reproduce this today failed on a) kdepim 4:4.1.1.enterprise4.0.20090306.935937-kk1 and kdelibs5_4.1.1.enterprise4.0.20090423.958303-kk1_powerpc and b) Architecture: i386 Source: kdepim Version: 4:4.1.1.enterprise4.0.20090414.953536-kk1 Source: kde4libs Version: 4:4.1.1.enterprise4.0.20090329.946626-kk1 Conclusiong: Might be harder to reproduce or gone with the kdelibs5 change. ---------- assignedto: bernhard messages: 19901 nosy: allen, bernhard, ludwig, till priority: bug status: need-eg title: List of emails jumps to the middle after selection with certain sizes topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From kolab-issues at intevation.de Tue Apr 28 14:55:23 2009 From: kolab-issues at intevation.de (Thomas Ribbrock) Date: Tue, 28 Apr 2009 12:55:23 +0000 Subject: [Kolab-devel] [issue3593] Switching to monthview crashes Kontact Message-ID: <1240923323.72.0.104039577057.issue3593@intevation.de> New submission from Thomas Ribbrock : After upgrading from 938853 to 955394, Kontact started crashing whenever I try to switch to monthview in the calendar. The only other thing I did before switching to monthview was changing the colour for events that have no category. Backtrace attached. Versions: Qt: 3.3.8b KDE: 3.5.10 Kontact: 1.2.9 (enterprise35 20090417.955394) on Kubuntu 8.04. Note: The Kubuntu package I'm using is based on the kdepim_3.5.10.enterprise.0.20090417.955394-kk3 package - as far as I could see, some additional patches seem to be present for issue2472 and issue3576. From "changelog": kdepim (4:3.5.10.enterprise.0.20090417.955394-kk3) unstable; urgency=low * Patched with diff r956733:956734 to solve kolab/issue3576 -- Ludwig Reiter Fri, 24 Apr 2009 16:30:09 +0200 kdepim (4:3.5.10.enterprise.0.20090417.955394-kk2) unstable; urgency=low * Patched with diff r957261:957262 to solve kolab/issue2472 -- Ludwig Reiter Wed, 22 Apr 2009 12:45:55 +0200 ---------- files: Crash_on_switching_to_monthview-955394.txt messages: 19904 nosy: itsef_admin priority: urgent status: unread title: Switching to monthview crashes Kontact topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Crash_on_switching_to_monthview-955394.txt Url: http://kolab.org/pipermail/kolab-devel/attachments/20090428/bce167c4/Crash_on_switching_to_monthview-955394.txt From bh at intevation.de Tue Apr 28 20:08:07 2009 From: bh at intevation.de (Bernhard Herzog) Date: Tue, 28 Apr 2009 20:08:07 +0200 Subject: [Kolab-devel] Automatically built KDEPIM packages now published on files.kolab.org Message-ID: <200904282008.16616.bh@intevation.de> Hi all, for quite some time now we've automatically built Debian packages of the Enterprise versions of KDEPIM. Some of the packages were made available on apt.intevation.org. We've automated the build system a bit more, and the newest automatically built packages are now available on files.kolab.org. IMPORTANT: These are packages are automatically built from SVN development snapshots and have seen no quality-control whatsoever. They are useful for testing but are NOT usable for production use. /etc/apt/sources.list configuration For the KDPIM packages for Debian Lenny from the enterprise4 branch, use deb http://files.kolab.org/apt/snapshots lenny kdepim-enterprise4 For the enterprise35 branch for Debian Etch, use deb http://files.kolab.org/apt/snapshots etch kdepim-enterprise35 deb http://apt.intevation.org etch unstable The enterprise35 packages need some crypto packages from http://apt.intevation.org. Overview of the build status: Reports about the status of these builds is are published on these web pages: http://saegewerk.wald.intevation.org/kdepim-enterprise4-lenny/index.html http://saegewerk.wald.intevation.org/kdepim-enterprise35-etch/index.html Bernhard -- Bernhard Herzog | ++49-541-335 08 30 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090428/669638b5/attachment.bin From kolab-issues at intevation.de Wed Apr 29 08:55:01 2009 From: kolab-issues at intevation.de (jean-pierre cartal) Date: Wed, 29 Apr 2009 06:55:01 +0000 Subject: [Kolab-devel] [issue3594] Mail not delivered, error in Kolab Filter Message-ID: <1240988101.08.0.456805498615.issue3594@intevation.de> New submission from jean-pierre cartal : Hi, I've upgraded my Kolab server to the latest 2.2.0 version but I have problem with specific messages coming from a specific server. I have several Linux servers that are running Logwatch each night and sending the result to a distribution list handled by Kolab. But for an unknown reason one of my server's report never get delivered. I found the following errors in the logs : * in postfix logs : relay=kolabmailboxfilter, delay=2.1, delays=0.42/0.01/0/1.6, dsn=4.3.0, status=deferred (temporary failure. Command output: Invalid response code received from server, original code ) * in kolab-filter/log/filter.log : Kolab Filter [error] [horde] Invalid response code received from server, original code ; Code: 459 [on line 266 of "/var/kolab/lib/php/Horde/Kolab/Filter/Transport.php"] Until the mail is finally deleted a few days later since it could not be delivered. I've made a few tests : * All other servers logwatch reports get delivered using the same alias. * Mail sent from the problematic server to its root user account are delivered properly to the intended alias. Does anybody have an idea of what could be causing this problem or how I could get more information from the kolab filter to diagnose this issue ? Regards. ---------- messages: 19915 nosy: jpcartal priority: urgent status: unread title: Mail not delivered, error in Kolab Filter ___________________________________________________ Kolab issue tracker ___________________________________________________ From math.parent at gmail.com Wed Apr 29 09:51:01 2009 From: math.parent at gmail.com (Mathieu Parent) Date: Wed, 29 Apr 2009 09:51:01 +0200 Subject: [Kolab-devel] Automatically built KDEPIM packages now published on files.kolab.org In-Reply-To: <200904282008.16616.bh@intevation.de> References: <200904282008.16616.bh@intevation.de> Message-ID: <960738410904290051w5df59e91s1bc51f5e26eb1272@mail.gmail.com> Hi, On Tue, Apr 28, 2009 at 8:08 PM, Bernhard Herzog wrote: > Hi all, > > for quite some time now we've automatically built Debian packages of the > Enterprise versions of KDEPIM. ?Some of the packages were made available on > apt.intevation.org. ?We've automated the build system a bit more, and the > newest automatically built packages are now available on files.kolab.org. > > IMPORTANT: These are packages are automatically built from SVN development > snapshots and have seen no quality-control whatsoever. ?They are useful for > testing but are NOT usable for production use. > ... Great. Thanks for those packages. Might be good to put this on wiki.kolab.org Mathieu Parent From alar.sing at err.ee Wed Apr 29 10:54:25 2009 From: alar.sing at err.ee (Alar Sing) Date: Wed, 29 Apr 2009 11:54:25 +0300 Subject: [Kolab-devel] Kolab_Freebusy pear problem Message-ID: <49F815C1.5040706@err.ee> Hello, There is problem with Kolab_Freebusy 1.5.0 or Kolab_Server 0.5.0 pear package. In file FreeBusy/Cache.php on line 377 there is $groups = $access->user_object->getGroupAddresses(); but on Kolab_Server package there is no Horde_Kolab_Server_Object_user::getGroupAddresses() such method. From kolab-issues at intevation.de Wed Apr 29 11:34:04 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Wed, 29 Apr 2009 09:34:04 +0000 Subject: [Kolab-devel] [issue3595] Online IMAP only shows one single email. Message-ID: <1240997644.8.0.732540016512.issue3595@intevation.de> New submission from Bernhard Reiter : Online IMAP does not seem to work on e4, windows. Also see report http://bugs.kde.org/show_bug.cgi?id=190503 (IMAP just show only one mail) reported with (enterprise4 0.20090313.938844) (using 4.1.4, MinGW 3.4.5). Till told me he is debugging it, so I assume it is reproducable. ---------- assignedto: till messages: 19919 nosy: allen, bernhard, ludwig, till priority: urgent status: unread title: Online IMAP only shows one single email. topic: kde client, kowi ___________________________________________________ Kolab issue tracker ___________________________________________________ From thomas at intevation.de Wed Apr 29 12:32:52 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 29 Apr 2009 12:32:52 +0200 Subject: [Kolab-devel] Kolab_Freebusy pear problem In-Reply-To: <49F815C1.5040706@err.ee> References: <49F815C1.5040706@err.ee> Message-ID: <20090429103252.GC13503.thomas@intevation.de> * Alar Sing [20090429 10:54]: > There is problem with Kolab_Freebusy 1.5.0 or Kolab_Server 0.5.0 pear > package. > In file FreeBusy/Cache.php on line 377 there is > > $groups = $access->user_object->getGroupAddresses(); but on Kolab_Server package there is no Horde_Kolab_Server_Object_user::getGroupAddresses() such method. Please provide more details about your setup. Kolab Server 2.2.1 with OpenPKG contains the packages: Kolab_FreeBusy-0.1.2-20090406 Kolab_Server-0.4.0-20090224 ... so you have something else, but what? Thomas -- thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998 Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From kolab-issues at intevation.de Wed Apr 29 12:51:24 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Wed, 29 Apr 2009 10:51:24 +0000 Subject: [Kolab-devel] [issue3596] Display a special text instead of a Toltec binary invitation email. Message-ID: <1241002284.25.0.189513446225.issue3596@intevation.de> New submission from Bernhard Reiter : KDE Kontact should display a configurable text when encountering a Toltec binary object email in an email folder only. Also this should be configurable. Not yet in kdepim Version: 4:3.5.10.enterprise.0.20090417.955394-kk3. Problem background: Boss B and her secretary S work together. B has Outlook/Toltec (e.g. 2.2.1) S has Kontact. S can see(write) B's INBOX/Inbox folder. Now an invitation comes in, B's OL get it via pop and Toltec syncs it out to INBOX/Inbox. The email has an XML part (missing some data) and a tnef part, and looks bad for S and his Kontact. So if criteriafortoltec() and is_email_folder() and feature_enabled() then display_subject_and_text_in_addition_to_the_email(). criteriafortoltec() is something we need to define. We'll add a few test messages for this. It currently looks like detection could be on X-Kolab-Type: application/x-vnd.kolab.o-IPM.Schedule.Meeting.Request in the header and having now other parts like the standard --BOUNDARY_20090428142635186_357025625_070DF52C Content-Type: text/plain Content-Transfer-Encoding: 7bit This is a Kolab Groupware object. To view this object you will need a email client that understands the Kolab Groupware format. For a list of such email clients please visit http://www.kolab.org/kolab2-clients.html --BOUNDARY_20090428142635186_357025625_070DF52C and Content-Type: application/x-vnd.kolab.o-IPM.Schedule.Meeting.Request Content-Type: application/x-outlook-tnef ---------- assignedto: allen messages: 19927 nosy: allen, bernhard, joonradley, ludwig, till priority: bug status: unread title: Display a special text instead of a Toltec binary invitation email. topic: enterprise4, kde client, kkc ___________________________________________________ Kolab issue tracker ___________________________________________________ From alar.sing at err.ee Wed Apr 29 13:07:22 2009 From: alar.sing at err.ee (Alar Sing) Date: Wed, 29 Apr 2009 14:07:22 +0300 Subject: [Kolab-devel] Kolab_Freebusy pear problem In-Reply-To: <20090429103252.GC13503.thomas@intevation.de> References: <49F815C1.5040706@err.ee> <20090429103252.GC13503.thomas@intevation.de> Message-ID: <49F834EA.40806@err.ee> Thomas Arendsen Hein wrote: > * Alar Sing [20090429 10:54]: > >> There is problem with Kolab_Freebusy 1.5.0 or Kolab_Server 0.5.0 pear >> package. >> In file FreeBusy/Cache.php on line 377 there is >> >> $groups = $access->user_object->getGroupAddresses(); but on Kolab_Server package there is no Horde_Kolab_Server_Object_user::getGroupAddresses() such method. >> > > Please provide more details about your setup. > > Kolab Server 2.2.1 with OpenPKG contains the packages: > Kolab_FreeBusy-0.1.2-20090406 > Kolab_Server-0.4.0-20090224 > > ... so you have something else, but what? > > Thomas > > Hello, I'm using opensuse native kolab which has Kolab_Server 0.5.0 and Kolab_FreeBusy 1.5.0 from pear.horde.org From kolab-issues at intevation.de Wed Apr 29 14:44:24 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Wed, 29 Apr 2009 12:44:24 +0000 Subject: [Kolab-devel] [issue3597] Event reminder of a deleted event appears. Message-ID: <1241009063.89.0.756806901537.issue3597@intevation.de> New submission from Ludwig Reiter : enterprise35 20090428.958685 Test: 1. Switch to the calendar component. 2. Create a new event with alarm. 3. Wait for the alarm and answer it with "Remind me later" 4. Delete the event and sync. After a short time a reminder appeared for the deleted event. I expect, that no reminder appears in this case, because I have deleted the event. ---------- assignedto: allen messages: 19931 nosy: allen, bh, ludwig priority: bug status: unread title: Event reminder of a deleted event appears. topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ From wrobel at pardus.de Wed Apr 29 15:49:06 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Wed, 29 Apr 2009 15:49:06 +0200 Subject: [Kolab-devel] Kolab_Freebusy pear problem In-Reply-To: <49F834EA.40806@err.ee> References: <49F815C1.5040706@err.ee> <20090429103252.GC13503.thomas@intevation.de> <49F834EA.40806@err.ee> Message-ID: <20090429154906.58623o799x5vovy8@webmail.pardus.de> Quoting Alar Sing : > Thomas Arendsen Hein wrote: >> * Alar Sing [20090429 10:54]: >> >>> There is problem with Kolab_Freebusy 1.5.0 or Kolab_Server 0.5.0 pear >>> package. >>> In file FreeBusy/Cache.php on line 377 there is >>> >>> $groups = $access->user_object->getGroupAddresses(); but on >>> Kolab_Server package there is no >>> Horde_Kolab_Server_Object_user::getGroupAddresses() such method. >>> >> >> Please provide more details about your setup. >> >> Kolab Server 2.2.1 with OpenPKG contains the packages: >> Kolab_FreeBusy-0.1.2-20090406 >> Kolab_Server-0.4.0-20090224 >> >> ... so you have something else, but what? >> >> Thomas >> >> > Hello, > > I'm using opensuse native kolab which has Kolab_Server 0.5.0 and > Kolab_FreeBusy 1.5.0 from pear.horde.org My release was not quite clean and I should take into account that there is not only Kolab/OpenPKG :) - which is usually very important to me so I'm really sorry I messed this up. Your Kolab_Server-0.5.0 needs this additional patch: http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php-kolab/Kolab_Server/Kolab_Server-0.5.0_p1.patch?rev=1.1&content-type=text/vnd.viewcvs-markup I will have to add a few additional test targets in my Makefiles for the next upstream releases. Cheers, Gunnar > > > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- ____ http://www.pardus.de _________________ http://gunnarwrobel.de _ E-mail : p at rdus.de Dr. Gunnar Wrobel Tel. : +49 700 6245 0000 Bundesstrasse 29 Fax : +49 721 1513 52322 D-20146 Hamburg -------------------------------------------------------------------- >> Mail at ease - Rent a kolab groupware server at p at rdus << -------------------------------------------------------------------- ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digitale PGP-Unterschrift Url : http://kolab.org/pipermail/kolab-devel/attachments/20090429/b8147440/attachment.bin From ml at radoeka.nl Wed Apr 29 23:16:35 2009 From: ml at radoeka.nl (Richard Bos) Date: Wed, 29 Apr 2009 23:16:35 +0200 Subject: [Kolab-devel] Kolab_Freebusy pear problem In-Reply-To: <20090429154906.58623o799x5vovy8@webmail.pardus.de> References: <49F815C1.5040706@err.ee> <49F834EA.40806@err.ee> <20090429154906.58623o799x5vovy8@webmail.pardus.de> Message-ID: <200904292316.36283.ml@radoeka.nl> Op woensdag 29 april 2009 15:49:06 schreef Gunnar Wrobel: > > I'm using opensuse native kolab which has Kolab_Server 0.5.0 and > > Kolab_FreeBusy 1.5.0 from pear.horde.org > > My release was not quite clean and I should take into account that > there is not only Kolab/OpenPKG :) - which is usually very important > to me so I'm really sorry I messed this up. > > Your Kolab_Server-0.5.0 needs this additional patch: > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/php-kolab/Kolab_Server/Ko >lab_Server-0.5.0_p1.patch?rev=1.1&content-type=text/vnd.viewcvs-markup Thanks Gunnar. I have added the patch to the package in the build service. To Alar: the new package will be available soon, with the patch included :) > I will have to add a few additional test targets in my Makefiles for > the next upstream releases. @Gunnar: is it possible to include a test or tests to uses methods from the php-dba package? In our opensuse setup freebusy did not work, because the php-dba package was missing. It was difficult to trace why the freebusy did not work, until Alar mentioned that the php-dba package was missing. After adding the package to the installation freebusy is now working fine! Hence it test to verify that php-dba is installed is useful. -- Richard From ml at radoeka.nl Wed Apr 29 23:18:16 2009 From: ml at radoeka.nl (Richard Bos) Date: Wed, 29 Apr 2009 23:18:16 +0200 Subject: [Kolab-devel] Freebusy data not provided (native openSUSE) In-Reply-To: <20090419055746.193486culnyvoabc@webmail.pardus.de> References: <200903071341.45223.richard@radoeka.nl> <200903082209.58995.ml@radoeka.nl> <20090419055746.193486culnyvoabc@webmail.pardus.de> Message-ID: <200904292318.16722.ml@radoeka.nl> Op zondag 19 april 2009 05:57:46 schreef Gunnar Wrobel: > > If you or someone else has an idea, to get me going a little further that > > would be nice and appreciated. > > Does the problem still persist? I know I responded very late now. I > tend to be somewhat too busy these days :( It was solved today! Alar Sing came up with the marvelous idea to install the php-dba package. After that the freebusy system started to work :) Goodies to Alar, you made my day :) -- Richard From bernhard at intevation.de Thu Apr 30 08:42:23 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 30 Apr 2009 08:42:23 +0200 Subject: [Kolab-devel] Automatically built KDEPIM packages now published on files.kolab.org In-Reply-To: <200904282008.16616.bh@intevation.de> References: <200904282008.16616.bh@intevation.de> Message-ID: <200904300842.23859.bernhard@intevation.de> Am Dienstag, 28. April 2009 20:08:07 schrieb Bernhard Herzog: > We've automated the build system a bit more, and the > newest automatically built packages are now available on files.kolab.org. > > IMPORTANT: These are packages are automatically built from SVN development > snapshots and have seen no quality-control whatsoever. ?They are useful for > testing but are NOT usable for production use. ATTENTION: They could potentially contain malicious code, so use them only for development testing purposes. The reason is our build process: between drop candidates developers are free to completely destroy the code base to get it back for the weekly drop candidate. The saegewerk will also build those broken versions! In addition KDE offers write access to their source repository for a lot of people, if someone checks in malicious code, it will be automatically build and published within the snapshots. So check the difference to the last trusted version before using a snapshot. For the drop candidates, developers are doing this, so the weekly drop candidates are a lot better. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090430/da1d95c1/attachment-0001.bin From kolab-issues at intevation.de Thu Apr 30 10:53:44 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Thu, 30 Apr 2009 08:53:44 +0000 Subject: [Kolab-devel] [issue3599] KNotes: Crash in KNotesResourceManager::deleteNote at resourcemanager.cpp:109 Message-ID: <1241081624.06.0.844688057324.issue3599@intevation.de> New submission from Ludwig Reiter : enterprise35 20090428.958635 I don't have a clear step to step instruction, but I have tried to: * Create three new note with RMB on the knote icon. * Delete some of the notes (folder, notes in kontact, yellow notes on desktop) * Close and Restarted knotes and kontact. in different order And sometimes, if I deleted all notes and restart knotes, there is this lonely note on the desktop and I tried to delete it and bang, knotes crashes. (see the backtrace crash-del-note-20090430.txt) ---------- assignedto: allen files: crash-del-note-20090430.txt messages: 19951 nosy: allen, bh, ludwig priority: urgent status: unread title: KNotes: Crash in KNotesResourceManager::deleteNote at resourcemanager.cpp:109 topic: enterprise35, kde client ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crash-del-note-20090430.txt Url: http://kolab.org/pipermail/kolab-devel/attachments/20090430/4197897c/crash-del-note-20090430.txt From kolab-issues at intevation.de Thu Apr 30 14:00:00 2009 From: kolab-issues at intevation.de (Martin Zapfl) Date: Thu, 30 Apr 2009 12:00:00 +0000 Subject: [Kolab-devel] [issue3600] OpenLDAP Kolab2 schema custom ISP attribute extension Message-ID: <1241092800.35.0.71382769363.issue3600@intevation.de> New submission from Martin Zapfl : This patch adds several new attributes to the kolab2.schema. It has been tested against CVS revision 1.35.The patch is also part of issue 3463 (custom ISP patches) The following new openldap attributes will be added: Class kolabGroupOfNames - uidPrefix (set a prefix for customer users that is always prepended) - maxAccounts (max. number of user accounts per customer) - domainQuota (default quota for a newly added domain) - domainDefaultQuota (default quota for an user account that belongs to that domain) - disableGroupware (disables Groupware fields for a user such as address...) Class kolabInetOrgPerson - lastLogin (last login date of a user to imap / pop3 services) Class kolab - passwordSecUserRegEx (regular expression to check against user passwords) - passwordSecAdminRegEx (regular expression to check against admin passwords) The patch is applied by running patch -p0 -i kolab2.2.schema.rev10.patch openldap must be restarted to apply changes of ldap schema. Please note: This is still a beta release. Do not install it on production machines!! ---------- assignedto: martinzapfl files: kolab2.2.schema.rev10.patch messages: 19961 nosy: martinzapfl priority: feature status: chatting title: OpenLDAP Kolab2 schema custom ISP attribute extension topic: server ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: kolab2.2.schema.rev10.patch Type: application/octet-stream Size: 3894 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090430/eac0e305/kolab2.2.schema.rev10.exe From kolab-issues at intevation.de Thu Apr 30 16:24:45 2009 From: kolab-issues at intevation.de (Bernhard Reiter) Date: Thu, 30 Apr 2009 14:24:45 +0000 Subject: [Kolab-devel] [issue3601] Toltec: utf-8 quoted-printable emails conversion to latin-1 problem (affecting umlauts) Message-ID: <1241101485.69.0.471186458768.issue3601@intevation.de> New submission from Bernhard Reiter : Sending an email with Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable get missconverted by Toltec Verified with Toltec 2.3.2-beta14. Example attached: testmail-umlauts-utf8_sent.mbox a) the umlauts are converted to latin1, but charset="utf-8" is kept so they cannot be decoded correctly by other email clients. Sch=C3=BCtze get to be Sch=FCtze There is an old issue about kolab/issue1722 (Toltec: Certain UTF-8 8bit transfer-encoded emails messed up) which was fixed with toltec-2.1.1beta4-de-kolabxml.exe.) It explains that the conversion is going on, which is fine. b) the quoted-printable encoding is missing to connect the lines, e.g. ..Reit er,=20Dr.=20Jan-Oliver=20Wagner which introduces a linefeed behind "Rei" which shouldn't be there. ---------- assignedto: joonradley files: testmail-umlauts-utf8_sent.mbox messages: 19970 nosy: bernhard, emanuel, joonradley, ludwig priority: urgent status: unread title: Toltec: utf-8 quoted-printable emails conversion to latin-1 problem (affecting umlauts) topic: toltec ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: testmail-umlauts-utf8_sent.mbox Type: application/octet-stream Size: 947 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090430/5e367039/testmail-umlauts-utf8_sent.exe From allen at kdab.net Tue Apr 28 15:18:13 2009 From: allen at kdab.net (Allen Winter) Date: Tue, 28 Apr 2009 13:18:13 -0000 Subject: [Kolab-devel] [issue3593] Switching to monthview crashes Kontact In-Reply-To: <1240923323.72.0.104039577057.issue3593@intevation.de> References: <1240923323.72.0.104039577057.issue3593@intevation.de> Message-ID: <200904280918.07788.allen@kdab.net> This crash was fixed with urgent blocker fix for issue3576 "Crash in MonthViewItem::paint when switching to monthly calendar view". The fix should have been included with the 200904024 tag. On Tuesday 28 April 2009 08:55:23 am Thomas Ribbrock wrote: > New submission from Thomas Ribbrock : > > After upgrading from 938853 to 955394, Kontact started crashing whenever I > try to switch to monthview in the calendar. The only other thing I did > before switching to monthview was changing the colour for events that have > no category. Backtrace attached. > > Versions: > Qt: 3.3.8b > KDE: 3.5.10 > Kontact: 1.2.9 (enterprise35 20090417.955394) > on Kubuntu 8.04. > > Note: The Kubuntu package I'm using is based on the > kdepim_3.5.10.enterprise.0.20090417.955394-kk3 package - as far as I could > see, some additional patches seem to be present for issue2472 and > issue3576. From "changelog": > > kdepim (4:3.5.10.enterprise.0.20090417.955394-kk3) unstable; urgency=low > > * Patched with diff r956733:956734 to solve kolab/issue3576 > > -- Ludwig Reiter Fri, 24 Apr 2009 16:30:09 > +0200 > > > kdepim (4:3.5.10.enterprise.0.20090417.955394-kk2) unstable; urgency=low > > * Patched with diff r957261:957262 to solve kolab/issue2472 > > -- Ludwig Reiter Wed, 22 Apr 2009 12:45:55 > +0200 > > ---------- > files: Crash_on_switching_to_monthview-955394.txt > messages: 19904 > nosy: itsef_admin > priority: urgent > status: unread > title: Switching to monthview crashes Kontact > topic: enterprise35, kde client > ___________________________________________________ > Kolab issue tracker > > ___________________________________________________ -- Allen Winter | allen at kdab.net | Software Engineer KDAB (USA), LLC, a KDAB Group company Tel. USA +1-866-777-KDAB(5322), Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From kolab-issues at intevation.de Thu Apr 30 10:17:55 2009 From: kolab-issues at intevation.de (Ludwig Reiter) Date: Thu, 30 Apr 2009 08:17:55 -0000 Subject: [Kolab-devel] [issue3598] monthview: public holiday description of events are missing Message-ID: <1241079470.34.0.732651612303.issue3598@intevation.de> New submission from Ludwig Reiter : enterprise35 20090417.955394 Test: 1. Switch to calendar 2. Configure in Calendar->Date&Time->Set holiday region a region. 3. Switch to month view and look at a public holiday. => There is no description of this day. 4. Create a test event at this day. => The event is not displayed at the first row of a day. (See screenshot holiday-20090430.png) The user expect that there is a holiday description. This is a regression as it worked in earlier versions. ---------- assignedto: allen files: holiday-20090430.png messages: 19947 nosy: allen, bh, ludwig priority: bug status: unread title: monthview: public holiday description of events are missing topic: kde client, prokde35 ___________________________________________________ Kolab issue tracker ___________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: holiday-20090430.png Type: image/png Size: 103462 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090430/5fadae8f/holiday-20090430-0001.png