From thomas at intevation.de Tue Sep 1 12:37:33 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Tue, 1 Sep 2009 12:37:33 +0200 Subject: [Kolab-devel] Kolab issue tracker upgrade today at 14:00 UTC In-Reply-To: <20090831160528.894619539.thomas@intevation.de> References: <20090827151616.141005530.thomas@intevation.de> <20090827173031.119953724.thomas@intevation.de> <20090831160528.894619539.thomas@intevation.de> Message-ID: <20090901121132.045119618.thomas@intevation.de> * Thomas Arendsen Hein [20090831 16:09]: > * Thomas Arendsen Hein [20090827 17:39]: > > Please report any problems with the tracker to this list or directly > > to me. > > Full text search seems to have some problems, e.g. search for > "died with" does not find "Command died with status 40" in > kolab/issue3610, but "caused by full quota" is found. > > Fixing this has high priority for me, I will send another mail when > this is solved. I turned of the Xapian indexer, now a simpler indexer is used. Title search for "achedImapJo" or "CachedImapJob" will find: kolab/issue2286 (Crash below KMail::CachedImapJob::slotPutMessageInfoData after working with tasks.) (i.e. substring search) "All text" search for "CachedImapJo" will find nothing, i.e searches only on full (indexed) words. "All text" search for "CachedImapJob" will find 24 issues, even kolab/issue2265, which contains the word only in an attached text file. It will find issues with this word only in the title, too. I created http://issues.roundup-tracker.org/issue2550583 for the Xapian problem in Roundup. 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/20090901/4bf110c7/attachment.bin From issues at kolab.org Tue Sep 1 12:47:44 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 01 Sep 2009 10:47:44 +0000 Subject: [Kolab-devel] [issue3829] Recent addresses don't change, after send a mail to an address and changed display order In-Reply-To: <1251802064.07.0.109321098238.issue3829@kolab.org> Message-ID: <1251802064.07.0.109321098238.issue3829@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090828.1016660-kk1 Test: 1. Change the completion display order. 2. Send a mail to contact "A, B" 3. Try to send another mail to the contact. => The contact is not under the recent adresses. It should be there. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21455 nosy: allen, ludwig priority: bug status: unread title: Recent addresses don't change, after send a mail to an address and changed display order ______________________________________ Kolab issue tracker ______________________________________ From bernhard at intevation.de Wed Sep 2 09:49:47 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 2 Sep 2009 09:49:47 +0200 Subject: [Kolab-devel] annotations patch in c-client what is the status? In-Reply-To: <200907240923.58654.martin.konold@erfrakon.de> References: <200906032321.30110.ml@radoeka.nl> <200907010951.27696.bernhard@intevation.de> <200907240923.58654.martin.konold@erfrakon.de> Message-ID: <200909020949.53616.bernhard@intevation.de> Am Freitag, 24. Juli 2009 09:23:58 schrieb Martin Konold: > On Wednesday 01 July 2009 09:51:24 Bernhard Reiter wrote: > > Note that currently there is a new imap c++ library developed > > (as part of our "prototype-e5" contract extending Kontact). This might be > > able to replace the c-client library, especially in situations where it > > actually is wrapped for access in an object oriented way. http://websvn.kde.org/trunk/KDE/kdepimlibs/kimap/ The new library currently lives in KDE's svn, it is fine to use it for other purposes and you can ask questions about it over the KDE lists. (Or try here on this list.) I believe it is pretty complete, and if you find defects in it soon the chances are higher that we just fix them. It depends on QT4 (the non-gui part, which is a general C++ class library). There is a weak dependency on KDE, if you like to have SSL/TLS certificate handling, but you can do without. kimap is a lot faster and more complete than other libraries we've examined. Our development target with it is to use it in KDE Kontact (Prototype-E5), but hey this is Free Software, it would be cool to have a community around it. > > BH (in cc) will post later where to find the library. > I did not see the relevant post. Sorry for the delay, we are planning to have a techbase wiki page but this did not happen as fast as I was hoping for. 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/20090902/5314de22/attachment.bin From issues at kolab.org Wed Sep 2 11:34:00 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 02 Sep 2009 09:34:00 +0000 Subject: [Kolab-devel] [issue3830] Mail: Setting option properties->share unread state with all users on an inbox doesn't have an effect. In-Reply-To: <1251884040.6.0.701641144356.issue3830@kolab.org> Message-ID: <1251884040.6.0.701641144356.issue3830@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090807.1015511-kk9 Test: 1. Switch to Mail plugin. 2. RMB on the inbox and choose properties. 3. Set on "Share unread state with all users". 4. Press ok. 5. Open the properties of the inbox again. The check before "Share unread state with all users" is not set. Please estimate this problem, before fixing it. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21468 nosy: allen, ludwig priority: bug status: unread title: Mail: Setting option properties->share unread state with all users on an inbox doesn't have an effect. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 2 12:22:17 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 02 Sep 2009 10:22:17 +0000 Subject: [Kolab-devel] [issue3831] Forward inline: the header of the forwarded msg doesn't contain the CC field and the time after the date. In-Reply-To: <1251886937.4.0.134843717722.issue3831@kolab.org> Message-ID: <1251886937.4.0.134843717722.issue3831@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090807.1015511-kk9 Test: 1. Send a msg with CC to yourself. 2. Sync 3. Forward inline this mail to yourself. Notice the CC field and the time of the date are missing in the header of the msg. I expect them also to be written in the header. ---------- assignedto: allen keyword: enterprise35, kde client, kkc messages: 21470 nosy: allen, ludwig priority: bug status: unread title: Forward inline: the header of the forwarded msg doesn't contain the CC field and the time after the date. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Thu Sep 3 16:58:09 2009 From: issues at kolab.org (Thomas Arendsen Hein) Date: Thu, 03 Sep 2009 14:58:09 +0000 Subject: [Kolab-devel] [issue3832] Entering domain part in "Primary Email Address" does not abort In-Reply-To: <1251989889.39.0.620920190699.issue3832@kolab.org> Message-ID: <1251989889.39.0.620920190699.issue3832@kolab.org> New submission from Thomas Arendsen Hein : Kolab Server 2.2.2: When entering "foo at example.com" in the input field for "Primary Email Address", the user is partially created as foo at example.com@example.com, which does not work. The user can be deleted without problems. The web admin interface should disallow @ in the user name (abort with error), optionally drop @example.com if it is one of the server domains (beware of multi-domain setups and/or multiple occurrences of the @ sign) ---------- assignedto: thomas keyword: server, web admin messages: 21475 nosy: martin, thomas, wilde, wrobel priority: minor bug status: unread title: Entering domain part in "Primary Email Address" does not abort ______________________________________ Kolab issue tracker ______________________________________ From thomas at intevation.de Thu Sep 3 17:09:48 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 3 Sep 2009 17:09:48 +0200 Subject: [Kolab-devel] Postfix Warning In-Reply-To: <200909021651.37181.ml@radoeka.nl> References: <4A9E2B27.3050300@zawm.be> <20090902150358.676160746.thomas@intevation.de> <200909021651.37181.ml@radoeka.nl> Message-ID: <20090903170335.371153772.thomas@intevation.de> * Richard Bos [20090902 16:51]: > Op woensdag 02 september 2009 15:09:32 schreef Thomas Arendsen Hein: > > * Sascha Schneider [20090902 10:21]: > > > I have a postfix warning in postfix.log with kolab 2.2.2 > > > postfix/cleanup: database /kolab/etc/postfix/canonical.db is > > > older than source file /kolab/etc/postfix/canonical > > > > You can ignore this warning. kolabconf generates the new file and if > > it is different from the old file, it runs postmap to create the new > > .db file. > > > > The logic in kolabconf could be improved a bit to prevent touching > > the target configuration file (canonical) if there will be no > > difference tough. > > > > Maybe you can create an entry for this on issues.kolab.org with > > priority "feature" and assign it to me (thomas)? > > I get the same message for these databases: > kolab2:/var/log # grep "is older than source file" warn | sed 's/.*warning: > database //' | sort -u > /etc/postfix/canonical.db is older than source file /etc/postfix/canonical > /etc/postfix/relocated.db is older than source file /etc/postfix/relocated > /etc/postfix/transport.db is older than source file /etc/postfix/transport > /etc/postfix/virtual.db is older than source file /etc/postfix/virtual Yes, the code is identical for all templates: - copy config file to backup - create new temp file from template - move temp file to config file - check if config file differs from backup - if yes, do what's needed (e.g. run postmap) If the check is done before the move, above warning will vanish. See perl-kolab/lib/Kolab/Conf.pm: build() This is more development than user talk, so moving to kolab-devel. Regards, 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 issues at kolab.org Fri Sep 4 10:33:05 2009 From: issues at kolab.org (Ludwig Reiter) Date: Fri, 04 Sep 2009 08:33:05 +0000 Subject: [Kolab-devel] [issue3833] Mails will vanish, if some subfolders and their favorites are renamed. In-Reply-To: <1252053185.03.0.40814302661.issue3833@kolab.org> Message-ID: <1252053185.03.0.40814302661.issue3833@kolab.org> New submission from Ludwig Reiter : tested with e35 20090828.1016660-kk1 I have three subfolder of a subfolder of the inbox (e.g. inbox->test->test1 test2 test3) In these subfolder are about 100 mails. RMB->Properties on test1 and change the name to xxb In the same way change the name of test2 to xxa and test3 to xxc. Sync. Rename the favorite of xxa->xxa xxx, xxb->xxb xxx, xxc->xxc xxx and sync again. Now xxa and xxb are empty. I will try to simplify the test. It is critical, because mails can get lost. ---------- assignedto: allen keyword: kde client, prokde35 messages: 21482 nosy: allen, ludwig priority: critical status: unread title: Mails will vanish, if some subfolders and their favorites are renamed. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Sat Sep 5 10:58:00 2009 From: issues at kolab.org (Axel Spoerl) Date: Sat, 05 Sep 2009 08:58:00 +0000 Subject: [Kolab-devel] [issue3834] Turba not connecting groupwarefolders In-Reply-To: <1252141080.15.0.605995351644.issue3834@kolab.org> Message-ID: <1252141080.15.0.605995351644.issue3834@kolab.org> New submission from Axel Spoerl : I have installed a plain and recent kolab 2.2.2 version and recovered the ldap user database as well as the imap store from a previous version. Everything works like a charm, but horde does not recognize the groupware folders for calender, contacts, journal, tasks, notes. They are displayed like normal folders in the webmail folder tree. The respective horde apps (e.g. turba) do not connect to those folders. ---------- files: folders.jpg messages: 21493 nosy: axel at spoerls.net priority: bug status: unread title: Turba not connecting groupwarefolders ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: folders.jpg Type: image/jpeg Size: 29948 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090905/312589c6/folders-0001.jpg From issues at kolab.org Mon Sep 7 15:56:52 2009 From: issues at kolab.org (Ludwig Reiter) Date: Mon, 07 Sep 2009 13:56:52 +0000 Subject: [Kolab-devel] [issue3835] Edit in the Reminder dialog doesn't work after restart of KDE. In-Reply-To: <1252331812.45.0.889179690514.issue3835@kolab.org> Message-ID: <1252331812.45.0.889179690514.issue3835@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090807-1015511-kk9 Test: In KDE: 1. Start kontact. 2. Create a task or event with reminder in some minute. 3. Switch to the Mail plugin. 4. Close the KDE session without closing Kontact before. 5. Wait until the remider time is over. 6. Start KDE again. => Kontact with the Mail plugin should start. => After a moment the reminder appears. 7. Click on the task or event and press Edit. => The reminder is sent to the background, but no Edit dialog appears. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21499 nosy: allen, ludwig priority: urgent status: unread title: Edit in the Reminder dialog doesn't work after restart of KDE. ______________________________________ Kolab issue tracker ______________________________________ From aspineux at gmail.com Mon Sep 7 16:52:15 2009 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 7 Sep 2009 16:52:15 +0200 Subject: [Kolab-devel] no logging for pop3 Message-ID: <71fe4e760909070752y60185389y91e06d5676becf1c@mail.gmail.com> in cyrus.conf.template @@@if cyrus-pop3@@@ pop3 cmd="pop3d -C /kolab/etc/imapd/imapd.conf" listen="@@@bind_addr@@@:110" prefork=0 @@@endif@@@ @@@if cyrus-pop3s@@@ pop3s cmd="pop3d -s -C /kolab/etc/imapd/imapd.conf" listen="@@@bind_addr@@@:995" prefork=0 @@@endif@@@ "pop3" is a possible "ident" for fsl but but in fsl.imapd .. ident (pop3.)/.+ q{ prefix( .. pop3 don't match the "POP3" entry Then the entry should be .. ident (pop3|pop3.)/.+ q{ prefix( .. or maybe .. ident (pop3|pop3s)/.+ q{ prefix( .. Did I miss something ? Regards. -- Alain Spineux aspineux gmail com May the sources be with you From issues at kolab.org Tue Sep 8 11:16:24 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 08 Sep 2009 09:16:24 +0000 Subject: [Kolab-devel] [issue3836] Saved auditlog contains some strange xml text In-Reply-To: <1252401384.98.0.159842107528.issue3836@kolab.org> Message-ID: <1252401384.98.0.159842107528.issue3836@kolab.org> New submission from Ludwig Reiter : Kontact enterprise35 20090907.1020975-kk1 If the user saves the auditlog of a S/MIME signed mail to a file, he will get a file full of XML. I expect the saved auditlog to be in a human useable form. Is there a reason to save the markups to the file? ---------- assignedto: allen keyword: enterprise35, kde client messages: 21512 nosy: allen, ludwig priority: bug status: unread title: Saved auditlog contains some strange xml text ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Tue Sep 8 15:22:17 2009 From: issues at kolab.org (Thomas Arendsen Hein) Date: Tue, 08 Sep 2009 13:22:17 +0000 Subject: [Kolab-devel] [issue3837] Reproducible crash when (not) decrypting s/mime message In-Reply-To: <1252416137.44.0.49128075518.issue3837@kolab.org> Message-ID: <1252416137.44.0.49128075518.issue3837@kolab.org> New submission from Thomas Arendsen Hein : Kontact Version 1.2.9 (enterprise35 20090807.1015511) When looking at an encrypted s/mime message the mail window looks like this: ---Encrypted message--- This message is encrypted. Decrypt Message ---End of encrypted message--- Now I click on "Decrypt Message", pinentry-qt 0.7.5-2.1 asks for my passphrase. In the background the mail window looks like this: ---Encrypted message (decryption not possible)--- smime.p7m ---End of encrypted message--- Then I minimize the pinentry window, click on the smime.p7m link in the mail window, click on Open with 'Kleopatra', confirm the error message (Invalid crypto engine) with OK, close Kleopatra, unminimize pinentry again. When I now click on OK three times (without entering a password) or on Cancel, kontact either crashes with the attached traceback or freezes until I kill it. (Note that I do not need to minimize pinentry when the pinentry does not obstruct the smime.p7m link, but in my default window layout it does) ---------- assignedto: allen files: kontact-crash.txt keyword: enterprise35, kde client messages: 21523 nosy: allen, laurent, ludwig, thomas, till, tmcguire, vkrause priority: urgent status: unread title: Reproducible crash when (not) decrypting s/mime message ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1242904896 (LWP 14736)] [New Thread -1286542416 (LWP 14767)] [New Thread -1278153808 (LWP 14766)] [New Thread -1269765200 (LWP 14765)] [New Thread -1261376592 (LWP 14764)] [KCrash handler] #5 0xb776de14 in memmove () from /lib/tls/libc.so.6 #6 0xb4dc495b in mem_copy (src=0x19
, n=6, dest=0x19
) at dwstring.cpp:143 #7 0xb4dc3523 in DwString::_copy (this=0x87e6fd8) at dwstring.cpp:1228 #8 0xb507bf95 in DwString::c_str (this=0x87e6fd8) at ../mimelib/mimelib/string.h:620 #9 0xb507bfd0 in DwMessageComponent::partId (this=0x87e6fb0) at ../mimelib/mimelib/msgcmp.h:259 #10 0xb5290822 in partNode::findNodeForDwPart (this=0x8930650, part=0x87e6fb0) at partNode.cpp:457 #11 0xb515251b in KMReaderWin::update (this=0x8424c48, observable=0x882542c) at kmreaderwin.cpp:890 #12 0xb5307e47 in KMail::ISubject::notify (this=0x882542c) at isubject.cpp:35 #13 0xb5288a10 in KMail::DecryptVerifyBodyPartMemento::notify (this=0x8825400) at objecttreeparser_p.h:87 #14 0xb5287c90 in KMail::DecryptVerifyBodyPartMemento::qt_invoke ( this=0x8825400, _id=3, _o=0xbfc2e0c8) at objecttreeparser_p.moc:94 #15 0xb6fbfd4f in QObject::activate_signal (this=0x81207c0, clist=0x884ecd8, o=0xbfc2e0c8) at kernel/qobject.cpp:2356 #16 0xb7348bbf in QSignal::signal (this=0x81207c0, t0=@0x81207e8) at .moc/debug-shared-mt/moc_qsignal.cpp:100 #17 0xb6fdf8d2 in QSignal::activate (this=0x81207c0) at kernel/qsignal.cpp:212 #18 0xb6fe72a4 in QSingleShotTimer::event (this=0x8120798) at kernel/qtimer.cpp:286 #19 0xb6f57c26 in QApplication::internalNotify (this=0xbfc2e6cc, receiver=0x8120798, e=0xbfc2e438) at kernel/qapplication.cpp:2635 #20 0xb6f59a43 in QApplication::notify (this=0xbfc2e6cc, receiver=0x8120798, e=0xbfc2e438) at kernel/qapplication.cpp:2358 #21 0xb767fe0e in KApplication::notify (this=0xbfc2e6cc, receiver=0x8120798, event=0xbfc2e438) at /chroots/etch-chroot/home/white/kdelibs/new/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550 #22 0xb6eeb421 in QApplication::sendEvent (receiver=0x8120798, event=0xbfc2e438) at ../include/qapplication.h:520 #23 0xb6f4a623 in QEventLoop::activateTimers (this=0x80af028) at kernel/qeventloop_unix.cpp:556 #24 0xb6eff76f in QEventLoop::processEvents (this=0x80af028, flags=4) at kernel/qeventloop_x11.cpp:389 #25 0xb6f72179 in QEventLoop::enterLoop (this=0x80af028) at kernel/qeventloop.cpp:198 #26 0xb6f71f9a in QEventLoop::exec (this=0x80af028) at kernel/qeventloop.cpp:145 #27 0xb6f597bf in QApplication::exec (this=0xbfc2e6cc) at kernel/qapplication.cpp:2758 #28 0x0805e2d4 in main (argc=) at main.cpp:188 #29 0xb7715ea8 in __libc_start_main () from /lib/tls/libc.so.6 #30 0x0805dbf1 in _start () at ../sysdeps/i386/elf/start.S:119 From thomas at intevation.de Tue Sep 8 15:43:50 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Tue, 8 Sep 2009 15:43:50 +0200 Subject: [Kolab-devel] no logging for pop3 In-Reply-To: <71fe4e760909070752y60185389y91e06d5676becf1c@mail.gmail.com> References: <71fe4e760909070752y60185389y91e06d5676becf1c@mail.gmail.com> Message-ID: <20090908153725.118592562.thomas@intevation.de> * Alain Spineux [20090907 16:58]: > in cyrus.conf.template > > @@@if cyrus-pop3@@@ > pop3 cmd="pop3d -C /kolab/etc/imapd/imapd.conf" > listen="@@@bind_addr@@@:110" prefork=0 > @@@endif@@@ > @@@if cyrus-pop3s@@@ > pop3s cmd="pop3d -s -C /kolab/etc/imapd/imapd.conf" > listen="@@@bind_addr@@@:995" prefork=0 > @@@endif@@@ > > "pop3" is a possible "ident" for fsl but > > but in fsl.imapd > > .. > ident (pop3.)/.+ q{ > prefix( > .. > > pop3 don't match the "POP3" entry > > Then the entry should be > > .. > ident (pop3|pop3.)/.+ q{ > prefix( > .. > > or maybe > > .. > ident (pop3|pop3s)/.+ q{ > prefix( > .. > > Did I miss something ? No, you are right. Since people might work around the problem by changing "pop3" to "pop3d" in cyrus.conf, and to be symmetrical with the imap logfile, the fsl pattern should probably be (pop3d|pop3s|pop3)/.+ (Copy to the tracker, let's see if that is enough to file a new issue with the current settings) 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 issues at kolab.org Tue Sep 8 15:43:52 2009 From: issues at kolab.org (Thomas Arendsen Hein) Date: Tue, 08 Sep 2009 13:43:52 +0000 Subject: [Kolab-devel] [issue3838] no logging for pop3 In-Reply-To: <71fe4e760909070752y60185389y91e06d5676becf1c@mail.gmail.com> Message-ID: <20090908153725.118592562.thomas@intevation.de> New submission from Thomas Arendsen Hein : * Alain Spineux [20090907 16:58]: > in cyrus.conf.template > > @@@if cyrus-pop3@@@ > pop3 cmd="pop3d -C /kolab/etc/imapd/imapd.conf" > listen="@@@bind_addr@@@:110" prefork=0 > @@@endif@@@ > @@@if cyrus-pop3s@@@ > pop3s cmd="pop3d -s -C /kolab/etc/imapd/imapd.conf" > listen="@@@bind_addr@@@:995" prefork=0 > @@@endif@@@ > > "pop3" is a possible "ident" for fsl but > > but in fsl.imapd > > .. > ident (pop3.)/.+ q{ > prefix( > .. > > pop3 don't match the "POP3" entry > > Then the entry should be > > .. > ident (pop3|pop3.)/.+ q{ > prefix( > .. > > or maybe > > .. > ident (pop3|pop3s)/.+ q{ > prefix( > .. > > Did I miss something ? No, you are right. Since people might work around the problem by changing "pop3" to "pop3d" in cyrus.conf, and to be symmetrical with the imap logfile, the fsl pattern should probably be (pop3d|pop3s|pop3)/.+ (Copy to the tracker, let's see if that is enough to file a new issue with the current settings) Regards, Thomas Arendsen Hein ---------- messages: 21525 nosy: thomas status: unread title: no logging for pop3 ______________________________________ Kolab issue tracker ______________________________________ From thomas at intevation.de Tue Sep 8 15:50:02 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Tue, 8 Sep 2009 15:50:02 +0200 Subject: [Kolab-devel] [issue3838] no logging for pop3 In-Reply-To: <20090908153725.118592562.thomas@intevation.de> References: <71fe4e760909070752y60185389y91e06d5676becf1c@mail.gmail.com> <20090908153725.118592562.thomas@intevation.de> Message-ID: <20090908154847.788909547.thomas@intevation.de> * Thomas Arendsen Hein [20090908 15:43]: > (Copy to the tracker, let's see if that is enough to file a new > issue with the current settings) It seems to work fine and since the new issue is reported to this list, I would not even have needed to send to the list, too. 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 wrobel at pardus.de Tue Sep 8 21:08:29 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Tue, 08 Sep 2009 21:08:29 +0200 Subject: [Kolab-devel] wilde: server/pear/Horde_Framework package.info, 1.2, 1.3 In-Reply-To: <20090810150247.125F8600147@lists.intevation.de> References: <20090810150247.125F8600147@lists.intevation.de> Message-ID: <20090908210829.35845g0fxkd7cwow@webmail.pardus.de> Quoting cvs at kolab.org: > Author: wilde > > Update of /kolabrepository/server/pear/Horde_Framework > In directory doto:/tmp/cvs-serv15180 > > Modified Files: > package.info > Log Message: > Fixed dependence at PEAR-Log. > This is kind of a guess, it was Log and we have Hoder_Log and > PEAR-Log, looking at package.xml in the tar I think PEAR-Log might be > the right choice... Gunnar should verify this. This was correct. Cheers, Gunnar > > > Index: package.info > =================================================================== > RCS file: /kolabrepository/server/pear/Horde_Framework/package.info,v > retrieving revision 1.2 > retrieving revision 1.3 > diff -u -d -r1.2 -r1.3 > --- package.info 23 Jul 2009 08:10:09 -0000 1.2 > +++ package.info 10 Aug 2009 15:02:44 -0000 1.3 > @@ -45,7 +45,7 @@ > PreReq: OpenPKG, openpkg >= 20070603 \ > PreReq: php, php::with_pear = yes \ > PreReq: PEAR-Horde-Channel \ > -PreReq: Log \ > +PreReq: PEAR-Log \ > PreReq: Horde_CLI \ > PreReq: Horde_DOM \ > PreReq: Horde_Util \ > > > _______________________________________________ > Kolab-commits mailing list > Kolab-commits at kolab.org > https://kolab.org/mailman/listinfo/kolab-commits > -- ______ 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 << -------------------------------------------------------------------- From issues at kolab.org Wed Sep 9 11:48:48 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 09 Sep 2009 09:48:48 +0000 Subject: [Kolab-devel] [issue3839] The audit log of an S/MIME signed mail, which key has expired, should show the expired key. In-Reply-To: <1252489728.64.0.930866181674.issue3839@kolab.org> Message-ID: <1252489728.64.0.930866181674.issue3839@kolab.org> New submission from Ludwig Reiter : Tested with Kontact e35 20090907.1020977-kk1 The user has a S/MIME signed mail, which was correctly signed, but now the key has expired. The user looks at the details of the signature and finds that: One key has expired. So he looks at the audit logs. I would expect that the user could find out which key has expired in the audit log. But he cannot find the expired key there. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21550 nosy: allen, ludwig, thomas priority: bug status: unread title: The audit log of an S/MIME signed mail, which key has expired, should show the expired key. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 9 11:55:14 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 09 Sep 2009 09:55:14 +0000 Subject: [Kolab-devel] [issue3840] The user cannot copy and paste from the audit log, because it suddently scrolls to the top. In-Reply-To: <1252490114.92.0.487912045794.issue3840@kolab.org> Message-ID: <1252490114.92.0.487912045794.issue3840@kolab.org> New submission from Ludwig Reiter : Kontact e35 20090907.1020977-kk1 Test: 1. Look at the details of the signature of a S/MIME signed mail. 2. Open the audit log. 3. Scroll to the bottom and try to copy and paste 3 lines. => The lines are not selected, because the audit logs scrolls to the top. Copy and paste should work. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21551 nosy: allen, ludwig, thomas priority: bug status: unread title: The user cannot copy and paste from the audit log, because it suddently scrolls to the top. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 9 12:09:51 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 09 Sep 2009 10:09:51 +0000 Subject: [Kolab-devel] [issue3841] After the user enters a wrong password three times , he cannot click on decrypt again. In-Reply-To: <1252490991.88.0.600159433778.issue3841@kolab.org> Message-ID: <1252490991.88.0.600159433778.issue3841@kolab.org> New submission from Ludwig Reiter : Kontact e35 20090907.1020977-kk1 Test: 1. The user gets a S/MIME decrypted mail. 2. He clicks on Decrypt msg, but enters a wrong password three times. => The blue border of the mail says decryption not possible, no key. That is correct. 3. But the user really wants to decrypt the msg, so he clicks on the smime.p7c link and kleopatra opens with an error. I expect that the smime.p7c link is not displayed, instead there should be the Decrypt msg link, so that the user can retry to decrpyt the msg. (At the moment he has to select another mail and then the encrypted mail again to decrypt it in this case.) ---------- assignedto: allen keyword: enterprise35, kde client messages: 21552 nosy: allen, ludwig, thomas priority: minor bug status: unread title: After the user enters a wrong password three times , he cannot click on decrypt again. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 9 14:57:40 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 09 Sep 2009 12:57:40 +0000 Subject: [Kolab-devel] [issue3842] After configuration of two new LDAP servers, the Addressbook view doesn't contain distribution list view and addressbook view. In-Reply-To: <1252501060.75.0.870889664686.issue3842@kolab.org> Message-ID: <1252501060.75.0.870889664686.issue3842@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090807.1020899-kk13 Switch to KAddressbook and configure two new LDAP server in the LDAP search. Press ok. => The dist list and the Kaddressbook resource list are gone. It is possible to reuse them, if I deactive and activate them in the view menu entry. So only bug. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21556 nosy: allen, ludwig priority: bug status: unread title: After configuration of two new LDAP servers, the Addressbook view doesn't contain distribution list view and addressbook view. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 9 17:16:01 2009 From: issues at kolab.org (Karl-Heinz Ruskowski) Date: Wed, 09 Sep 2009 15:16:01 +0000 Subject: [Kolab-devel] [issue3843] Address export to CVS does not include field "PostOfficeBox" In-Reply-To: <1252509361.45.0.88221056942.issue3843@kolab.org> Message-ID: <1252509361.45.0.88221056942.issue3843@kolab.org> New submission from Karl-Heinz Ruskowski : Kontact: enterprise35 20090715.996815 The CVS-export function does not include the field "PostOfficeBox" in export. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21566 nosy: allen, khruskowski, laurent, ludwig, till, tmcguire, vkrause priority: minor bug status: unread title: Address export to CVS does not include field "PostOfficeBox" ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Thu Sep 10 14:31:00 2009 From: issues at kolab.org (Ludwig Reiter) Date: Thu, 10 Sep 2009 12:31:00 +0000 Subject: [Kolab-devel] [issue3853] Crash after renaming a folder. In-Reply-To: <1252585860.81.0.594828834155.issue3853@kolab.org> Message-ID: <1252585860.81.0.594828834155.issue3853@kolab.org> New submission from Ludwig Reiter : Kontact enterprise35 20090907.1021521-kk4 Test: 1. Create folder 2. Copy some mails in it 3. Sync 4. Create fav. 5. Rename folder 6. Sync 8. Click on a mail => Crash. See backtrace. ---------- assignedto: allen files: crash-rename-20090910-1.log keyword: enterprise35, kde client messages: 21595 nosy: allen, khruskowski, ludwig, thomas, tmcguire priority: critical status: unread title: Crash after renaming a folder. ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: crash-rename-20090910-1.log Type: text/x-log Size: 2217 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090910/79cec4e4/crash-rename-20090910-1.bin From issues at kolab.org Thu Sep 10 15:54:11 2009 From: issues at kolab.org (Gunnar Wrobel) Date: Thu, 10 Sep 2009 13:54:11 +0000 Subject: [Kolab-devel] [issue3854] [kronolith] Deletion of old events via maintenance fails In-Reply-To: <1252590851.21.0.0791599523163.issue3854@kolab.org> Message-ID: <1252590851.21.0.0791599523163.issue3854@kolab.org> New submission from Gunnar Wrobel

: From http://kolab.org/pipermail/kolab-users/2009-September/010436.html Being a to trigger happy user, I had myself convinved, that enabling the "delete everything older than 365 days" in the options of horde's calendar component sounded like a good idea. Now I can't access the calendatr in horde any more. Whenever I do I am presented with "Calendar is ready to perform the maintenance operations checked below. Check the box for any operation(s) you want to perform at this time. All of your events older than 365 days will be permanently deleted." No matter what I do here (skip or perform) I'm being invariably send back to my inbox and nothing seems to happen (I currently have no access to another client than horde, so I'm not 100% sure). Question 1: Where can I reset this functionality? The calendar settings present me with the same maintenance message and subsequent failure ... Question 2: Is it possible to remove horde options that interfere/do not function along with Kolab? I'd like to contribute protecting trigger happy users like myself. ---------- assignedto: wrobel keyword: web client messages: 21601 nosy: bernhard, thomas, wilde, wrobel priority: bug status: unread title: [kronolith] Deletion of old events via maintenance fails ______________________________________ Kolab issue tracker ______________________________________ From stkunz at web.de Thu Sep 10 15:58:35 2009 From: stkunz at web.de (ASK, Stefan Kunz) Date: Thu, 10 Sep 2009 15:58:35 +0200 Subject: [Kolab-devel] Alternative mailbox login Message-ID: Hello, i try a alternative mailbox login in the kolab system to integrate. My problem is that cyrus doesn't find the mailbox and i get the error "maildrop: can't locate the mailbox" Is it possible, that a user can with two different logins and passwords to login in his mailbox. Have you any ideas to solve this problem? Thanks! Regards Stefan Kunz From wrobel at pardus.de Thu Sep 10 16:03:47 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 10 Sep 2009 16:03:47 +0200 Subject: [Kolab-devel] Alternative mailbox login In-Reply-To: References: Message-ID: <20090910160347.2036712r720h92rn@webmail.pardus.de> Hi Stefan, Quoting "ASK, Stefan Kunz" : > Hello, > > i try a alternative mailbox login in the kolab system to integrate. My > problem is that cyrus doesn't find the mailbox and i get the error > "maildrop: can't locate the mailbox" Can you elaborate on what you mean with "alternative mailbox login"? It is not quite clear to me what kind of configurations you changed. > Is it possible, that a user can with two different logins and passwords to > login in his mailbox. I think a lot should be possible via the saslauthd authentication. But I don't know if that is what you are trying to do. Cheers, Gunnar > > Have you any ideas to solve this problem? > > Thanks! > > Regards > > Stefan Kunz > > _______________________________________________ > 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 << -------------------------------------------------------------------- -------------- 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/20090910/6e467b53/attachment.bin From murch at andrew.cmu.edu Wed Sep 9 15:47:14 2009 From: murch at andrew.cmu.edu (Ken Murchison) Date: Wed, 09 Sep 2009 09:47:14 -0400 Subject: [Kolab-devel] Cyrus IMAPd 2.2.13p1 & 2.3.15 Released Message-ID: <4AA7B1E2.9010507@andrew.cmu.edu> I'd like to announce the releases of Cyrus IMAPd 2.2.13p1 and 2.3.15. These releases should both be considered production quality. These releases are being made at this time to fix the potential buffer overflow vulnerability described in CERT VU#336053: http://www.kb.cert.org/vuls/id/336053 The 2.2.13p1 release is no different from 2.2.13 other than the buffer overflow fix. The 2.3.15 release contains several other non-critical bugfixes and feature enhancements. For full details, please see doc/changes.html and doc/install-upgrade.html which are included in the distribution. I'd personally like to thank Bron Gondwana of Fastmail.fm for finding and fixing the buffer overflow, as well as his numerous other contributions to the 2.3.15 release. URLs for these releases: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.13p1.tar.gz ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.15.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.13p1.tar.gz http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.15.tar.gz Questions and comments can be directed to info-cyrus at lists.andrew.cmu.edu (public list), or cyrus-bugs at andrew.cmu.edu. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University From issues at kolab.org Thu Sep 10 09:49:50 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 07:49:50 +0000 Subject: [Kolab-devel] [issue3844] New user preference to specify order of date input fields In-Reply-To: <1252568990.4.0.00456554329507.issue3844@kolab.org> Message-ID: <1252568990.4.0.00456554329507.issue3844@kolab.org> New submission from Sönke Schwardt-Krummrich : Currently in kronolith the order of date input fields is hardcoded to year-month-day. Some parts of the world usually use a different order. The attached patch adds a user preference to specify input field order. ---------- files: t_kronolith_HK_UV_dateInputFieldOrder.diff keyword: web client messages: 21577 nosy: schwardt priority: feature status: unread title: New user preference to specify order of date input fields ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Wed Sep 9 14:43:43 2009 +0200): horde/kronolith: added preference to specify order of date input fields Currently in kronolith the order of date input fields is hardcoded to year-month-day. Some states usually use a different order. This patch adds a per user preference option to specify input field order. --- a/horde-webmail/config/prefs.php +++ b/horde-webmail/config/prefs.php @@ -105,7 +105,7 @@ $prefGroups['language'] = array( 'column' => _("Your Information"), 'label' => _("Locale and Time"), 'desc' => _("Set your preferred language, timezone and date options."), - 'members' => array('language', 'timezone', 'twentyFour', 'date_format', 'first_week_day') + 'members' => array('language', 'timezone', 'twentyFour', 'date_format', 'date_input_format', 'first_week_day') ); $prefGroups['categories'] = array( @@ -346,6 +346,21 @@ $_prefs['date_format'] = array( 'desc' => _("Choose how to display dates:"), ); +// date input format +$_prefs['date_input_format'] = array( + 'value' => 'year-month-day', + 'locked' => false, + 'shared' => true, + 'type' => 'enum', + 'enum' => array( + 'day-month-year' => strftime('%d %b %Y'), + 'month-day-year' => strftime('%b %d %Y'), + 'year-day-month' => strftime('%Y %d %b'), + 'year-month-day' => strftime('%Y %b %d'), + ), + 'desc' => _("Choose order how to enter dates:"), +); + // what day should be displayed as the first day of the week? $_prefs['first_week_day'] = array( 'value' => '0', --- a/horde-webmail/config/prefs.php.dist +++ b/horde-webmail/config/prefs.php.dist @@ -105,7 +105,7 @@ $prefGroups['language'] = array( 'column' => _("Your Information"), 'label' => _("Locale and Time"), 'desc' => _("Set your preferred language, timezone and date options."), - 'members' => array('language', 'timezone', 'twentyFour', 'date_format', 'first_week_day') + 'members' => array('language', 'timezone', 'twentyFour', 'date_format', 'date_input_format', 'first_week_day') ); $prefGroups['categories'] = array( @@ -344,6 +344,21 @@ $_prefs['date_format'] = array( 'desc' => _("Choose how to display dates:"), ); +// date input format +$_prefs['date_input_format'] = array( + 'value' => 'year-month-day', + 'locked' => false, + 'shared' => true, + 'type' => 'enum', + 'enum' => array( + 'day-month-year' => strftime('%d %b %Y'), + 'month-day-year' => strftime('%b %d %Y'), + 'year-day-month' => strftime('%Y %d %b'), + 'year-month-day' => strftime('%Y %b %d'), + ), + 'desc' => _("Choose order how to enter dates:"), +); + // what day should be displayed as the first day of the week? $_prefs['first_week_day'] = array( 'value' => '0', --- a/horde-webmail/kronolith/templates/edit/edit_timespan.inc +++ b/horde-webmail/kronolith/templates/edit/edit_timespan.inc @@ -22,11 +22,16 @@   - html('start[year]') ?> - - - html('start[month]') ?> - - - html('start[day]') ?> + getValue('date_input_format'); + $dateorder = $dateorder != "" ? $dateorder : "year-month-day"; + $dateorder = explode("-", $dateorder ); + $datefields = array(); + foreach ($dateorder as $fld) { + $datefields[] = $event->html('start['.$fld.']'); + } + echo implode("-", $datefields); + ?> hasFeature('dom')): ?> +

js('start')) . '\'); return false;') . Horde::img('calendar.png', _("Set start date"), 'id="startimg"', $GLOBALS['registry']->getImageDir('horde')) . ''; endif; ?> @@ -31,12 +42,18 @@ - +     - html('start_hour') ?> : html('start_min') ?> - hasFeature('dom')) { + echo $event->html('start_hour') . " : " . $event->html('start_min'); + } else { + echo ""; + echo Horde::link('#', _("Select a time"), '', '', 'openTimePicker(\'start_time\', \'start_time\', \'' . $GLOBALS['prefs']->getValue('twentyFour') . '\'); return false;') . Horde::img('dropdownbtn.png', _("Set start time"), 'id="startimg"', $GLOBALS['registry']->getImageDir('horde')) . ''; + + + } if (!$GLOBALS['prefs']->getValue('twentyFour')) { if ($event->start->hour < 12) { $am = ' checked="checked"'; @@ -48,7 +65,10 @@ ?> onclick="$('allday').checked=false;updateEndDate();" /> onclick="$('allday').checked=false;updateEndDate();" /> - + html('start_hour')) . str_replace('"; + + echo Horde::link('#', _("Select a time"), '', '', 'openTimePicker(\'end_time\', \'end_time\', \'' . $GLOBALS['prefs']->getValue('twentyFour') . '\'); updateTimeHourMin(\'end_time\',\'end_hour\',\'end_min\', \'' . _("Please enter correct end time!") . '\'); updateDuration(); document.eventform.end_or_dur[0].checked = true; return false;') . Horde::img('dropdownbtn.png', _("Set start time"), 'id="endimg"', $GLOBALS['registry']->getImageDir('horde')) . ''; + + } if (!$GLOBALS['prefs']->getValue('twentyFour')) { if ($event->end->hour < 12) { $am = ' checked="checked"'; @@ -103,7 +129,10 @@ endif; ?> onclick="$('end').checked=true;updateDuration()" /> onclick="$('end').checked=true;updateDuration()" /> - + html('end_hour')) . str_replace('getDuration(); if ($dur->wholeDay) echo ' checked="checked"' ?> /> -
- html('dur_day'), $event->html('dur_hour'), $event->html('dur_min')) ?> + '; ?> +html('dur_day'), $duration_div_start, $event->html('dur_hour'), $event->html('dur_min'), "") ?> hasFeature('dom')): ?> -   +   --- a/horde-webmail/kronolith/templates/edit/javascript.inc +++ b/horde-webmail/kronolith/templates/edit/javascript.inc @@ -4,6 +4,31 @@ + +function formatTime5char(hrs,mins) { +getValue('twentyFour')): ?> + if (hrs < 12) { + if (hrs == 0) { + hrs = 12; + } + } else { + if (hrs > 12) { + hrs -= 12; + } + } + + + res = mins; + if (mins < 10) { + res = "0" + res; + } + res = hrs + ":" + res; + if (hrs < 10) { + res = "0" + res; + } + return res; +} + function setInterval(field) { elt = document.eventform[field]; @@ -45,18 +70,28 @@ function clearFields(index) function setWholeDay(wholeDay) { - if (wholeDay == 1) { + if (wholeDay == true) { + $('duration_div_hrs_mins', 'end_time_row', 'start_time_row').invoke('hide'); getValue('twentyFour')): ?> $('start_hour').selectedIndex = 0; + $('start_time').value = '00:00'; + $('end_time').value = '00:00'; $('start_hour').selectedIndex = 11; + $('start_time').value = '12:00'; + $('end_time').value = '12:00'; $('am').checked = true; $('start_min').selectedIndex = 0; - $('dur_day').value = 0; - $('dur_hour').selectedIndex = 23; - $('dur_min').selectedIndex = 12; + if ($('dur_day').value < 1) { + $('dur_day').value = 1; + $('dur_hour').selectedIndex = 0; + $('dur_min').selectedIndex = 0; + } + } else { + $('duration_div_hrs_mins', 'end_time_row', 'start_time_row').invoke('show'); } + } function updateWday(span) @@ -161,14 +196,21 @@ function updateDuration() } var duration = (endDate - startDate) / 1000; - $('dur_day').value = Math.floor(duration / 86400); - duration %= 86400; - var durHour = Math.floor(duration / 3600); - duration %= 3600; - var durMin = Math.floor(duration / 60 / 5); - $('dur_hour').selectedIndex = durHour; - $('dur_min').selectedIndex = durMin; - $('allday').checked = false; + var durHour = 0; + var durMin = 0; + if ($('allday').checked == true) { + // whole day event + $('dur_day').value = Math.floor(duration / 86400) + 1; + } else { + // no whole day event + $('dur_day').value = Math.floor(duration / 86400); + duration %= 86400; + var durHour = Math.floor(duration / 3600); + duration %= 3600; + var durMin = Math.floor(duration / 60 / 5); + } + $('dur_hour').selectedIndex = durHour; + $('dur_min').selectedIndex = durMin; if (failed) { updateEndDate(); } @@ -187,7 +229,16 @@ function updateEndDate() startHour, $F('start_min')); var endDate = new Date(); - var minutes = $F('dur_day') * 1440; + if ($('allday').checked == true) { + // whole day event + if ( $('dur_day').value < 1 ) { + alert(''); + $('dur_day').value = 1; + } + var minutes = ( $F('dur_day') - 1) * 1440; + } else { + var minutes = $F('dur_day') * 1440; + } minutes += $F('dur_hour') * 60; minutes += parseInt($F('dur_min')); var msecs = minutes * 60000; @@ -216,6 +267,7 @@ function updateEndDate() $('end_hour').selectedIndex = endHour; $('end_min').selectedIndex = endDate.getMinutes() / 5; + $('end_time').value = formatTime5char(endDate.getHours(),endDate.getMinutes()); updateWday('end_wday'); } @@ -272,6 +324,7 @@ Event.observe(window, 'load', function() { toggleSection('keywords'); + setWholeDay( $('allday').checked ); }); new file mode 100644 --- /dev/null +++ b/horde-webmail/templates/javascript/time_picker.js @@ -0,0 +1,196 @@ +var TimePicker = { + targetId: null, + useTwentyFour: true, + callback_running: false, + + draw: function(posId, targetId) + { + TimePicker.targetId = targetId; + var div = document.getElementById('goto'); + if (div.firstChild) { + div.removeChild(div.firstChild); + } + + var select = document.createElement('SELECT'); + select.id = "TimePickerSelect"; + select.size = 8; + select.onchange = function() { + for (var i = 0; i < this.options.length; ++i) { + if (this.options[i].selected === true) { + var targetitem = document.getElementById( TimePicker.targetId ); + targetitem.value = this.options[i].value; + } + } + targetitem.onchange(); + + var div = document.getElementById('goto'); + div.style.display = 'none'; + if (div.firstChild) { + div.removeChild(div.firstChild); + } + var iefix = document.getElementById('goto_iefix'); + if (iefix) { + iefix.style.display = 'none'; + } + }; + + minhrs = 1; + maxhrs = 12; + if (TimePicker.useTwentyFour) { + minhrs = 0; + maxhrs = 23; + } + for (var hrs = minhrs; hrs <= maxhrs; ++hrs) { + for (var mins = 0; mins < 60; mins = mins + 5) { + cell = document.createElement('OPTION'); + + cell.value = formatTime5char(hrs, mins); + cell.innerHTML = cell.value; + + select.appendChild(cell); + } + } + div.appendChild(select); + div.style.display = ''; + div.style.position = 'absolute'; + div.style.visibility = 'visible'; + + // select current item + select.selectedIndex = 0; + select.options[0].selected = true; + var targetval = $( targetId ).value; + for (var i = 0; i <= select.options.length; ++i) { + if (select.options[i].value >= targetval) { + select.selectedIndex = i; + select.options[i].selected = true; + select.value = select.options[select.selectedIndex].value; + i = select.options.length; + } + } + + + // Position the popup every time in case of a different input, + // window sizing changes, etc. + var el = document.getElementById(posId); + var p = TimePicker.getAbsolutePosition(el); + + if (p.x + div.offsetWidth > document.body.offsetWidth) { + l = (document.body.offsetWidth - 10 - div.offsetWidth); + if (l < 0) { + l = 0; + } + div.style.left = l + 'px'; + } else { + div.style.left = p.x + 'px'; + } + if (p.y + div.offsetHeight > document.body.offsetHeight) { + t = (document.body.offsetHeight - 10 - div.offsetHeight); + if (t < 0) { + t = 0; + } + div.style.top = t + 'px'; + } else { + div.style.top = p.y + 'px'; + } + + // Browser sniff for IE taken from Prototype. + if (!!(window.attachEvent && !window.opera)) { + // Fix for IE and select elements. + iefix = document.getElementById('goto_iefix'); + if (!iefix) { + iefix = document.createElement('IFRAME'); + iefix.id = 'goto_iefix'; + iefix.src = 'javascript:return false;'; + iefix.scrolling = 'no'; + iefix.frameborder = 0; + iefix.style.display = 'none'; + iefix.style.position = 'absolute'; + document.body.appendChild(iefix); + } + iefix.style.width = div.offsetWidth; + iefix.style.height = div.offsetHeight; + iefix.style.top = div.style.top; + iefix.style.left = div.style.left; + + if (div.style.zIndex === '') { + div.style.zIndex = 2; + iefix.style.zIndex = 1; + } else { + iefix.style.zIndex = div.style.zIndex - 1; + } + iefix.style.display = ''; + } + }, + + getAbsolutePosition: function(el) + { + var r = { x: el.offsetLeft, y: el.offsetTop }; + if (el.offsetParent) { + var tmp = TimePicker.getAbsolutePosition(el.offsetParent); + r.x += tmp.x; + r.y += tmp.y; + } + return r; + }, + + setSelectValue: function(select, value) + { + select.value = value; + if (select.value != value) { + for (var i = 0; i < select.options.length; ++i) { + if (select.options[i].value == value) { + select.selectedIndex = i; + return true; + } + } + } + return false; + } +}; + +function updateHourMinTime(hourId, minId, timeId) { + timeitem = document.getElementById(timeId); + houritem = document.getElementById(hourId); + minitem = document.getElementById(minId); + + hrs = houritem.value; + if (!TimePicker.useTwentyFour) { + if (hrs > 12) { + hrs = hrs - 12; + } + } + + timeitem.value = formatTime5char(hrs, minitem.value); +} + +function updateTimeHourMin(timeId, hourId, minId, msg) { + timeitem = document.getElementById(timeId); + houritem = document.getElementById(hourId); + minitem = document.getElementById(minId); + + Ergebnis = timeitem.value.match(/^(2[0123]|[01]\d|\d):[0-5]\d$/); + if (!Ergebnis) { + if (!msg) { + msg = "Please enter correct time!"; + } + alert(msg); + return ; + } + + items = timeitem.value.split(':'); + if (items[0].charAt(0) == '0') { + items[0] = items[0].charAt(1); + } + if (items[1].charAt(0) == '0') { + items[1] = items[1].charAt(1); + } + TimePicker.setSelectValue(houritem, parseInt(items[0], 10)); + TimePicker.setSelectValue(minitem, parseInt(items[1], 10)); +} + +function openTimePicker(posId, targetId, useTwentyFour) { + if (!(useTwentyFour)) { + TimePicker.useTwentyFour = false; + } + TimePicker.draw(posId, targetId); +} From issues at kolab.org Thu Sep 10 10:14:35 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 08:14:35 +0000 Subject: [Kolab-devel] [issue3848] display "Basic Search" and "Advanced Search" as tabs in place of a small table header. In-Reply-To: <1252570475.6.0.87898525825.issue3848@kolab.org> Message-ID: <1252570475.6.0.87898525825.issue3848@kolab.org> New submission from Sönke Schwardt-Krummrich : In kronolith currently the clickable headlines "Basic Search" and "Advanced Search" are displayed in a small header line. One on the left side, one on the right side. This patch displays these links as tabs side by side. ---------- files: t_kronolith_HK_UV_searchTabs.diff keyword: web client messages: 21581 nosy: schwardt priority: feature status: unread title: display "Basic Search" and "Advanced Search" as tabs in place of a small table header. ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Tue Sep 8 17:34:44 2009 +0200): kronolith: display "Basic Search" and "Advanced Search" as tabs in place of a small table header. --- a/horde-webmail/kronolith/templates/search/search.inc +++ b/horde-webmail/kronolith/templates/search/search.inc @@ -4,13 +4,17 @@ -

-

- - - - -

+addTab(_("Basic Search"), $sUrl, 'basic'); +$tabs->addTab(_("Advanced Search"), $sUrl, 'advanced'); +echo $tabs->render('basic'); +?>
--- a/horde-webmail/kronolith/templates/search/search_advanced.inc +++ b/horde-webmail/kronolith/templates/search/search_advanced.inc @@ -3,14 +3,17 @@ -

-

- - - - -

- +addTab(_("Basic Search"), $sUrl, 'basic'); +$tabs->addTab(_("Advanced Search"), $sUrl, 'advanced'); +echo $tabs->render('advanced'); +?>
From issues at kolab.org Thu Sep 10 10:24:29 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 08:24:29 +0000 Subject: [Kolab-devel] [issue3849] new config switch to display event's time range in day/workweek/week view In-Reply-To: <1252571069.54.0.161989339836.issue3849@kolab.org> Message-ID: <1252571069.54.0.161989339836.issue3849@kolab.org> New submission from Sönke Schwardt-Krummrich : In day/workweek/week view of kronolith it's currently impossible distinct between events starting/ending at complete hours (e.g. 11:00) and events starting/ending with offset (e.h. 11:15). This patch adds a new config option to display the events start/end time additionally to existing event title in day/workweek/week view. ---------- files: t_kronolith_HK_UV_display_inline_time.diff keyword: web client messages: 21584 nosy: schwardt priority: feature status: unread title: new config switch to display event's time range in day/workweek/week view ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Wed Sep 9 12:12:26 2009 +0200): kronolith: new config switch to display event's time range in day/workweek/week view In day/workweek/week view it's currently impossible distinct between events starting/ending at complete hours and events starting/ending with offset. This patch adds a new config option to display the events start/end time additionally to existing event title. --- a/horde-webmail/kronolith/config/conf.php +++ b/horde-webmail/kronolith/config/conf.php @@ -2,6 +2,8 @@ /* CONFIG START. DO NOT CHANGE ANYTHING IN OR AFTER THIS LINE. */ // $Horde: kronolith/config/conf.xml,v 1.14.10.5 2007/12/20 14:12:23 jan Exp $ $conf['calendar']['driver'] = 'kolab'; +$conf['calendar']['day']['inline_time'] = false; +$conf['calendar']['week']['inline_time'] = false; $conf['storage']['driver'] = 'kolab'; $conf['storage']['default_domain'] = ''; $conf['storage']['freebusy']['protocol'] = 'https'; --- a/horde-webmail/kronolith/config/conf.xml +++ b/horde-webmail/kronolith/config/conf.xml @@ -16,6 +16,15 @@ + + + Display Settings For Week View + false + + + Display Settings For Day View + false + --- a/horde-webmail/kronolith/lib/Driver.php +++ b/horde-webmail/kronolith/lib/Driver.php @@ -2214,7 +2214,7 @@ class Kronolith_Event { return Horde::applicationUrl(Util::addParameter('event.php', $params)); } - function getLink($timestamp = null, $icons = true, $from_url = null, $full = false) + function getLink($timestamp = null, $icons = true, $from_url = null, $full = false, $inline_time = false) { global $prefs, $registry; @@ -2226,7 +2226,11 @@ class Kronolith_Event { } $link = ''; - $event_title = $this->getTitle(); + if ( $inline_time ) { + $event_title = $this->getTitle() . " " . $this->getTimeRange(); + } else { + $event_title = $this->getTitle(); + } if (isset($this->external)) { $link = $registry->link($this->external . '/show', $this->external_params); $link = Horde::linkTooltip(Horde::url($link), '', 'event-tentative', '', '', String::wrap($this->description)); --- a/horde-webmail/kronolith/lib/Views/Day.php +++ b/horde-webmail/kronolith/lib/Views/Day.php @@ -70,6 +70,7 @@ class Kronolith_View_Day extends Kronolith_Day { function html() { global $prefs; + global $conf; if (!$this->_parsed) { $this->parse(); @@ -237,7 +238,7 @@ class Kronolith_View_Day extends Kronolith_Day { $row .= '
' - . $event->getLink($this->getStamp(), true, $this->link(0, true)); + . $event->getLink($this->getStamp(), true, $this->link(0, true), false, isset($conf['calendar']['day']['inline_time']) ? $conf['calendar']['day']['inline_time'] : false ); if ($showTime) { $row .= '
' . htmlspecialchars($event->getTimeRange()) . '
'; } --- a/horde-webmail/kronolith/lib/Views/Week.php +++ b/horde-webmail/kronolith/lib/Views/Week.php @@ -117,6 +117,7 @@ class Kronolith_View_Week { function html() { global $prefs; + global $conf; $more_timeslots = $prefs->getValue('time_between_days'); $include_all_events = !$prefs->getValue('show_shared_side_by_side'); @@ -170,7 +171,7 @@ class Kronolith_View_Week { $row .= '
' - . $event->getLink($this->days[$j]->getStamp(), true, $this->link(0, true)); + . $event->getLink($this->days[$j]->getStamp(), true, $this->link(0, true), false, isset($conf['calendar']['week']['inline_time']) ? $conf['calendar']['week']['inline_time'] : false); if ($showLocation) { $row .= '
' . htmlspecialchars($event->getLocation()) . '
'; } @@ -292,7 +293,7 @@ class Kronolith_View_Week { . 'valign="top" ' . 'width="' . floor(((90 / count($this->days)) / count($this->_currentCalendars)) * ($span / $this->days[$j]->_span[$cid])) . '%" ' . 'colspan="' . $span . '" rowspan="' . $event->rowspan . '">' - . $event->getLink($this->days[$j]->getStamp(), true, $this->link(0, true)); + . $event->getLink($this->days[$j]->getStamp(), true, $this->link(0, true), false, isset($conf['calendar']['week']['inline_time']) ? $conf['calendar']['week']['inline_time'] : false); if ($showTime) { $row .= '
' . htmlspecialchars($event->getTimeRange()) . '
'; } From issues at kolab.org Thu Sep 10 10:32:38 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 08:32:38 +0000 Subject: [Kolab-devel] [issue3850] new hook to create display names for personal/shared calendars individually In-Reply-To: <1252571558.96.0.144464704192.issue3850@kolab.org> Message-ID: <1252571558.96.0.144464704192.issue3850@kolab.org> New submission from Sönke Schwardt-Krummrich : In some cases displaying owner and full name of shared calendars is not appreciated or confusing for users (e.g. "[some.admin at example.com] user:someadmin:vacation-calendar"). The optional hook, added with this patch, provides the ability to format the display name to ones own needs (e.g. a simple "vacation-calendar") while other calendars remain untouched. This patch also adds an additional hook for modifying display names of personal calendars. ---------- files: t_kronolith_HK_UV_calendarDisplayNameHook.diff keyword: web client messages: 21585 nosy: schwardt status: unread title: new hook to create display names for personal/shared calendars individually ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Wed Sep 9 17:29:45 2009 +0200): kronolith: added hook to create display names for personal/shared calendars individually In some cases displaying owner and full name of shared calendars is not appreciated or confusing for users (e.g. "[some.admin at example.com] user:someadmin:vacation-calendar"). The optional hook, added with this patch, provides the ability to format the display name to ones own needs (e.g. a simple "vacation-calendar") while other calendars remain untouched. This patch adds an additional hook for modifying display names of personal calendars. --- a/horde-webmail/kronolith/config/conf.xml +++ b/horde-webmail/kronolith/config/conf.xml @@ -111,4 +111,15 @@ + + + + false + false + + new file mode 100644 --- /dev/null +++ b/horde-webmail/kronolith/config/hooks.php @@ -0,0 +1,34 @@ +get('owner'))) . '] ' . htmlspecialchars($cal->get('name')) ; +// } +// } + +// Example hook for building display name of shared calendars in kronolith + +// if (!function_exists('_kronolith_build_shared_calendar_display_name')) { +// function _kronolith_build_shared_calendar_display_name($id = null, $cal = null) +// { +// return '[' . htmlspecialchars(Auth::removeHook($cal->get('owner'))) . '] ' . htmlspecialchars($cal->get('name')) ; +// } +// } + +if (file_exists(dirname(__FILE__) . '/hooks.local.php')) { + require_once(dirname(__FILE__) . '/hooks.local.php'); +} new file mode 100644 --- /dev/null +++ b/horde-webmail/kronolith/config/hooks.php.dist @@ -0,0 +1,34 @@ +get('owner'))) . '] ' . htmlspecialchars($cal->get('name')) ; +// } +// } + +// Example hook for building display name of shared calendars in kronolith + +// if (!function_exists('_kronolith_build_shared_calendar_display_name')) { +// function _kronolith_build_shared_calendar_display_name($id = null, $cal = null) +// { +// return '[' . htmlspecialchars(Auth::removeHook($cal->get('owner'))) . '] ' . htmlspecialchars($cal->get('name')) ; +// } +// } + +if (file_exists(dirname(__FILE__) . '/hooks.local.php')) { + require_once(dirname(__FILE__) . '/hooks.local.php'); +} --- a/horde-webmail/kronolith/templates/panel.inc +++ b/horde-webmail/kronolith/templates/panel.inc @@ -41,7 +41,14 @@ foreach (Kronolith::listCalendars() as $id => $cal) {

    $cal): ?> -
  • + get('name')) ; + } + ?> +
@@ -50,7 +57,14 @@ foreach (Kronolith::listCalendars() as $id => $cal) {

    $cal): ?> -
  • + get('owner'))) . '] ' . htmlspecialchars($cal->get('name')) ; + } + ?> +
From issues at kolab.org Thu Sep 10 10:36:07 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 08:36:07 +0000 Subject: [Kolab-devel] [issue3851] add ability to display "0 minutes before incident" alarms In-Reply-To: <1252571767.79.0.35272688689.issue3851@kolab.org> Message-ID: <1252571767.79.0.35272688689.issue3851@kolab.org> New submission from Sönke Schwardt-Krummrich : currently horde treats alarms that should occur 0 minutes before the specific incident as disabled alarms. This patch adds a distiction between disabled alarms and "0 minutes alarms". ---------- files: t_kronolith_HK_UV_addZeroMinutesAlarms.diff keyword: web client messages: 21587 nosy: schwardt priority: feature status: unread title: add ability to display "0 minutes before incident" alarms ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Tue Sep 8 17:53:51 2009 +0200): kronolith: add ability to display "0 minutes before incident" alarms currently horde treats alarms that should occur 0 minutes before the specific incident as disabled alarms. This patch adds a distiction between them. --- a/horde-webmail/kronolith/lib/Block/monthlist.php +++ b/horde-webmail/kronolith/lib/Block/monthlist.php @@ -119,7 +119,7 @@ class Horde_Block_Kronolith_monthlist extends Horde_Block { $event->end = new Horde_Date($tomorrow12am); } if (($event->end->timestamp() < $now && !$event->isAllDay()) || - ($prefs->getValue('summary_alarms') && !$event->alarm)) { + ($prefs->getValue('summary_alarms') && (!isset($event->alarm) || $event->alarm === ''))) { continue; } --- a/horde-webmail/kronolith/lib/Driver.php +++ b/horde-webmail/kronolith/lib/Driver.php @@ -415,7 +415,7 @@ class Kronolith_Event { * * @var integer */ - var $alarm = 0; + var $alarm = null; /** * The identifier of the calender this event exists on. @@ -732,7 +732,7 @@ class Kronolith_Event { } // Alarms. - if (!empty($this->alarm)) { + if (isset($this->alarm) && $this->alarm !== '') { if ($v1) { $vEvent->setAttribute('AALARM', $this->start->timestamp() - $this->alarm * 60); } else { @@ -1108,7 +1108,7 @@ class Kronolith_Event { 'sec' => $time[2])); } } - if (!empty($hash['alarm'])) { + if (isset($hash['alarm']) && $hash['alarm'] !== '') { $this->setAlarm($hash['alarm']); } elseif (!empty($hash['alarm_date']) && !empty($hash['alarm_time'])) { @@ -1150,7 +1150,8 @@ class Kronolith_Event { */ function toAlarm($time, $user = null, $prefs = null) { - if (!$this->getAlarm()) { + file_put_contents ('/tmp/test', 'asdf '.$this->getAlarm(), FILE_APPEND); + if ($this->getAlarm() === null || $this->getAlarm() === '') { return; } @@ -1840,7 +1841,7 @@ class Kronolith_Event { if (Util::getFormData('alarm') == 1) { $this->setAlarm(Util::getFormData('alarm_value') * Util::getFormData('alarm_unit')); } else { - $this->setAlarm(0); + $this->setAlarm(null); } // Recurrence. @@ -2244,8 +2245,13 @@ class Kronolith_Event { ($GLOBALS['cManager_fgColors']['_default_'] == '#000' ? '000' : 'fff'); $status = ''; - if ($this->alarm) { - if ($this->alarm % 10080 == 0) { + if (isset($this->alarm) && $this->alarm !== '') { + if ($this->alarm === 0) { + $alarm_value = $this->alarm; + $title = $alarm_value == 1 ? + _("Alarm 1 minute before") : + sprintf(_("Alarm %d minutes before"), $alarm_value); + } elseif ($this->alarm % 10080 == 0) { $alarm_value = $this->alarm / 10080; $title = $alarm_value == 1 ? _("Alarm 1 week before") : --- a/horde-webmail/kronolith/lib/Driver/kolab.php +++ b/horde-webmail/kronolith/lib/Driver/kolab.php @@ -495,7 +495,9 @@ class Kronolith_Driver_kolab_wrapper_old extends Kronolith_Driver_kolab_wrapper $organizer = &$this->_kolab->initRootElem('organizer'); $this->_kolab->setElemStr($organizer, 'smtp-address', $event->getCreatorID()); - $this->_kolab->setVal('alarm', $event->getAlarm()); + if ($event->getAlarm () !== null && $event->getAlarm () !== '') { + $this->_kolab->setVal('alarm', $event->getAlarm()); + } if ($event->isAllDay()) { $this->_kolab->setVal('start-date', Kolab::encodeDate($event->start->timestamp())); $this->_kolab->setVal('end-date', Kolab::encodeDate($event->end->timestamp()-24*60*60)); @@ -786,7 +788,11 @@ class Kronolith_Event_kolab_old extends Kronolith_Event { $organizer = &$kolab->getRootElem('organizer'); $this->creatorID = $kolab->getElemStr($organizer, 'smtp-address'); - $this->alarm = $kolab->getVal('alarm'); + if ($kolab->getVal('alarm') !== null && $kolab->getVal('alarm') !== '') { + $this->alarm = $kolab->getVal('alarm'); + } else { + $this->alarm = $kolab->getVal('alarm'); + } $this->start = new Horde_Date(Kolab::decodeDateOrDateTime($kolab->getVal('start-date'))); $this->end = new Horde_Date(Kolab::decodeFullDayDate($kolab->getVal('end-date'))); $this->durMin = ($this->end->timestamp() - $this->start->timestamp()) / 60; @@ -1144,7 +1150,7 @@ class Kronolith_Driver_kolab_wrapper_new extends Kronolith_Driver_kolab_wrapper $ids = array(); foreach($this->_events_cache as $event) { - if ($hasAlarm && !$event->getAlarm()) { + if ($hasAlarm && ($event->getAlarm() === null || $event->getAlarm() == '')) { continue; } @@ -1457,8 +1463,7 @@ class Kronolith_Event_kolab_new extends Kronolith_Event { $this->creatorID = $event['organizer']['smtp-address']; } } - - if (isset($event['alarm'])) { + if (isset($event['alarm']) && $event['alarm'] !== '') { $this->alarm = $event['alarm']; } @@ -1570,7 +1575,11 @@ class Kronolith_Event_kolab_new extends Kronolith_Event { $event['organizer'] = $organizer; } - if ($this->alarm != 0) { + if (!isset($this->alarm) || $this->alarm === '') { + file_put_contents ('/tmp/out', "no this->alarm\n", FILE_APPEND); + $event['alarm'] = null; + } else { + file_put_contents ('/tmp/out', "this->alarm\n", FILE_APPEND); $event['alarm'] = $this->alarm; } --- a/horde-webmail/kronolith/lib/Driver/sql.php +++ b/horde-webmail/kronolith/lib/Driver/sql.php @@ -967,7 +967,8 @@ class Kronolith_Event_sql extends Kronolith_Event { $this->_properties['event_end'] = date('Y-m-d H:i:s', $this->end->timestamp()); /* Alarm. */ - $this->_properties['event_alarm'] = (int)$this->getAlarm(); + if ($this->getAlarm() !== null && $this->getAlarm() !== '') + $this->_properties['event_alarm'] = $this->getAlarm(); /* Recurrence. */ if (!$this->recurs()) { --- a/horde-webmail/kronolith/templates/edit/edit.inc +++ b/horde-webmail/kronolith/templates/edit/edit.inc @@ -133,9 +133,12 @@
alarm) { + if (isset($event->alarm) && $event->alarm !== '') { $alarm_set = true; - if ($event->alarm % 10080 == 0) { + if ((int)$event->alarm === 0) { + $alarm_value = $event->alarm; + $alarm_unit = 'min'; + } elseif ($event->alarm % 10080 == 0) { $alarm_value = $event->alarm / 10080; $alarm_unit = 'week'; } elseif ($event->alarm % 1440 == 0) { --- a/horde-webmail/kronolith/templates/prefs/default_alarm_management.inc +++ b/horde-webmail/kronolith/templates/prefs/default_alarm_management.inc @@ -1,10 +1,12 @@ isLocked('default_alarm')): $alarm_value = $prefs->getValue('default_alarm'); -if (!$alarm_value) { +if (!isset($alarm_value) || $alarm_value === '') { $alarm_unit = 'min'; } else { - if ($alarm_value % 10080 == 0) { + if ($alarm_value === 0) { + $alarm_unit = 'min'; + } elseif ($alarm_value % 10080 == 0) { $alarm_value /= 10080; $alarm_unit = 'week'; } elseif ($alarm_value % 1440 == 0) { --- a/horde-webmail/kronolith/templates/view/view.inc +++ b/horde-webmail/kronolith/templates/view/view.inc @@ -47,8 +47,11 @@    event->isInitialized() && $this->event->alarm > 0): - if ($this->event->alarm % 10080 == 0) { +if ($this->event->isInitialized() && isset($this->event->alarm) && $this->event->alarm !== ''): + if ((int)$this->event->alarm === 0) { + $alarm_value = $this->event->alarm; + $alarm_unit = _("Minute(s)"); + } elseif ($this->event->alarm % 10080 == 0) { $alarm_value = $this->event->alarm / 10080; $alarm_unit = _("Week(s)"); } elseif ($this->event->alarm % 1440 == 0) { From issues at kolab.org Thu Sep 10 14:13:33 2009 From: issues at kolab.org (issues@kolab.org) Date: Thu, 10 Sep 2009 12:13:33 +0000 Subject: [Kolab-devel] [issue3852] turba: add objectclass filter to search criteria In-Reply-To: <1252584813.65.0.907664244423.issue3852@kolab.org> Message-ID: <1252584813.65.0.907664244423.issue3852@kolab.org> New submission from Sönke Schwardt-Krummrich : While searching turba uses either an objectclass filter or user defined criteria but not both. When searching for "name" all ldap object with matching "cn" attribute will show up. Selecting one returns a "no result" message. This patch adds the objectclass filter if definded, so only valid address book entries are shown. ---------- files: t_turba_HK_UV_addObjectclassFilter.diff keyword: web client messages: 21594 nosy: schwardt priority: minor bug status: unread title: turba: add objectclass filter to search criteria ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Thu Sep 10 11:34:08 2009 +0200): turba: add objectclass filter to search criteria While searching turba uses either an objectclass filter or user defined criteria but not both. When searching for "name" all ldap object with matching "cn" attribute will show up. Selecting one returns a "no result" message. This patch adds the objectclass filter if definded, so only valid address book entries are shown. --- a/horde-webmail/turba/lib/Driver/ldap.php +++ b/horde-webmail/turba/lib/Driver/ldap.php @@ -155,6 +155,10 @@ class Turba_Driver_ldap extends Turba_Driver { $filter .= '(&' . $this->_buildSearchQuery($vals) . ')'; } } + $objfilter = $this->_buildObjectclassFilter(); + if (!empty($objfilter)) { + $filter = '(&' . $filter . $objfilter . ')'; + } } else { /* Filter on objectclass. */ $filter = $this->_buildObjectclassFilter(); From wrobel at pardus.de Thu Sep 10 17:41:34 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Thu, 10 Sep 2009 17:41:34 +0200 Subject: [Kolab-devel] Remote Microsoft Exchange freebusy fetching in Kolab_Freebusy In-Reply-To: <960738410908260002j3cbb64b7r72ef81b1311492c4@mail.gmail.com> References: <960738410908260002j3cbb64b7r72ef81b1311492c4@mail.gmail.com> Message-ID: <20090910174134.17411vvn1t1jbw3o@webmail.pardus.de> Hi Mathieu, Quoting Mathieu Parent : > Hello, > > Currently, retrieving freebusy information only works for users > present in the LDAP directory and having an IMAP folder following > Kolab XML format and annotations. I need to extend this to get > freebusy data from Exchange 2007 servers which shares the same mail > domain as our Kolab servers. This is a very specific request, but it > is covered by two more general features : > - retrieve freebusy information from servers outside the Kolab "cluster" > - retrieve freebusy information from other formats > > Proposed implementation : > - add an "Outlook Web Access" format in Kolab_Format for freebusy > information (probably in lib/Horde/Kolab/Format/OWA.php, inheriting > Horde_Kolab_Format_XML or not). More info on the format [owa-format] > - change Horde_Kolab_FreeBusy_Access::_process to allow fallback when > no user is found in LDAP and a hook is defined. The hook will return a > freebusyserver and a freebusyservertype (owa for MS exchange, ifb for > remote, imap for local) based on uid/mail > - change Horde_Kolab_FreeBusy_Access::fetchRemote to redirect only if > freebusyservertype is ifb, error only if freebusyserver is not set. > - change Freebusy/Cache.php to use Horde_Kolab_FreeBusy_xx class (Imap > or OWA) depending on freebusyservertype > - create Horde_Kolab_FreeBusy_OWA class, using Horde_Kolab_Format_OWA > > With this proposal it will be possible in the future to add connectors > for other mail servers. > > As this changes a lot of the existing code, I first need to know if > the proposal is ok or if there is a better solution (I'm mostly asking > Gunnar as the main developer of those horde parts). As discussed on IRC this sounds good to me. You should probably add an issue for this feature and post your patches there. For completenes: our IRC discussion log. 17:15 sathieu: If I understand you correctly then the set of users on the exchange server should be available to ALL users on your Kolab server, right? 17:16 yes 17:17 sathieu: so I think it does not belong into the IMAP folders. In principle the IMAP folders should store information that is owned by the users (or a group of users). System-wide data usually finds a better place in LDAP. 17:17 sathieu: the other things look okay to me (the extensions to the FreeBusy classes. 17:18 sathieu: especially having a hook extension possibility for the remote f/b lists sounds good 17:18 sathieu: do you think you could store the required information about remote exchange based f/b lists also in LDAP? 17:19 what do you mean by "it does not belong into the IMAP folders"? you are talking about the cache? 17:23 sathieu: ah, I misunderstood your first point. The fact that you wanted to use Kolab XML format (which you probably don't want) did make me believe you wanted to store the user mapping as groupware objects in an IMAP folder. But I see now that the Free/Busy format is in XML. 17:26 sathieu: So I think the proposal makes sense. You wanted to code this, right? What was your timeframe on this? 17:26 what is the best solution, inherit Horde_Kolab_Format_XML or not ? 17:26 sathieu: I guess it would not inherit from Horde_Kolab_Format_XML. This class is specifically meant for the Kolab groupware objects and I wouldn't use it for general XML parsing. 17:28 sathieu: I think it makes sense if OWA parsing would live in the Kolab_FreeBusy package. 17:28 sathieu: Or is it that common that it warrants its own package? 17:29 I will code this at work, probably. We are planning migration from M$ Exchange 5.5 to Kolab in the beginning of 2010. 17:32 we will use Debian native packages, they lack some stuff in the webclient part now.... 17:33 sathieu: Okay, so you should code for Horde 3. I am currently cleaning and restructuring the package for Horde 4. I don't think it should be too hard to merge your patches though. 17:33 wrobel: will kolab 2.3 be with horde 3 or 4? 17:38 sathieu: 2.3 will be horde3. I plan to have the first set of test packages for Horde 4 in early 2010. But this will be test stuff and not part of the current server. Horde 4 is still in early alpha. The plan is to support Horde3 until the middle of 2011 on the Kolab Server (albeit it still has many shortcomings). > > Mathieu Parent > > [owa-format]: > http://www.infinitec.de/post/2004/12/30/Retrieving-a-users-availability-(freebusy-data).aspx > http://wiki.zimbra.com/index.php?title=Troubleshooting_Exchange_Freebusy_Interop > > _______________________________________________ > 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 << -------------------------------------------------------------------- -------------- 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/20090910/bd49b6ef/attachment.bin From stkunz at web.de Thu Sep 10 21:33:36 2009 From: stkunz at web.de (Stefan Kunz) Date: Thu, 10 Sep 2009 21:33:36 +0200 Subject: [Kolab-devel] Alternative mailbox login In-Reply-To: <20090910160347.2036712r720h92rn@webmail.pardus.de> Message-ID: Hi Gunnar, i have add manually a new user in the ldap. This user can authenticate via saslauth, but cyrus doesn't find the mailbox, because i have not defined mail attribute in the new ldap entry. My problem is that the mail attribute in ldap must be unique, else no success authentication is possible. I tried something with ldap_filter in saslauth.conf though without success. Apparently cyrus read the mail attribute from ldap to find the mailbox. Cyrus passes the e-mail-address to saslauth, when the mail attribute is found. So the parameter %u, %r in ldap_filter have the value viz the e-mail-adress. So it is difficult, the correct ldap entry filtered to authenticate. Have you any tip for me, how cyrus find the mailbox from another ldap attribute, so the same mailbox open with two different usernames bzw. passwords. Regards Stefan From issues at kolab.org Fri Sep 11 10:52:26 2009 From: issues at kolab.org (Marc Mutz) Date: Fri, 11 Sep 2009 08:52:26 +0000 Subject: [Kolab-devel] [issue3855] [regression] S/MIME opaque signed and encrypted email suboptimal display In-Reply-To: <1252659146.54.0.381269175675.issue3855@kolab.org> Message-ID: <1252659146.54.0.381269175675.issue3855@kolab.org> New submission from Marc Mutz : (discovered while fixing issue 3577) Even with the smime-data parameter preserved, when clicking on the "Decrypt Message" link of a S/MIME opaque (tested: S+E'ed, probably others) message, the display does _not_ show the usual "please wait while decrypting..." message, but an smime signature icon and "cannot decrypt". This seems to be a regression from the async reader work. ---------- assignedto: bernhard keyword: crypto, enterprise35, kde client messages: 21614 nosy: allen, bernhard, bh, ludwig, marc, till priority: urgent status: testing title: [regression] S/MIME opaque signed and encrypted email suboptimal display ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Fri Sep 11 12:33:14 2009 From: issues at kolab.org (Thomas Arendsen Hein) Date: Fri, 11 Sep 2009 10:33:14 +0000 Subject: [Kolab-devel] [issue3856] IMP/DIMP folder navigator does not allow creating/deleting/... mail folders In-Reply-To: <1252665194.26.0.116627973974.issue3856@kolab.org> Message-ID: <1252665194.26.0.116627973974.issue3856@kolab.org> New submission from Thomas Arendsen Hein : The web client (imp, I did not check dimp) in Kolab Server 2.2.0 the Folder Navigator offered Create/Rename/Delete/Empty In 2.2.2's imp and dimp these 4 options are not available (the other 10 are). While dimp offers a "New Folder" button in the side navigation bar to workaround this problem, creating new mail folders in imp is impossible. Should be fixed in 2.2 branch (and of course HEAD, if it is affected, too) ---------- assignedto: wrobel keyword: release, web client messages: 21629 nosy: martin, thomas, wilde, wrobel priority: urgent status: unread title: IMP/DIMP folder navigator does not allow creating/deleting/... mail folders ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Fri Sep 11 14:56:30 2009 From: issues at kolab.org (Ludwig Reiter) Date: Fri, 11 Sep 2009 12:56:30 +0000 Subject: [Kolab-devel] [issue3857] anniversary day event doesn't contain the contact's name, if a second dimap account is used. In-Reply-To: <1252673790.5.0.213005962121.issue3857@kolab.org> Message-ID: <1252673790.5.0.213005962121.issue3857@kolab.org> New submission from Ludwig Reiter : observed with Kontact e4 20090907-1 The user has two dimap accounts configured, both with contacts. He activate the birthday resource. The anniversary days of the second dimap account don't contain the names of the contacts in the German translation. E.g. Testy Test with partner Testy2 Test2. The anniversary is just: "Testy2 Test2's anniversary", if Testy Test is a contact from the second dimap account. ---------- assignedto: allen keyword: enterprise4, kde client messages: 21638 nosy: allen, ludwig, thomas priority: minor bug status: unread title: anniversary day event doesn't contain the contact's name, if a second dimap account is used. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Fri Sep 11 15:37:23 2009 From: issues at kolab.org (Ludwig Reiter) Date: Fri, 11 Sep 2009 13:37:23 +0000 Subject: [Kolab-devel] [issue3858] export calendar as web page: In the export dialog a wrong file selection dialog is used. In-Reply-To: <1252676243.1.0.923672282252.issue3858@kolab.org> Message-ID: <1252676243.1.0.923672282252.issue3858@kolab.org> New submission from Ludwig Reiter : observed with Kontact e4 200900907-1 of tag 20090907.1020969 Test: 1. Switch to Calendar. 2. Export->As Web page... 3. Try to enter a new file into the save to field using the file dialog. => This doesn't work, because the dialog is a file open not a file selection dialog. ---------- assignedto: allen keyword: enterprise4, kde client messages: 21643 nosy: allen, ludwig priority: minor bug status: unread title: export calendar as web page: In the export dialog a wrong file selection dialog is used. ______________________________________ Kolab issue tracker ______________________________________ From wrobel at pardus.de Fri Sep 11 16:08:19 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 11 Sep 2009 16:08:19 +0200 Subject: [Kolab-devel] shared calendar as long time reminding system? In-Reply-To: <200909110849.51109.bernhard@intevation.de> References: <200909101012.18927.thorsten.schnebeck@gmx.net> <200909101210.59711.bernhard@intevation.de> <20090910162344.150661uw9t35vnxs@webmail.pardus.de> <200909110849.51109.bernhard@intevation.de> Message-ID: <20090911160819.12783mk14wbdc14w@webmail.pardus.de> Quoting Bernhard Reiter : > Am Donnerstag, 10. September 2009 16:23:44 schrieb Gunnar Wrobel: >> > I guess the hackish solution would be to make sure a webclient is running >> > all the time that has access to the folder and will just send out emails >> > for each reminder. You might need a script to keep the horde sessing >> > alive, though. >> >> I think the Horde Alarm system allows setting up email reminders >> via a cron job. > > From the concept side I do not see how this could work reliably. > In order to read a folder, any client would need the users credentials > which should only be kept in memory as long as the client is active. > A cron job is another client and it dies not have the credentials to access > the folder of any user. Correct. The current reminder script is targeted at the SQL-Installation and the assumption is that you have an admin user that can read all events. This is easy for SQL but not the case if you have IMAP. We do however already employ some kind of shared access for our resource accounts on the Kolab server. And often is might also be sufficient if there is only one specific user sending out reminders. In these limited cases you could provide the corresponding credentials for the cron job in a config file. I had hoped the current reminder script allows something like that. Cheers, Gunnar > > (And we should move the implementation details to the kolab-devel@ list.) > >> @Thorsten: Can you check section 4.4 ("Setting up reminder emails") of >> >> http://www.horde.org/kronolith/docs/?f=INSTALL.html >> >> and test if that works with the Kolab server? I admit I didn't test >> this yet but if you start testing that I'll promise to help along >> to get it working. It would be useful to add the necessary >> configuration into the Kolab Server configuration templates (or at >> least into the wiki). > > > -- > 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 > -- ______ 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 << -------------------------------------------------------------------- -------------- 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/20090911/118b9da0/attachment.bin From wrobel at pardus.de Fri Sep 11 16:13:45 2009 From: wrobel at pardus.de (Gunnar Wrobel) Date: Fri, 11 Sep 2009 16:13:45 +0200 Subject: [Kolab-devel] shared calendar as long time reminding system? In-Reply-To: <200909101210.59711.bernhard@intevation.de> References: <200909101012.18927.thorsten.schnebeck@gmx.net> <200909101210.59711.bernhard@intevation.de> Message-ID: <20090911161345.15211donoewuvrj4@webmail.pardus.de> Quoting Bernhard Reiter : > Am Donnerstag, 10. September 2009 10:12:18 schrieb Thorsten Schnebeck: >> we are searching for a solution to set-up a reminding system for tasks in >> the remote future. This can not be a per user setting as it is not sure >> that the user still works in the company when the task arise. So, every >> Kolab user should be able to create such a reminder and the system should >> send a reminder email to a distribution list. This distribution list >> contains all users that take care of these tasks in the future. >> So, I set-up a shared calendar and used Horde to insert the reminder. > > An reminder for a task or an event is saved in the groupware object > in order to be used by a client. How the client notifies the user, > is something the client can decide up to a point. > Of course to be able to read the object, a client must be running. > >> This seems to work for stuff like creating and deleting but the >> email- reminder seems to be a per user setting. >> But I need this as a feature of the shared calendar. > > A shared calendar folder (which should belong to an account, but > this does not > matter) has the object, thus all readers can see that there is a reminder > wanted with this object and could react. In other words: All users already > have the reminder information, if it is saved in a folder those users have > access to. > > The issue here is that you would want someone to send out the email reminder > even if no client is running. So we need a daemon on the server which > periodically watches the folder in question and issues a reminder. > >> Maybe someone has an idea how to solve this issue or knows a >> better way how to handle the whole problem? Maybe its better to use the >> shared calendar of a virtual user? > > I guess the hackish solution would be to make sure a webclient is running all > the time that has access to the folder and will just send out emails for each > reminder. You might need a script to keep the horde sessing alive, though. > > A better solution would be to implement a daemon that does the same job. It > would be less code, more robust, secure and flexible. > > An even better, but more long time solution would be to enhance Kolab Storage > format and add a standard daemon for such purposes or come up with something > else that does time based events. I think it would also be possible to extend the Kolab Free/Busy system to keep track of reminders. Or to use something similar that allows triggering. We'd only export data relevant for the reminder on triggering and thus wouldn't compromise security of the imap system. Cheers, Gunnar > > 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 > -- ______ 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 << -------------------------------------------------------------------- -------------- 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/20090911/a413a79b/attachment.bin From issues at kolab.org Fri Sep 11 17:25:30 2009 From: issues at kolab.org (Soenke Schwardt-Krummrich) Date: Fri, 11 Sep 2009 15:25:30 +0000 Subject: [Kolab-devel] [issue3859] [turba] optimized formatName function and fallback to company attribute In-Reply-To: <1252682730.85.0.994177286924.issue3859@kolab.org> Message-ID: <1252682730.85.0.994177286924.issue3859@kolab.org> New submission from Soenke Schwardt-Krummrich : Some groupware clients like kontact or allow the creation of contacts without name entered (fullname, firstname, middlename and lastname are not set). This patch tries to assemble a formatted name if not all fields are set. If the formatted name is empty after all turba displays company name (if entered). ---------- files: t_turba_HK_UV_formatName_companyName.diff keyword: web client messages: 21652 nosy: schwardt status: unread title: [turba] optimized formatName function and fallback to company attribute ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Thu Sep 10 16:56:07 2009 +0200): [turba] optimized formatName function and fallback to company attribute Some groupware clients like kontact or allow the creation of contacts without name entered (fullname, firstname, middlename and lastname are not set). This patch tries to assemble a formatted name if not all fields are set. If the formatted name is empty after all turba displays company name (if entered). --- a/horde-webmail/turba/lib/Turba.php +++ b/horde-webmail/turba/lib/Turba.php @@ -235,18 +235,34 @@ class Turba { if (!isset($name_format)) { $name_format = $prefs->getValue('name_format'); } + $firstname = $ob->getValue('firstname'); + $middlename = $ob->getValue('middlenames'); + $lastname = $ob->getValue('lastname'); + $name = $ob->getValue('name'); /* if no formatting, return original name */ if ($name_format != 'first_last' && $name_format != 'last_first') { - return $ob->getValue('name'); + if (!empty($name)) + return $name; + if (!empty($firstname) || !empty($middlenames) || !empty($lastname)) + return trim($firstname.' '.$middlenames.' '.$lastname); + return ''; } /* See if we have the name fields split out explicitly. */ if ($ob->hasValue('firstname') && $ob->hasValue('lastname')) { if ($name_format == 'last_first') { - return $ob->getValue('lastname') . ', ' . $ob->getValue('firstname'); + if (!empty($firstname) || !empty($lastname)) + return trim($lastname . ', ' . $firstname); + if (!empty($name)) + return $name; + return ''; } else { - return $ob->getValue('firstname') . ' ' . $ob->getValue('lastname'); + if (!empty($firstname) || !empty($lastname)) + return trim ($firstname . ' ' . $lastname); + if (!empty($name)) + return $name; + return ''; } } else { /* One field, we'll have to guess. */ --- a/horde-webmail/turba/templates/browse/row.inc +++ b/horde-webmail/turba/templates/browse/row.inc @@ -6,6 +6,8 @@ if ($ob->hasValue('name')) { !in_array($ob->driver->alternativeName, $this->columns) && $ob->hasValue($ob->driver->alternativeName)) { $link_text = htmlspecialchars($ob->getValue($ob->driver->alternativeName)); +} elseif ($ob->hasValue('company')) { + $link_text = htmlspecialchars($ob->getValue('company')); } else { $link_text = '' . _("Blank name") . ''; } From issues at kolab.org Fri Sep 11 17:26:50 2009 From: issues at kolab.org (Soenke Schwardt-Krummrich) Date: Fri, 11 Sep 2009 15:26:50 +0000 Subject: [Kolab-devel] [issue3860] kronolith: fixed display of wrong organizer - german translation update In-Reply-To: <1252682810.28.0.370275105929.issue3860@kolab.org> Message-ID: <1252682810.28.0.370275105929.issue3860@kolab.org> New submission from Soenke Schwardt-Krummrich : Without this patch kronolith displays "me" as event's creator/modifier if the true creator/modifier cannot be determined. This gets very confusive in conjunction with shared calendars if not all readers have write permission. Additionally the patch switches event's german "owner" translation from "Besitzer" to "Organisator". ---------- files: t_kronolith_HK_UV_lastModificationOfEvents.diff keyword: web client messages: 21653 nosy: schwardt status: unread title: kronolith: fixed display of wrong organizer - german translation update ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Fri Sep 11 15:31:05 2009 +0200): kronolith: fixed display of wrong organizer - german translation update Without this patch kronolith displays "me" as event's creator/modifier if the true creator/modifier cannot be determined. This gets very confusive in conjunction with shared calendars if not all readers have write permission. Additionally the patch switches event's german "owner" translation from "Besitzer" to "Organisator". --- a/horde-webmail/kronolith/lib/Driver.php +++ b/horde-webmail/kronolith/lib/Driver.php @@ -1433,7 +1433,7 @@ class Kronolith_Event { */ function getCreatorId() { - return !empty($this->creatorID) ? $this->creatorID : Auth::getAuth(); + return !empty($this->creatorID) ? $this->creatorID : _('User unkown'); } /** --- a/horde-webmail/kronolith/lib/Driver/kolab.php +++ b/horde-webmail/kronolith/lib/Driver/kolab.php @@ -1467,6 +1467,58 @@ class Kronolith_Event_kolab_new extends Kronolith_Event { $this->alarm = $event['alarm']; } + // update history with Kolab creation and modify timestamps + $history = &Horde_History::singleton(); + $log = $history->getHistory('kronolith:' . $this->_calendar . ':' . $event['uid']); + + if (isset ($event['creation-date'])) { + $set_add = false; + if ($log && !is_a($log, 'PEAR_Error')) { + foreach ($log->getData() as $entry) { + switch ($entry['action']) { + case 'add': + $set_add = true; + $_date = new Horde_Date($event['creation-date']); + if ($entry['ts'] != $_date->timestamp ()) { + $history_id = 'kronolith:' . $this->_calendar . ':' . $event['uid']; + $history->log($history_id, array('action' => 'add', 'ts' => $_date->timestamp(), 'who' => ''), true); + } + break; + } + } + } + if (!$set_add) { + $_date = new Horde_Date($event['creation-date']); + $history_id = 'kronolith:' . $this->_calendar . ':' . $event['uid']; + $history->log($history_id, array('action' => 'add', 'ts' => $_date->timestamp(), 'who' => ''), true); + } + } + + if (isset ($event['last-modification-date'])) { + $set_modify = false; + if ($log && !is_a($log, 'PEAR_Error')) { + if (!empty ($log)) { + foreach ($log->getData() as $entry) { + switch ($entry['action']) { + case 'modify': + $set_modify = true; + $_date = new Horde_Date($event['last-modification-date']); + if ($entry['ts'] != $_date->timestamp ()) { + $history_id = 'kronolith:' . $this->_calendar . ':' . $event['uid']; + $history->log($history_id, array('action' => 'modify', 'ts' => $_date->timestamp(), 'who' => ''), true); + } + break; + } + } + } + } + if (!$set_modify) { + $_date = new Horde_Date($event['last-modification-date']); + $history_id = 'kronolith:' . $this->_calendar . ':' . $event['uid']; + $history->log($history_id, array('action' => 'modify', 'ts' => $_date->timestamp(), 'who' => ''), true); + } + } + $this->start = new Horde_Date($event['start-date']); $this->end = new Horde_Date($event['end-date']); $this->durMin = ($this->end->timestamp() - $this->start->timestamp()) / 60; --- a/horde-webmail/kronolith/lib/Views/Event.php +++ b/horde-webmail/kronolith/lib/Views/Event.php @@ -59,7 +59,11 @@ class Kronolith_View_Event { case 'add': $created = $entry['ts']; if ($userId != $entry['who']) { - $createdby = sprintf(_("by %s"), Kronolith::getUserName($entry['who'])); + if (empty ($entry['who'])) { + $createdby = ''; + } else { + $createdby = sprintf(_("by %s"), Kronolith::getUserName($entry['who'])); + } } else { $createdby = _("by me"); } @@ -68,7 +72,11 @@ class Kronolith_View_Event { case 'modify': $modified = $entry['ts']; if ($userId != $entry['who']) { - $modifiedby = sprintf(_("by %s"), Kronolith::getUserName($entry['who'])); + if (empty ($entry['who'])) { + $modifiedby = ''; + } else { + $modifiedby = sprintf(_("by %s"), Kronolith::getUserName($entry['who'])); + } } else { $modifiedby = _("by me"); } --- a/horde-webmail/kronolith/po/de_DE.po +++ b/horde-webmail/kronolith/po/de_DE.po @@ -1348,8 +1348,8 @@ msgid "" "Only the owner or system administrator may change ownership or owner " "permissions for a share" msgstr "" -"Nur der Besitzer oder der Systemadministrator kann den Besitzer oder die " -"Besitzerrechte ändern" +"Nur der Organisator oder der Systemadministrator kann den Organisator oder die " +"Organisatorrechte ändern" #: lib/Kronolith.php:1238 msgid "Optional" @@ -1369,16 +1369,16 @@ msgstr " #: templates/perms/perms.inc:22 templates/view/view.inc:28 msgid "Owner" -msgstr "Besitzer" +msgstr "Organisator" #: templates/perms/perms.inc:28 templates/perms/perms.inc:39 msgid "Owner:" -msgstr "Besitzer:" +msgstr "Organisator:" #: lib/Driver.php:2341 #, php-format msgid "Owner: %s" -msgstr "Besitzer: %s" +msgstr "Organisator: %s" #: templates/data/export.inc:119 templates/data/export.inc:204 msgid "PM" @@ -1700,7 +1700,7 @@ msgstr "Hinzuzuf #: templates/perms/perms.inc:30 msgid "Select a new owner:" -msgstr "Neuen Besitzer auswählen:" +msgstr "Neuen Organisator auswählen:" #: templates/perms/perms.inc:217 templates/perms/perms.inc:219 msgid "Select a user to add:" @@ -2293,6 +2293,10 @@ msgstr "Benutzeroberfl msgid "User to add:" msgstr "Hinzuzufügender Benutzer:" +#: lib/Views/Event.php:63 +msgid "User unkown" +msgstr "Benutzer unbekannt" + #: lib/Forms/SubscribeRemoteCalendar.php:38 #: lib/Forms/EditRemoteCalendar.php:38 msgid "Username" From issues at kolab.org Fri Sep 11 17:27:57 2009 From: issues at kolab.org (Soenke Schwardt-Krummrich) Date: Fri, 11 Sep 2009 15:27:57 +0000 Subject: [Kolab-devel] [issue3861] kronolith: new config option to hide "send invitation" checkbox In-Reply-To: <1252682877.84.0.234458655079.issue3861@kolab.org> Message-ID: <1252682877.84.0.234458655079.issue3861@kolab.org> New submission from Soenke Schwardt-Krummrich : In a environments where most users use a non-groupware-aware mail client sending invitations for events is superfluous. This patch adds a config option to hide the corresponding checkbox. ---------- files: t_kronolith_HK_UV_optionalInvitationCheckbox.diff keyword: web client messages: 21654 nosy: schwardt status: unread title: kronolith: new config option to hide "send invitation" checkbox ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Fri Sep 11 16:20:34 2009 +0200): kronolith: new config option to hide "send invitation" checkbox In a environments where most users use a non-groupware-aware mail client sending invitations for events is superfluous. This patch adds a config option to hide the corresponding checkbox. --- a/horde-webmail/kronolith/config/conf.php +++ b/horde-webmail/kronolith/config/conf.php @@ -5,6 +5,7 @@ $conf['calendar']['driver'] = 'kolab'; $conf['calendar']['day']['inline_time'] = false; $conf['calendar']['week']['inline_time'] = false; $conf['calendar']['edit']['save_as_new'] = true; +$conf['calendar']['edit']['invitation_send'] = true; $conf['storage']['driver'] = 'kolab'; $conf['storage']['default_domain'] = ''; $conf['storage']['freebusy']['protocol'] = 'https'; --- a/horde-webmail/kronolith/config/conf.xml +++ b/horde-webmail/kronolith/config/conf.xml @@ -20,6 +20,7 @@ Display Settings For Events Edit Dialog true + true --- a/horde-webmail/kronolith/templates/delete/delete.inc +++ b/horde-webmail/kronolith/templates/delete/delete.inc @@ -17,9 +17,11 @@ if (empty($url)) { +event->attendees)): ?> + + + +
occurrence and all future occurences, or all occurences?") ?>
" /> --- a/horde-webmail/kronolith/templates/delete/one.inc +++ b/horde-webmail/kronolith/templates/delete/one.inc @@ -15,9 +15,11 @@ if (empty($url)) {
+ event->attendees)): ?>

+

--- a/horde-webmail/kronolith/templates/edit/edit.inc +++ b/horde-webmail/kronolith/templates/edit/edit.inc @@ -371,6 +371,7 @@ endif;
@@ -378,6 +379,8 @@ endif;
From issues at kolab.org Fri Sep 11 17:29:00 2009 From: issues at kolab.org (Soenke Schwardt-Krummrich) Date: Fri, 11 Sep 2009 15:29:00 +0000 Subject: [Kolab-devel] [issue3862] kronolith: new config option to hide 'save_as_new' button In-Reply-To: <1252682940.34.0.969467202946.issue3862@kolab.org> Message-ID: <1252682940.34.0.969467202946.issue3862@kolab.org> New submission from Soenke Schwardt-Krummrich : This patch adds a new config option that is able to hide the 'save_as_new' button when editing events. ---------- files: t_kronolith_HK_UV_optionalSaveAsNewButton.diff keyword: web client messages: 21655 nosy: schwardt status: unread title: kronolith: new config option to hide 'save_as_new' button ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Fri Sep 11 16:11:09 2009 +0200): kronolith: new config option to hide 'save_as_new' button This patch adds a new config option that is able to hide the 'save_as_new' button when editing events. --- a/horde-webmail/kronolith/config/conf.php +++ b/horde-webmail/kronolith/config/conf.php @@ -4,6 +4,7 @@ $conf['calendar']['driver'] = 'kolab'; $conf['calendar']['day']['inline_time'] = false; $conf['calendar']['week']['inline_time'] = false; +$conf['calendar']['edit']['save_as_new'] = true; $conf['storage']['driver'] = 'kolab'; $conf['storage']['default_domain'] = ''; $conf['storage']['freebusy']['protocol'] = 'https'; --- a/horde-webmail/kronolith/config/conf.xml +++ b/horde-webmail/kronolith/config/conf.xml @@ -17,6 +17,12 @@ + + Display Settings For Events Edit Dialog + true + + + Display Settings For Week View false --- a/horde-webmail/kronolith/lib/Views/EditEvent.php +++ b/horde-webmail/kronolith/lib/Views/EditEvent.php @@ -36,6 +36,7 @@ class Kronolith_View_EditEvent { function html($active = true) { + global $conf; require_once 'Horde/Identity.php'; $identity = &Identity::singleton(); @@ -76,7 +77,9 @@ class Kronolith_View_EditEvent { (!empty($GLOBALS['conf']['hooks']['permsdenied']) || Kronolith::hasPermission('max_events') === true || Kronolith::hasPermission('max_events') > Kronolith::countEvents())) { - $buttons[] = ''; + if ( isset($conf['calendar']['edit']['save_as_new']) ? $conf['calendar']['edit']['save_as_new'] : true ) { + $buttons[] = ''; + } } else { if (!$this->event->isRemote()) { $buttons[] = ''; @@ -86,7 +89,9 @@ class Kronolith_View_EditEvent { (!empty($conf['hooks']['permsdenied']) || Kronolith::hasPermission('max_events') === true || Kronolith::hasPermission('max_events') > Kronolith::countEvents())) { - $buttons[] = ''; + if ( isset($conf['calendar']['edit']['save_as_new']) ? $conf['calendar']['edit']['save_as_new'] : true ) { + $buttons[] = ''; + } } } } From issues at kolab.org Fri Sep 11 19:37:58 2009 From: issues at kolab.org (issues@kolab.org) Date: Fri, 11 Sep 2009 17:37:58 +0000 Subject: [Kolab-devel] [issue3863] Kontact: VCalendar elements should not contain TZID times In-Reply-To: <1252690678.8.0.151855556349.issue3863@kolab.org> Message-ID: <1252690678.8.0.151855556349.issue3863@kolab.org> New submission from Albrecht Dre? : Some Kontact version (e.g. the one coming with Ubuntu Jaunty; Kontact 1.4.2, Korganiser 4.2.2) produce VCalendar invitations containing TZID's, e.g. DTSTART;TZID=Europe/Berlin:20090826T150000 DTEND;TZID=Europe/Berlin:20090826T153000 Although this is perfectly allowed according to RFC 2445, Outlook apparently sometimes mis-interprets these values. Therefore, it might be better to always use the UT time stamps according to RFC 2445, Sect. 4.3.5, which are more robust. ---------- keyword: enterprise35, enterprise4, kde client messages: 21656 nosy: albrecht.dress priority: feature status: chatting title: Kontact: VCalendar elements should not contain TZID times ______________________________________ Kolab issue tracker ______________________________________ From bernhard at intevation.de Mon Sep 14 11:58:00 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 14 Sep 2009 11:58:00 +0200 Subject: [Kolab-devel] shared calendar as long time reminding system? In-Reply-To: <20090911160819.12783mk14wbdc14w@webmail.pardus.de> References: <200909101012.18927.thorsten.schnebeck@gmx.net> <200909110849.51109.bernhard@intevation.de> <20090911160819.12783mk14wbdc14w@webmail.pardus.de> Message-ID: <200909141158.03874.bernhard@intevation.de> Am Freitag, 11. September 2009 16:08:19 schrieb Gunnar Wrobel: > >> I think the Horde Alarm system allows setting up email reminders ? > >> via a ?cron job. > > > > From the concept side I do not see how this could work reliably. > > In order to read a folder, any client would need the users credentials > > which should only be kept in memory as long as the client is active. > > A cron job is another client and it dies not have the credentials to > > access the folder of any user. > > Correct. The current reminder script is targeted at the ? > SQL-Installation and the assumption is that you have an admin user ? > that can read all events. This is easy for SQL but not the case if you ? > have IMAP. > > We do however already employ some kind of shared access for our ? > resource accounts on the Kolab server. And often is might also be ? > sufficient if there is only one specific user sending out reminders. Yes, we do this by granting access to a special daemon user called "calendar" which in turn gets to have access to all the folders. > In these limited cases you could provide the corresponding credentials ? > for the cron job in a config file. I had hoped the current reminder ? > script allows something like that. Just to be extra clear: The real user credentials must never be saved on the server system, except hashed in the directory server of course. This mean we would need to workd by another users like "reminder" or a different construct. -- 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/20090914/0fe520ad/attachment.bin From bernhard at intevation.de Mon Sep 14 11:59:59 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 14 Sep 2009 11:59:59 +0200 Subject: [Kolab-devel] shared calendar as long time reminding system? In-Reply-To: <20090911161345.15211donoewuvrj4@webmail.pardus.de> References: <200909101012.18927.thorsten.schnebeck@gmx.net> <200909101210.59711.bernhard@intevation.de> <20090911161345.15211donoewuvrj4@webmail.pardus.de> Message-ID: <200909141159.59775.bernhard@intevation.de> Am Freitag, 11. September 2009 16:13:45 schrieb Gunnar Wrobel: > > I guess the hackish solution would be to make sure a webclient is running > > all the time that has access to the folder and will just send out emails > > for each reminder. You might need a script to keep the horde sessing > > alive, though. > > > > A better solution would be to implement a daemon that does the same job. > > It would be less code, more robust, secure and flexible. > > > > An even better, but more long time solution would be to enhance Kolab > > Storage format and add a standard daemon for such purposes or come up > > with something else that does time based events. > > I think it would also be possible to extend the Kolab Free/Busy system ? > to keep track of reminders. Or to use something similar that allows ? > triggering. We'd only export data relevant for the reminder on ? > triggering and thus wouldn't compromise security of the imap system. This is one possible design. I wonder thought if we would want to have feedback on who got reminded when, just triggering would be enought. Also the contents of the reminder might be worth being protected. Still we would need a daemon to check for the reminders. 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/20090914/c2ac84ba/attachment.bin From aspineux at gmail.com Mon Sep 14 12:34:39 2009 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 14 Sep 2009 12:34:39 +0200 Subject: [Kolab-devel] Alternative mailbox login In-Reply-To: References: <20090910160347.2036712r720h92rn@webmail.pardus.de> Message-ID: <71fe4e760909140334l1b882716oc1993ea45afec628@mail.gmail.com> You could use a proxy like nginx and write a script that will map a user to another one, you can hard code the mapping or use field matching in ldap if you can make some ldap request from inside your script. On Thu, Sep 10, 2009 at 9:33 PM, Stefan Kunz wrote: > Hi Gunnar, > > i have add manually a new user in the ldap. This user can authenticate via saslauth, but cyrus doesn't find the mailbox, because i have not defined mail attribute in the new ldap entry. > My problem is that the mail attribute in ldap must be unique, else no success authentication is possible. > I tried something with ldap_filter in saslauth.conf though without success. > Apparently cyrus read the mail attribute from ldap to find the mailbox. > > Cyrus passes the e-mail-address to saslauth, when the mail attribute is found. So the parameter %u, %r in ldap_filter have the value viz the e-mail-adress. So it is difficult, the correct ldap entry filtered to authenticate. > > Have you any tip for me, how cyrus find the mailbox from another ldap attribute, so the same mailbox open with two different usernames bzw. passwords. > > Regards > > Stefan > > > > > _______________________________________________ > Kolab-devel mailing list > Kolab-devel at kolab.org > https://kolab.org/mailman/listinfo/kolab-devel > -- Alain Spineux aspineux gmail com May the sources be with you From issues at kolab.org Mon Sep 14 15:08:41 2009 From: issues at kolab.org (Ludwig Reiter) Date: Mon, 14 Sep 2009 13:08:41 +0000 Subject: [Kolab-devel] [issue3864] An invitation of a long event shows a wrong duration. In-Reply-To: <1252933721.91.0.574096405324.issue3864@kolab.org> Message-ID: <1252933721.91.0.574096405324.issue3864@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090911-1022378-kk2 Test: 1. A sends B an invitation with start at 10:00 and end at 11:00 at the next day. (A long event which contain one night.) 2. B syncs. 3. B looks at the invitation. => The invitation shows a duration of 1 hour. The duration in this case should be 25 hours. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21674 nosy: allen, ludwig priority: bug status: unread title: An invitation of a long event shows a wrong duration. ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Tue Sep 15 10:13:00 2009 From: issues at kolab.org (Bernhard Reiter) Date: Tue, 15 Sep 2009 08:13:00 +0000 Subject: [Kolab-devel] [issue3865] Crash while syncing, automatic event archival enabled, in EventArchiver::archiveIncidences In-Reply-To: <1253002380.48.0.812999938487.issue3865@kolab.org> Message-ID: <1253002380.48.0.812999938487.issue3865@kolab.org> New submission from Bernhard Reiter : A user has frequent crashes with Kontact. The crash happens during an automatic sync, about every _hour_! The automatic sync intervall is 15 minutes. The KOrganizer archive function is enabled to automaticall move old (1 month) events and todo entries into a file. (See Calender View -> File -> Archive old entries) [KCrash handler] #5 0xb7760643 in strlen () from /lib/libc.so.6 #6 0xb72ba503 in QString::fromUtf8 ( utf8=0xb16ac008
, len=-1) at tools/qstring.cpp:5804 #7 0xb65d778a in Attachment (this=0xad3b010, base64=0xb16ac008
, mime=@0x807c400) at attachment.cpp:47 #8 0xb6606262 in KCal::ICalFormatImpl::readAttachment (this=0xab5e478, attach=0xac28780) at icalformatimpl.cpp:1250 #9 0xb6607dbf in KCal::ICalFormatImpl::readIncidence (this=0xab5e478, parent=0xac39368, tz=0x0, incidence=0xad3ae28) at icalformatimpl.cpp:1413 #10 0xb6608bfe in KCal::ICalFormatImpl::readTodo (this=0xab5e478, vtodo=0xac39368) at icalformatimpl.cpp:908 #11 0xb660926f in KCal::ICalFormatImpl::populate (this=0xab5e478, cal=0xbfe32a54, calendar=0xac43b88) at icalformatimpl.cpp:2031 #12 0xb6603644 in KCal::ICalFormat::fromRawString (this=0xbfe329a4, cal=0xbfe32a54, text=@0xbfe3293c) at icalformat.cpp:184 #13 0xb6603e63 in KCal::ICalFormat::load (this=0xbfe329a4, calendar=0xbfe32a54, fileName=@0xbfe32bc8) at icalformat.cpp:98 #14 0xb662b437 in KCal::FileStorage::load (this=0xbfe32bbc) at filestorage.cpp:97 #15 0xb55f9348 in EventArchiver::archiveIncidences (this=0xbfe32e44, calendar=0xa83a6a0, widget=0xa25f7b8, incidences=@0xbfe32d78) at eventarchiver.cpp:162 #16 0xb55fa0bb in EventArchiver::run (this=0xbfe32e44, calendar=0xa83a6a0, limitDate=@0xbfe32e08, widget=0xa25f7b8, withGUI=, errorIfNone=false) at eventarchiver.cpp:116 #17 0xb55fa29d in EventArchiver::runAuto (this=0xbfe32e44, calendar=0xa83a6a0, widget=0xa25f7b8, withGUI=) at eventarchiver.cpp:70 #18 0xb55d9be7 in ActionManager::slotAutoArchive (this=0xa83a510) at actionmanager.cpp:1911 #19 0xb55e002b in ActionManager::qt_invoke (this=0xa83a510, _id=42, _o=0xbfe32ef4) at actionmanager.moc:329 #20 0xb6fc216a in QObject::activate_signal (this=0xa897b90, clist=0xa897c58, o=0xbfe32ef4) at kernel/qobject.cpp:2359 #21 0xb6fc468b in QObject::activate_signal (this=0xa897b90, signal=2) at kernel/qobject.cpp:2328 #22 0xb7321ab9 in QTimer::timeout (this=0xa897b90) at .moc/release-shared-mt/moc_qtimer.cpp:82 #23 0xb6fe67ec in QTimer::event (this=0xa897b90, e=0xbfe331f4) at kernel/qtimer.cpp:222 #24 0xb6f5d775 in QApplication::internalNotify (this=0xbfe3343c, receiver=0xa897b90, e=0xbfe331f4) at kernel/qapplication.cpp:2638 #25 0xb6f5e7b6 in QApplication::notify (this=0xbfe3343c, receiver=0xa897b90, e=0xbfe331f4) at kernel/qapplication.cpp:2375 #26 0xb7648b92 in KApplication::notify (this=0xbfe3343c, receiver=0xa897b90, event=0xbfe331f4) at /usr/src/kdelibs/20090706/kdelibs-3.5.10.dfsg.1/./kdecore/kapplication.cpp:550 #27 0xb6f52fc3 in QEventLoop::activateTimers (this=0x96e7178) at kernel/qapplication.h:523 #28 0xb6f086be in QEventLoop::processEvents (this=0x96e7178, flags=4) at kernel/qeventloop_x11.cpp:392 #29 0xb6f76140 in QEventLoop::enterLoop (this=0x96e7178) at kernel/qeventloop.cpp:201 #30 0xb6f76006 in QEventLoop::exec (this=0x96e7178) at kernel/qeventloop.cpp:148 #31 0xb6f5de0f in QApplication::exec (this=0xbfe3343c) at kernel/qapplication.cpp:2761 #32 0x0805f190 in main (argc=) at main.cpp:188 ---------- assignedto: allen keyword: enterprise35, kde client, kkc messages: 21680 nosy: allen, bernhard, ludwig, till priority: critical status: unread title: Crash while syncing, automatic event archival enabled, in EventArchiver::archiveIncidences ______________________________________ Kolab issue tracker ______________________________________ From funke at hiskp.uni-bonn.de Tue Sep 15 10:36:57 2009 From: funke at hiskp.uni-bonn.de (Christian Funke) Date: Tue, 15 Sep 2009 10:36:57 +0200 Subject: [Kolab-devel] Active options for RPMs Message-ID: <20090915103657.43356733jgzwwv8p@mx.hiskp.uni-bonn.de> Hello, I am currently investigating kolab/issue2982 (OpenLDAP segmentation fault on 64bit). And I think i have tracked it down to the berkeley db compile options. Now I want to test this for my whole system since quite a lot of packages depend on bdb. So I want to recompile the dependant packages, but I cannot figure out with which options the various rpms were compiled. In install-kolab.sh there are a few -D lines but for everything else especially php and imapd i dont't have a clue. I guess its defined in 00index.rdf, but i dont know how to read this file correctly. Can someone give me hint? Thanks in advance Christian From issues at kolab.org Tue Sep 15 12:02:57 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 15 Sep 2009 10:02:57 +0000 Subject: [Kolab-devel] [issue3866] OL2003 doesn't understand the timezone info in a e4 invitation. In-Reply-To: <1253008977.87.0.671235734726.issue3866@kolab.org> Message-ID: <1253008977.87.0.671235734726.issue3866@kolab.org> New submission from Ludwig Reiter : Tested with Kontact lenny/e4 20090508.965297-kk1 and Windows XP SP3 with Outlook 2003 Test: 1. The Kontact user sends an invitation to the OL user. Contains: DTSTART;TZID=Europe/Berlin:20090915T130000 DTEND;TZID=Europe/Berlin:20090915T133000 in the iCalendar invitation. 2. Sync OL and look at the invitation. => OL says the event is at 15:00-15:30, but Windows has the same timezone CEST. So OL seems to ignore the TZID part. ---------- assignedto: allen keyword: enterprise4, kde client messages: 21683 nosy: allen, ludwig priority: bug status: unread title: OL2003 doesn't understand the timezone info in a e4 invitation. ______________________________________ Kolab issue tracker ______________________________________ From stkunz at web.de Wed Sep 16 09:40:32 2009 From: stkunz at web.de (Stefan Kunz) Date: Wed, 16 Sep 2009 09:40:32 +0200 Subject: [Kolab-devel] Alternative mailbox login In-Reply-To: <71fe4e760909140334l1b882716oc1993ea45afec628@mail.gmail.com> Message-ID: Thanks for your answer! Has anybody other suggestions? Regards Stefan -----Ursprungliche Nachricht----- Von: kolab-devel-bounces at kolab.org [mailto:kolab-devel-bounces at kolab.org]Im Auftrag von Alain Spineux Gesendet: Montag, 14. September 2009 12:35 An: Kolab development coordination Betreff: Re: [Kolab-devel] Alternative mailbox login You could use a proxy like nginx and write a script that will map a user to another one, you can hard code the mapping or use field matching in ldap if you can make some ldap request from inside your script. -- Alain Spineux aspineux gmail com May the sources be with you _______________________________________________ Kolab-devel mailing list Kolab-devel at kolab.org https://kolab.org/mailman/listinfo/kolab-devel From issues at kolab.org Wed Sep 16 14:45:29 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 16 Sep 2009 12:45:29 +0000 Subject: [Kolab-devel] [issue3867] Save a S/MIME encrypted mails unencrypted after reading them. In-Reply-To: <1253105129.99.0.896040158265.issue3867@kolab.org> Message-ID: <1253105129.99.0.896040158265.issue3867@kolab.org> New submission from Ludwig Reiter : tested with Kontact 20090911.1022378-kk2 A S/MIME encrypted mail should be stored unencrypted after displaying it. This should work like in proko2. Test: 1. Set in .kde/share/config/kmailrc under group [Reader] store-displayed-messages-unencrypted=true 2. Start kontact. 3. Read a S/MIME encrypted mail. 4. Close Kontact. 5. Read the S/MIME encrypted mail again. => The mail is still encrypted. This is a regression. Please also add the documentation for the option. ---------- assignedto: allen keyword: enterprise35, kkc messages: 21702 nosy: allen, ludwig priority: urgent status: unread title: Save a S/MIME encrypted mails unencrypted after reading them. ______________________________________ Kolab issue tracker ______________________________________ From thomas at intevation.de Wed Sep 16 15:12:52 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 16 Sep 2009 15:12:52 +0200 Subject: [Kolab-devel] Active options for RPMs In-Reply-To: <20090915103657.43356733jgzwwv8p@mx.hiskp.uni-bonn.de> References: <20090915103657.43356733jgzwwv8p@mx.hiskp.uni-bonn.de> Message-ID: <20090916150006.272472570.thomas@jtah.de> * Christian Funke [20090915 10:37]: > I am currently investigating kolab/issue2982 (OpenLDAP segmentation > fault on 64bit). And I think i have tracked it down to the berkeley db > compile options. Now I want to test this for my whole system since > quite a lot of packages depend on bdb. So I want to recompile the > dependant packages, but I cannot figure out with which options the > various rpms were compiled. In install-kolab.sh there are a few -D > lines but for everything else especially php and imapd i dont't have a > clue. I guess its defined in 00index.rdf, but i dont know how to read > this file correctly. openpkg rpm -qi imapd will show imapd::with_fsl = yes imapd::with_group = yes imapd::with_group_igncase = yes ... Alternatively you could change install-kolab.sh to not execute the shell script which is generated by openpkg build, but save it somewhere for you to look at. This will contain all openpkg rpm calls you need. Regards, Thomas Arendsen Hein P.S.: Your mail server's disk was full, so you have lost at least one mail for issue3610. (Hopefully you will receive this mail or at least see it in the web archive) -- 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 ... and we need a dozen cans of tuna From thomas at intevation.de Wed Sep 16 15:34:48 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed, 16 Sep 2009 15:34:48 +0200 Subject: [Kolab-devel] Instructions for creating new issues Message-ID: <20090916152958.482431302.thomas@jtah.de> Hi! I updated http://wiki.kolab.org/index.php/Kolab_Issue_Tracker to include links to create new issues with keywords and assignedto for specific Kolab components. Additionally I added a link "Instructions" to this page in the navigation of issues.kolab.org to make it easier to find. You can add yourself to the URLs on the wiki page if you like. 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 ... and we need a dozen cans of tuna From ninaramus at mail.ru Thu Sep 17 12:52:18 2009 From: ninaramus at mail.ru (=?koi8-r?Q?=CE=C9=CE=C1_=D2=C1=CD=D5=D3?=) Date: Thu, 17 Sep 2009 14:52:18 +0400 Subject: [Kolab-devel] =?koi8-r?b?S29sYWItZGV2ZWwgRGlnZXN0LCBWb2wgNzQsIElz?= =?koi8-r?b?c3VlIDE4?= In-Reply-To: References: Message-ID: ?????? ??????????? ????????? : ninaramus at mail.ru zet1959 at mail.ru 3000nina at mail.ru From issues at kolab.org Thu Sep 17 18:28:52 2009 From: issues at kolab.org (Sascha Wilde) Date: Thu, 17 Sep 2009 16:28:52 +0000 Subject: [Kolab-devel] [issue3868] Resmgr eats up all memory and dies on some recuring events In-Reply-To: <1253204932.5.0.904433658374.issue3868@kolab.org> Message-ID: <1253204932.5.0.904433658374.issue3868@kolab.org> New submission from Sascha Wilde : When inviting an automatic resource (accepts when not conflicting) to an event with [x] Monthly: Recurs every 1 month(s) on the same weekday set, the filer php process grows in sizes till system limits are reached and then dies. This is _not_ the case for all kinds of recurring event (sucsessfully tested an event with weekly recurrence). But at least for the case outlined above (more failures are possible, I didn't test all cases). ---------- assignedto: wrobel keyword: freebusy, server messages: 21726 nosy: martin, thomas, wilde, wrobel priority: critical status: unread title: Resmgr eats up all memory and dies on some recuring events ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Fri Sep 18 11:15:44 2009 From: issues at kolab.org (Bernhard Reiter) Date: Fri, 18 Sep 2009 09:15:44 +0000 Subject: [Kolab-devel] [issue3869] Adding email address to the contacts (add to address book function) fails on Lenny (#rt5864) In-Reply-To: <1253265344.73.0.779414599239.issue3869@kolab.org> Message-ID: <1253265344.73.0.779414599239.issue3869@kolab.org> New submission from Bernhard Reiter : With e35 20090907.1021521-kk4 on Debian Lenny the function "add to address book" on an email address in an email view does not work correctly anymore. The resulting addressbook entry is empty. With Etch it works, so it is likely that the change of libraries is a potential trigger for this issue. ---------- assignedto: allen keyword: enterprise35, kde client, kkc messages: 21733 nosy: allen, bernhard, ludwig, till priority: urgent status: unread title: Adding email address to the contacts (add to address book function) fails on Lenny (#rt5864) ______________________________________ Kolab issue tracker ______________________________________ From christopher.bertels at intevation.de Fri Sep 18 16:20:18 2009 From: christopher.bertels at intevation.de (Christopher Bertels) Date: Fri, 18 Sep 2009 16:20:18 +0200 Subject: [Kolab-devel] Packaging Sesame2 storage backend for Soprano (Nepomuk) Message-ID: <200909181620.28342.christopher.bertels@intevation.de> Hi, I just wanted to inform you, that I've been working on packaging Sesame2 as a storage backend for Nepomuk. After a bit of frustration I'm getting closer to the final goal now. I've packaged a few dependencies which haven't been packaged for Debian already. There are still some left, but I hope to get something working out by the middle of next week. Wish me luck. ;-) Cheers, Christopher. -- Christopher Bertels | OpenPGP key: 0x725D9BE5| 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: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090918/fb1b71cf/attachment.bin From bernhard at intevation.de Fri Sep 18 17:33:25 2009 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 18 Sep 2009 17:33:25 +0200 Subject: [Kolab-devel] Packaging Sesame2 storage backend for Soprano (Nepomuk) In-Reply-To: <200909181620.28342.christopher.bertels@intevation.de> References: <200909181620.28342.christopher.bertels@intevation.de> Message-ID: <200909181733.28989.bernhard@intevation.de> Am Freitag, 18. September 2009 16:20:18 schrieb Christopher Bertels: > I just wanted to inform you, that I've been working on packaging Sesame2 as > a storage backend for Nepomuk. After a bit of frustration I'm getting > closer to the final goal now. I've packaged a few dependencies which > haven't been packaged for Debian already. There are still some left, but I > hope to get something working out by the middle of next week. Wish me luck. > ;-) Just some background information: Nepomuk is a semantic search engine "backend" which we currently try to use in a prototype called Kontact Prototype-E5. This of course is the next generation KDE4 based Kolab Client, and if the prototype is successful it might become the foundation for an enterprise 5 client. Yes, we try to make Debian packages for Kontact prototype-e5 at some time, development as always happens public in the kde repository. http://en.wikipedia.org/wiki/NEPOMUK_(framework) http://nepomuk.kde.org/ http://techbase.kde.org/Development/Tutorials#Nepomuk -- 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/20090918/4ba0e8c9/attachment.bin From christopher.bertels at intevation.de Fri Sep 18 17:45:40 2009 From: christopher.bertels at intevation.de (Christopher Bertels) Date: Fri, 18 Sep 2009 17:45:40 +0200 Subject: [Kolab-devel] Packaging Sesame2 storage backend for Soprano (Nepomuk) In-Reply-To: <200909181733.28989.bernhard@intevation.de> References: <200909181620.28342.christopher.bertels@intevation.de> <200909181733.28989.bernhard@intevation.de> Message-ID: <200909181745.44482.christopher.bertels@intevation.de> A small addition to my last email: I've uploaded my current work to gitorious.org. You can take a look there, if you want to. The url to the git repositories is: http://gitorious.org/soprano-backend-sesame2/ Cheers, Christopher. PS: I chose git & gitorious purely out of pragmatical reasons, as that is my (personally) preferred scm and I'm used to working with it. Once I'm done I'll feel happy to move the sources somewhere else, maybe even more 'official', if that is in your interest. ;) -- Christopher Bertels | OpenPGP key: 0x725D9BE5| 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: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090918/bada5193/attachment.bin From issues at kolab.org Mon Sep 21 13:11:15 2009 From: issues at kolab.org (Mathieu Parent) Date: Mon, 21 Sep 2009 11:11:15 +0000 Subject: [Kolab-devel] [issue3870] Remote Microsoft Exchange freebusy fetching in Kolab_Freebusy In-Reply-To: <1253531475.98.0.445613307368.issue3870@kolab.org> Message-ID: <1253531475.98.0.445613307368.issue3870@kolab.org> New submission from Mathieu Parent : Hello, Currently, retrieving freebusy information only works for users present in the LDAP directory and having an IMAP folder following Kolab XML format and annotations. I need to extend this to get freebusy data from Exchange 2007 servers which shares the same mail domain as our Kolab servers. This is a very specific request, but it is covered by two more general features : - retrieve freebusy information from servers outside the Kolab "cluster" - retrieve freebusy information from other formats Proposed implementation : - add an "Outlook Web Access" format in Kolab_Format for freebusy information (probably in lib/Horde/Kolab/Format/OWA.php, inheriting Horde_Kolab_Format_XML or not). More info on the format [owa-format] - change Horde_Kolab_FreeBusy_Access::_process to allow fallback when no user is found in LDAP and a hook is defined. The hook will return a freebusyserver and a freebusyservertype (owa for MS exchange, ifb for remote, imap for local) based on uid/mail - change Horde_Kolab_FreeBusy_Access::fetchRemote to redirect only if freebusyservertype is ifb, error only if freebusyserver is not set. - change Freebusy/Cache.php to use Horde_Kolab_FreeBusy_xx class (Imap or OWA) depending on freebusyservertype - create Horde_Kolab_FreeBusy_OWA class, using Horde_Kolab_Format_OWA With this proposal it will be possible in the future to add connectors for other mail servers. As this changes a lot of the existing code, I first need to know if the proposal is ok or if there is a better solution (I'm mostly asking Gunnar as the main developer of those horde parts). Mathieu Parent [owa-format]: http://www.infinitec.de/post/2004/12/30/Retrieving-a-users-availability-(freebusy-data).aspx http://wiki.zimbra.com/index.php?title=Troubleshooting_Exchange_Freebusy_Interop References: http://kolab.org/pipermail/kolab-devel/2009-August/010738.html http://kolab.org/pipermail/kolab-devel/2009-September/010786.html ---------- assignedto: wrobel keyword: freebusy, server messages: 21741 nosy: martin, mathieu.parent, opensides, thomas, wilde, wrobel priority: feature status: unread title: Remote Microsoft Exchange freebusy fetching in Kolab_Freebusy ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Mon Sep 21 15:23:56 2009 From: issues at kolab.org (Soenke Schwardt-Krummrich) Date: Mon, 21 Sep 2009 13:23:56 +0000 Subject: [Kolab-devel] [issue3871] horde: new option to disable "options" link in left sidebar In-Reply-To: <1253539436.61.0.392271848395.issue3871@kolab.org> Message-ID: <1253539436.61.0.392271848395.issue3871@kolab.org> New submission from Soenke Schwardt-Krummrich : This patch adds a new config option to hide the "options" link in oldstyle sidebar. The "options" link at the menu on the top is unaffected. ---------- assignedto: wrobel files: t_horde_HK_UV_hideOptionsInSidebar.diff keyword: web client messages: 21744 nosy: martin, schwardt, thomas, wilde, wrobel priority: feature status: unread title: horde: new option to disable "options" link in left sidebar ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- Patch by schwardt at univention.de (Fri Sep 11 16:51:37 2009 +0200): horde: new option to disable "options" link in left sidebar This patch adds a new config option to hide the "options" link in oldstyle sidebar. The "options" link at the menu on the top is unaffected. --- a/horde-webmail/config/conf.php +++ b/horde-webmail/config/conf.php @@ -79,6 +79,7 @@ $conf['problems']['tickets'] = false; $conf['problems']['attachments'] = true; $conf['menu']['apps'] = array(); $conf['menu']['always'] = false; +$conf['menu']['options_in_sidebar'] = true; $conf['menu']['links']['help'] = 'all'; $conf['menu']['links']['options'] = 'authenticated'; $conf['menu']['links']['problem'] = 'all'; --- a/horde-webmail/config/conf.xml +++ b/horde-webmail/config/conf.xml @@ -1510,6 +1510,8 @@ false + true 'active', From issues at kolab.org Mon Sep 21 15:43:03 2009 From: issues at kolab.org (Thomas Arendsen Hein) Date: Mon, 21 Sep 2009 13:43:03 +0000 Subject: [Kolab-devel] [issue3872] Domains can be deleted without confirmation In-Reply-To: <1253540583.83.0.123282300672.issue3872@kolab.org> Message-ID: <1253540583.83.0.123282300672.issue3872@kolab.org> New submission from Thomas Arendsen Hein : Kolab Server 2.2.2 (and earlier): When clicking on the Delete button for a domain in the Settings tab, the domain gets deleted without asking for confirmation. Currently not a big problem due to: kolab/issue1571 (Deleting domain does not delete corresponding users/DLs) (i.e. the domain can be created again and at least user accounts are still there, I haven't checked admins, maintainers, domain maintainers or distribution lists) ---------- assignedto: wrobel keyword: server, web admin messages: 21746 nosy: martin, thomas, wilde, wrobel priority: bug status: unread title: Domains can be deleted without confirmation ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Tue Sep 22 10:57:01 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 22 Sep 2009 08:57:01 +0000 Subject: [Kolab-devel] [issue3873] Opening a encrypted mail, without gpg-agent running opens many pw dialogs and crashs In-Reply-To: <1253609821.25.0.798072052929.issue3873@kolab.org> Message-ID: <1253609821.25.0.798072052929.issue3873@kolab.org> New submission from Ludwig Reiter : Observed with Kontact enterprise35 20090907.1024959-kk8 lenny-built with gnupg2 2.0.9-3.1 Test: No gpg-agent is running. 1. Start kontact and switch to the mail component. 2. Select a OpenPGP encrypted mail and press , => The mail display and many password dialogs pop up. 3. Close the mail display. 4. Press cancel in one pw-dialog. => Crash ---------- assignedto: allen keyword: crypto, enterprise35, kde client messages: 21752 nosy: allen, ludwig priority: bug status: unread title: Opening a encrypted mail, without gpg-agent running opens many pw dialogs and crashs ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Tue Sep 22 11:42:09 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 22 Sep 2009 09:42:09 +0000 Subject: [Kolab-devel] [issue3874] Calendar Timeline View: Resize and deactive and activate of a calendar resource changes the duration of the event to 15 mins In-Reply-To: <1253612529.41.0.0600307730785.issue3874@kolab.org> Message-ID: <1253612529.41.0.0600307730785.issue3874@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090907.1024959-kk8 lenny built. Test: 1. Switch to the calendaer component, activate the timeline view. 2. Resize an event to 1 h duration. 3. Deactivate the calendar resource of this event. 4. Activate the calendar resource again. => The duration of the event changed to 15 minutes. Expected: The duration should remain at 1 h. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21753 nosy: allen, ludwig priority: bug status: unread title: Calendar Timeline View: Resize and deactive and activate of a calendar resource changes the duration of the event to 15 mins ______________________________________ Kolab issue tracker ______________________________________ From itsef-admin at brightsight.com Tue Sep 22 17:52:46 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Tue, 22 Sep 2009 17:52:46 +0200 Subject: [Kolab-devel] Upgrade problem Kolab 2.2.0 -> 2.2.2 Message-ID: <200909221752.46330.itsef-admin@brightsight.com> Hi *! We're just in the process of testing an upgrade of our Debian 4.0/Kolab 2.2.0 server to Debian 5.0/Kolab 2.2.2. We are using a separate test machine with an exact copy of the actual installation for this, so we can experiment a bit. The most logical approach seemed to be to upgrade the OS first (Debian 4.0 -> 5.0), then upgrade Kolab itself. The OS upgrade went fine, the Kolab installation (based on the Debian 4.0 OpenPKG RPMs provided by you) was still working. Hence, we went ahead and upgraded the Kolab installation using the Debian 5.0 OpenPKG RPMs (all x86). On first try, the "install-kolab.sh" command failed with an error about a missing "openpkg install script". Apparently, this was caused by the change from Debian 4.0 to 5.0, which caused a mismatch in RPM names. The problem was solved by running "sh openpkg-20071227-20071227_kolab1.ix86-debian5.0-kolab.sh" manually once, followed by the standard "install-kolab.sh" run. According to the upgrade log, the upgrade seemingly went fine. The only thing we noticed was a large number of config files that were moved to ".rpmorig" - contrary to earlier upgrades, where we only encountered ".rpmsave" files. Also, the kolab.conf file was not touched. Subsequently, we tried to follow the upgrade instructions with regard to LDAP. Using slapcat to export the ldif file and manipulating it with the awk script went fine. However, importing the result back into openldap with slapadd (after removing the existing DB, of course) failed: /kolab/sbin/slapadd < test2.ldif bdb_db_open: Warning - No DB_CONFIG file found in directory /kolab/var/openldap/openldap-data: (2) Expect poor performance for suffix dc=my-domain,dc=com. str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=12) As the "dc=my-domain,dc=com" seemed odd, we poked around a bit and found that the old slapd.conf had also been moved to "slapd.conf.rpmorig" - and the new one did not contain any configuration specific to our machine set-up. Also, it seemed to lack a few includes with regard to schemes. We then tried replacing slapd.conf with the old version and - lo and behold - slapadd now worked without error. Given that none of this is mentioned in the upgrade instructions, we are now a bit wary that something might have gone wrong during the upgrade - and hence wary to use the same procedure in the actual upgrade of the production server. Hence the question: Anybody out there who might have an idea as to what happened here and whether something actually went wrong or whether it's just something missing from the upgrade instructions? As always, any enlightenment is most appreciated! Cheerio, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From itsef-admin at brightsight.com Wed Sep 23 10:52:19 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Wed, 23 Sep 2009 10:52:19 +0200 Subject: [Kolab-devel] SOLVED: Upgrade problem Kolab 2.2.0 -> 2.2.2 - Doc-upgrade needed? In-Reply-To: <200909221752.46330.itsef-admin@brightsight.com> References: <200909221752.46330.itsef-admin@brightsight.com> Message-ID: <200909231052.19278.itsef-admin@brightsight.com> Hi all, on a second attempt, we seemingly found the problem: On Tuesday 22 September 2009 17:52:46 ITSEF Admin (UNTRUSTED, sender is not authenticated) wrote: > We're just in the process of testing an upgrade of our Debian 4.0/Kolab > 2.2.0 server to Debian 5.0/Kolab 2.2.2. We are using a separate test > machine with an exact copy of the actual installation for this, so we can > experiment a bit. > > The most logical approach seemed to be to upgrade the OS first (Debian 4.0 > -> 5.0), then upgrade Kolab itself. > > The OS upgrade went fine, the Kolab installation (based on the Debian 4.0 > OpenPKG RPMs provided by you) was still working. Hence, we went ahead and > upgraded the Kolab installation using the Debian 5.0 OpenPKG RPMs (all > x86). > > On first try, the "install-kolab.sh" command failed with an error about a > missing "openpkg install script". Apparently, this was caused by the change > from Debian 4.0 to 5.0, which caused a mismatch in RPM names. The problem > was solved by running > "sh openpkg-20071227-20071227_kolab1.ix86-debian5.0-kolab.sh" manually > once, followed by the standard "install-kolab.sh" run. This seems to be the mistake - running "sh openpkg-20071227-20071227_kolab1.ix86-debian5.0-kolab.sh" manually apparently disrupted the update procedure (despite the log file saying it's still performing an upgrade), thus causing the ".rpmorig" files and the missing slapd.conf file. During the second try, we tried a different approach: When "install-kolab.sh" failed due to the RPM name mismatch (caused by the Debian 4.0 -> 5.0 upgrade), we manually upgraded the RPM in question first with: /kolab/bin/openpkg rpm -Uhv --ignoreos openpkg-20071227-20071227_kolab1.ix86-debian5.0-kolab.rpm Subsequently, we re-ran "install-kolab.sh" and the upgrade including the LDAP modifications worked fine. I'm aware of the fact that this is not the standard upgrade situation, as we upgrade both OS and Kolab. On the other hand, this combination does not seem *too* "outworldly" to me, hence, I am wondering where this could best be documented. Would you like me to create a wish in the bugtracker to add this to the suitable README - or is this better documented in the Wiki (where?)? Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From issues at kolab.org Wed Sep 23 19:13:17 2009 From: issues at kolab.org (Allen Winter) Date: Wed, 23 Sep 2009 17:13:17 +0000 Subject: [Kolab-devel] [issue3876] regression: New Message To: doesn't fill in To: field in composer In-Reply-To: <1253725997.04.0.852776252993.issue3876@kolab.org> Message-ID: <1253725997.04.0.852776252993.issue3876@kolab.org> New submission from Allen Winter : In a message reader, RMB over a From: address and select "New Message To..." from the context menu. a composer window opens, but the To: field isn't filled-in with the selected address; the To: field is empty. same test with "Reply To.." or "Forward To..." works as expected. ---------- assignedto: tmcguire keyword: enterprise35, kde client messages: 21802 nosy: allen, ludwig, tmcguire priority: bug status: unread title: regression: New Message To: doesn't fill in To: field in composer ______________________________________ Kolab issue tracker ______________________________________ From christopher.bertels at intevation.de Wed Sep 23 19:14:22 2009 From: christopher.bertels at intevation.de (Christopher Bertels) Date: Wed, 23 Sep 2009 19:14:22 +0200 Subject: [Kolab-devel] Packaging Sesame2 storage backend for Soprano (Nepomuk) In-Reply-To: <200909181745.44482.christopher.bertels@intevation.de> References: <200909181620.28342.christopher.bertels@intevation.de> <200909181733.28989.bernhard@intevation.de> <200909181745.44482.christopher.bertels@intevation.de> Message-ID: <200909231914.26555.christopher.bertels@intevation.de> Hi, I've uploaded the current version of my packages to files.kolab.org. I've got a buildable version ready, you can get the packages here: http://files.kolab.org/apt/sesame2/ It's still not fully finished (need to clean up most packages - like adding copyright etc...) When starting Nepomuk, Sesame2 seems to get started as the storage backend, but then I get an error (see attachment). Maybe anyone knows what it causing this? I find the error when starting Sesame a little puzzling, since I pretty much got the same versions of all the dependencies I think. Also, the jar file in the original ubuntu package (soprano-backend-sesame) seem pretty much identical. Something else, that I just found out is, that installing the original Ubuntu package gives me pretty much the same error, although it used to work before. I think I've messed up something else. I'd love to hear some feedback, especially if you're getting the same errors as I do. I've attached the error log. I'll try to figure more out tomorrow, but feel free to try it out yourself. Cheers, Christopher. PS: You might need to create a symlink to your libjvm.so in /usr/lib, e.g.: ln -s /usr/lib/jvm/java-6-openjdk/jre/lib/i386/server/libjvm.so /usr/lib/libjvm.so -- Christopher Bertels | OpenPGP key: 0x725D9BE5| 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: sesame2-error Type: text/x-java Size: 15345 bytes Desc: not available Url : http://kolab.org/pipermail/kolab-devel/attachments/20090923/e0509156/sesame2-error.bin -------------- 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/20090923/e0509156/attachment.bin From issues at kolab.org Thu Sep 24 15:26:57 2009 From: issues at kolab.org (Arvid Requate) Date: Thu, 24 Sep 2009 13:26:57 +0000 Subject: [Kolab-devel] [issue3877] String ", Array" appended to value of "Emails" field after modification of contact In-Reply-To: <1253798817.43.0.534522074735.issue3877@kolab.org> Message-ID: <1253798817.43.0.534522074735.issue3877@kolab.org> New submission from Arvid Requate : Affected: horde-webmailer 1.2.0 with kolab-webclient patches 1. Create a contact with an address in "Emails" field", e.g. "user1 at domain.test" 2. Edit contact, changing e.g. the first name. Save. 3. Looking at the "Communications" tab, the value now shows a modified value with the string ", Array" appended: "user1 at domain.test, Array" The XML-Data of that contact in the IMAP folder now shows a second tag with "Array". ---------- assignedto: wrobel keyword: web client messages: 21818 nosy: martin, requate, thomas, wilde, wrobel priority: bug status: unread title: String ", Array" appended to value of "Emails" field after modification of contact ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Thu Sep 24 15:42:29 2009 From: issues at kolab.org (Arvid Requate) Date: Thu, 24 Sep 2009 13:42:29 +0000 Subject: [Kolab-devel] [issue3878] Only first letter of Category assigned to a Contact, creating a new Category In-Reply-To: <1253799749.69.0.528644199392.issue3878@kolab.org> Message-ID: <1253799749.69.0.528644199392.issue3878@kolab.org> New submission from Arvid Requate : Affected: horde-webmailer 1.2.0 with kolab-webclient patches 1. Create a Category (Options>Global Options>Categories and Labels), e.g. "work". 2. Create a new Contact (or edit an existing one), choosing this Category for it. Save. 3. Looking at the tab named "Other", the "Category" field shows only the first letter ("w") of the Category assigned in step 2. 4. Edit some Contact and open the Category dropdown again or open "Options>Global Options>Categories and Labels": It now shows a new Category ("w"). ---------- assignedto: wrobel keyword: web client messages: 21819 nosy: martin, requate, schwardt, thomas, wilde, wrobel status: unread title: Only first letter of Category assigned to a Contact, creating a new Category ______________________________________ Kolab issue tracker ______________________________________ From thomas at intevation.de Thu Sep 24 17:21:36 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Thu, 24 Sep 2009 17:21:36 +0200 Subject: [Kolab-devel] SOLVED: Upgrade problem Kolab 2.2.0 -> 2.2.2 - Doc-upgrade needed? In-Reply-To: <200909231052.19278.itsef-admin@brightsight.com> References: <200909221752.46330.itsef-admin@brightsight.com> <200909231052.19278.itsef-admin@brightsight.com> Message-ID: <20090924172022.573286165.thomas@intevation.de> * ITSEF Admin [20090923 12:41]: > I'm aware of the fact that this is not the standard upgrade situation, as we > upgrade both OS and Kolab. On the other hand, this combination does not seem > *too* "outworldly" to me, hence, I am wondering where this could best be > documented. Would you like me to create a wish in the bugtracker to add this > to the suitable README - or is this better documented in the Wiki (where?)? An issue for this already exists and since I have done some more updates of this kind during the past weeks I should now be able to write a generic documentation for this. 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 ... and we need a dozen cans of tuna From itsef-admin at brightsight.com Thu Sep 24 18:18:24 2009 From: itsef-admin at brightsight.com (ITSEF Admin) Date: Thu, 24 Sep 2009 18:18:24 +0200 Subject: [Kolab-devel] =?iso-8859-1?q?SOLVED=3A_Upgrade_problem_Kolab_2=2E?= =?iso-8859-1?q?2=2E0_-=3E_2=2E2=2E2_-_Doc-upgrade=09needed=3F?= In-Reply-To: <20090924172022.573286165.thomas@intevation.de> References: <200909221752.46330.itsef-admin@brightsight.com> <200909231052.19278.itsef-admin@brightsight.com> <20090924172022.573286165.thomas@intevation.de> Message-ID: <200909241818.24651.itsef-admin@brightsight.com> On Thursday 24 September 2009 17:21:36 Thomas Arendsen Hein wrote: > An issue for this already exists and since I have done some more > updates of this kind during the past weeks I should now be able to > write a generic documentation for this. My apologies, I have to admit to completely forgetting to check whether there might be an existing issue... Is this issue3138 you're talking about? Regards, Thomas -- ------------------------------------------------------------------------------ Thomas Ribbrock, IT-Team brightsight From thomas at intevation.de Fri Sep 25 12:34:25 2009 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Fri, 25 Sep 2009 12:34:25 +0200 Subject: [Kolab-devel] SOLVED: Upgrade problem Kolab 2.2.0 -> 2.2.2 - Doc-upgrade?needed? In-Reply-To: <200909241818.24651.itsef-admin@brightsight.com> References: <200909221752.46330.itsef-admin@brightsight.com> <200909231052.19278.itsef-admin@brightsight.com> <20090924172022.573286165.thomas@intevation.de> <200909241818.24651.itsef-admin@brightsight.com> Message-ID: <20090925123323.359289094.thomas@intevation.de> * ITSEF Admin [20090924 18:53]: > On Thursday 24 September 2009 17:21:36 Thomas Arendsen Hein wrote: > > An issue for this already exists and since I have done some more > > updates of this kind during the past weeks I should now be able to > > write a generic documentation for this. > > My apologies, I have to admit to completely forgetting to check whether there > might be an existing issue... No need to apologize for this. > Is this issue3138 you're talking about? Correct. 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 ... and we need a dozen cans of tuna From issues at kolab.org Fri Sep 25 12:36:30 2009 From: issues at kolab.org (Bernhard Reiter) Date: Fri, 25 Sep 2009 10:36:30 +0000 Subject: [Kolab-devel] [issue3879] It is possible to select the separators by arrow keys when doing address completion the first time )((rt#5853). In-Reply-To: <1253874990.62.0.166869961783.issue3879@kolab.org> Message-ID: <1253874990.62.0.166869961783.issue3879@kolab.org> New submission from Bernhard Reiter : The separator strings can still be selected in the address completion for the composer to field under some conditions. (I could so far not reprodce this with the reply-to field or the event attendee dialog.) How to reproduce: Open an new email composer, use a string for address completion. Use the arrow key to go up. Observation: You can select the contents of the folder separator name, (e.g. "LDAP Server X"). Observation: This only works on the first click in one of the (flexible) To: fields. It also works on the second To: field, but not on the second click into the field. Wild hyptothesis: There seems to be some initialisation missing for this case. Successfully reproduced with Version: 4:3.5.10.enterprise.0.20090914.1023445-kk1 on Etch. Version: 4:3.5.10.enterprise.0.20090907.1024959-kk8 on Etch ---------- assignedto: allen keyword: enterprise35, kde client, kkc messages: 21833 nosy: allen, bernhard, ludwig, till priority: bug status: unread title: It is possible to select the separators by arrow keys when doing address completion the first time )((rt#5853). ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Mon Sep 28 12:32:51 2009 From: issues at kolab.org (Ludwig Reiter) Date: Mon, 28 Sep 2009 10:32:51 +0000 Subject: [Kolab-devel] [issue3880] Calendar: In an update mail the end time of an event is wrongly translated with the "Beginn" In-Reply-To: <1254133971.2.0.739473546337.issue3880@kolab.org> Message-ID: <1254133971.2.0.739473546337.issue3880@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 20090918.1025271-kk1.1 Test: 1. A sends an invitation to B. 2. A moved the event. 3. B syncs and accepts the first mal 4. B looks at the update mail. It contains: Der Beginn dieser Einladung wurde von 2009-09-28 12:30 nach 2009-09-28 13:00 verschoben Der Beginn dieser Einladung wurde von 2009-09-28 13:00 nach 2009-09-28 13:30 verschoben (in English: The begin of the event...from 12:30 to 13:00 The begin of the event.. from 13:00 to 13:30) One begin is wrong here. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21841 nosy: allen, ludwig priority: bug status: unread title: Calendar: In an update mail the end time of an event is wrongly translated with the "Beginn" ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Mon Sep 28 15:20:37 2009 From: issues at kolab.org (Marc Mutz) Date: Mon, 28 Sep 2009 13:20:37 +0000 Subject: [Kolab-devel] [issue3881] [etch/packaging] allow libboost1.35-dev as alternative to libboost-dev in kdepim source package dependencies In-Reply-To: <1254144037.12.0.858199178084.issue3881@kolab.org> Message-ID: <1254144037.12.0.858199178084.issue3881@kolab.org> New submission from Marc Mutz : libboost1.35-dev is from etch-backports that works just as well as libboost-dev, but conflicts with it, dependency-wise. ---------- assignedto: ludwig keyword: debian, enterprise35 messages: 21849 nosy: ludwig, marc status: unread title: [etch/packaging] allow libboost1.35-dev as alternative to libboost-dev in kdepim source package dependencies ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Tue Sep 29 12:51:56 2009 From: issues at kolab.org (Ludwig Reiter) Date: Tue, 29 Sep 2009 10:51:56 +0000 Subject: [Kolab-devel] [issue3882] Composer: Pressing TAB in the address completion popup list doesn't change to the next addressbook In-Reply-To: <1254221516.15.0.92377159131.issue3882@kolab.org> Message-ID: <1254221516.15.0.92377159131.issue3882@kolab.org> New submission from Ludwig Reiter : observed with Kontact e35 lenny 20090918.1025271-kk1.1 Test: 1. Switch to kmail and click on new message. => composer opens. 2. Enter some letters into the To: field. => a popup list appears showing many contacts in different addressbooks. 3. Pressing TAB. => The next address of the same addressbook is selected. It fails to jump to the first address of the next addressbook. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21855 nosy: allen, ludwig priority: bug status: unread title: Composer: Pressing TAB in the address completion popup list doesn't change to the next addressbook ______________________________________ Kolab issue tracker ______________________________________ From christopher.bertels at intevation.de Wed Sep 30 14:47:20 2009 From: christopher.bertels at intevation.de (Christopher Bertels) Date: Wed, 30 Sep 2009 14:47:20 +0200 Subject: [Kolab-devel] Packaging Sesame2 storage backend for Soprano (Nepomuk) In-Reply-To: <200909231914.26555.christopher.bertels@intevation.de> References: <200909181620.28342.christopher.bertels@intevation.de> <200909181745.44482.christopher.bertels@intevation.de> <200909231914.26555.christopher.bertels@intevation.de> Message-ID: <200909301447.25421.christopher.bertels@intevation.de> Hi, I've got the packages working as it seems. You can get the latest packages from http://files.kolab.org/apt/sesame2/ . I've tried the Sesame2 backend with Nepomuk and Akonadi and it works for me. Feedback is, as always, welcome. In the meantime I have also mailed the Debian Java maintainers and asked them to incorporate the packages. I will tell you more once I get an answer there. Cheers, Christopher. -- Christopher Bertels | OpenPGP key: 0x725D9BE5| 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: 198 bytes Desc: This is a digitally signed message part. Url : http://kolab.org/pipermail/kolab-devel/attachments/20090930/f12b3acc/attachment.bin From issues at kolab.org Wed Sep 30 14:45:00 2009 From: issues at kolab.org (Ludwig Reiter) Date: Wed, 30 Sep 2009 12:45:00 +0000 Subject: [Kolab-devel] [issue3883] Calendar resource tree is wrong In-Reply-To: <1254314700.7.0.620770314998.issue3883@kolab.org> Message-ID: <1254314700.7.0.620770314998.issue3883@kolab.org> New submission from Ludwig Reiter : observed with Kontact 20090925.1027940-kk1 A user configures two dimap accounts both containing at least one calendar folder. At the calendar plugin the subresources of both accounts are under "Kolab-Server1". I expect that the subresources of the second account "Kolab-Server2" are inserted under the "Kolab-Server2" resource in the tree. ---------- assignedto: allen keyword: enterprise35, kde client messages: 21868 nosy: allen, ludwig priority: urgent status: unread title: Calendar resource tree is wrong ______________________________________ Kolab issue tracker ______________________________________ From issues at kolab.org Wed Sep 23 12:23:05 2009 From: issues at kolab.org (issues@kolab.org) Date: Wed, 23 Sep 2009 10:23:05 +0000 Subject: [Kolab-devel] [issue3875] Kontact hangs when opening file open dialog of KMail In-Reply-To: <1253701385.7.0.32604275156.issue3875@kolab.org> Message-ID: <1253701385.7.0.32604275156.issue3875@kolab.org> New submission from Emanuel Sch?tze : enterprise4 Windows 20090911.1022317 Test: 1. Start Kontact. 2. Open KMail view. 3. Open "File->Open..." => Kontact hangs! CPU and memory load increase. After some minutes Windows (on my virtual box) freeze. GDB Debug Output (shows continual two warnings only): warning: Debug:kontact(1452)/kio (KDirListerCache) KDirListerCache::listDir: Entry already in use: KUrl("trash:/") warning: Warning:QPixmap::fromWinHBITMAP(), failed to get bitmap bits ---------- assignedto: allen keyword: kde client, kowi messages: 21777 nosy: allen, bernhard, emanuel, ludwig priority: critical status: unread title: Kontact hangs when opening file open dialog of KMail ______________________________________ Kolab issue tracker ______________________________________