From issues at kolab.org  Mon Feb  1 11:05:05 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 01 Feb 2010 10:05:05 +0000
Subject: [Kolab-devel] [issue4075] Calendar: two dimap accounts(A,
	B): Invitation from A to B cannot be answered.
In-Reply-To: <1265018705.57.0.99179291765.issue4075@kolab.org>
Message-ID: <1265018705.57.0.99179291765.issue4075@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100122.1078643-kk1

Test:
The user has two dimap accounts A and B with calendars.
1. As account A invite B to an event.
2. Sync.
3. Look at the mail.
The user cannot react on the invitation, even when he changed his identity.
There are no action buttons in the invitation.

This is a problem, because if a user manually manages a resource(e.g. a beamer),
he will want to accept or reject an invitation as the resource. (with the
resource id).

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23306
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Calendar: two dimap accounts(A,B): Invitation from A to B cannot be answered.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4075>
______________________________________


From issues at kolab.org  Mon Feb  1 15:03:35 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 01 Feb 2010 14:03:35 +0000
Subject: [Kolab-devel] [issue4076] Mail: search for whole message cannot
	handle	umlauts(rt#5979)
In-Reply-To: <1265033015.61.0.455485720255.issue4076@kolab.org>
Message-ID: <1265033015.61.0.455485720255.issue4076@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
0. Create a test folder.
1. Create a test mail with "?" in subject and move it into a test folder
2. Create a test mail with "?" in text and move it into the test folder
3. RMB-> Search... on the test folder.
4. Search for the whole msg with umlaut "?".
=> No msg is shown. Wrong. Two msgs with ? are in this place.
5. Search for the subject "?" or search for msg body with "?"
=> One mail is found : ok. 
I expect the whole msg search to find the two messages with "?".

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23318
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Mail: search for whole message cannot handle umlauts(rt#5979)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4076>
______________________________________


From issues at kolab.org  Mon Feb  1 15:44:16 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 01 Feb 2010 14:44:16 +0000
Subject: [Kolab-devel] [issue4077] descriptions of the different
	spellchecking dictionaries	are confusion(rt#5981)
In-Reply-To: <1265035456.99.0.487827796629.issue4077@kolab.org>
Message-ID: <1265035456.99.0.487827796629.issue4077@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1
            aspell
            
Test:
German is used as lanuage.
1. Open a composer.
2. Activate View->Dictionary
3. Look at the different dictionaries.
The descriptions of the dictionaries are confusion.
E.g. There exist "Deutsch", "Standard - Deutsch(common)" "Deutsch (neu)" etc.
Where is the difference between these dicts?
The English dictionaries descriptions are worse.

Is there a way to improve this?

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23320
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: descriptions of the different spellchecking dictionaries are confusion(rt#5981)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4077>
______________________________________


From thomas at kdab.com  Tue Feb  2 12:38:03 2010
From: thomas at kdab.com (Thomas McGuire)
Date: Tue, 2 Feb 2010 12:38:03 +0100
Subject: [Kolab-devel] Question about the kolab storage format: Tag
	revision.
In-Reply-To: <201001281133.30154.bernhard@intevation.de>
References: <201001221222.15495.ludwig.reiter@intevation.de>
	<201001261647.31112.thomas@kdab.com>
	<201001281133.30154.bernhard@intevation.de>
Message-ID: <201002021238.14217.thomas@kdab.com>

Hi,

On Thursday 28 January 2010 11:33:26 Bernhard Reiter wrote:
> Am Dienstag, 26. Januar 2010 16:47:20 schrieb Thomas McGuire:
> > On Friday 22 January 2010 12:22:15 Ludwig Reiter wrote:
> > > in the kolab.xml in a mail of an event is the tag <revision> which
> > > seems always to be 0. What is this tag for?
> > 
> > I couldn't find any mention of the revision tag at
> > http://www.kolab.org/doc/kolabformat-2.0rc7-html/index.html.
> > Kontact never sets that value, so it is always written as 0.
> 
> Okay, so it should not be written out then.
> (Unless another client created it and it is preserved.)

The revision field is now no longer written out by Kontact, with r1084047.

Regards,
Thomas

-- 
Thomas McGuire | thomas at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100202/9dfd11e5/attachment.bin

From issues at kolab.org  Wed Feb  3 11:34:42 2010
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 03 Feb 2010 10:34:42 +0000
Subject: [Kolab-devel] [issue4078] Webclient: Completion of Email Adresses
	inconvinient
In-Reply-To: <1265193282.88.0.76503308369.issue4078@kolab.org>
Message-ID: <1265193282.88.0.76503308369.issue4078@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

The completion of email addresses during composing of an new mail only
matches on the (start of) name and given name but not on the email
address it self:

Example:

I have two Kolab users:
Test One <1 at example.com>
Test Two <2 at example.com>

User 1 at example.com has the global addressbook activated for use and
starts writing an email:

- When he types "T" he gets a completion for both users (matching "Test")
- When he types "Tw" into the to field he gets a completion for "Test
  Two <2 at example.com>"
- BUT when he types "2" or "2@" he gets no completion.

A completion on the email address itself should be possible.

----------
assignedto: wrobel
keyword: web client
messages: 23336
nosy: martin, thomas, wilde, wrobel
status: unread
title: Webclient: Completion of Email Adresses inconvinient

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4078>
______________________________________


From issues at kolab.org  Wed Feb  3 11:51:30 2010
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 03 Feb 2010 10:51:30 +0000
Subject: [Kolab-devel] [issue4079] Webclient: Completion does not use all
	configured address	books
In-Reply-To: <1265194290.41.0.166295882425.issue4079@kolab.org>
Message-ID: <1265194290.41.0.166295882425.issue4079@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

In the web client the user can select bunch of address books to use by
putting them under "Options" -> "Address Book" -> "Address Books
(Choose which address books to use.)" in the column "These address
books will display in this order".

But for completion of addresses (tested during composing a new mail)
only the first (top most) in the list of address books is used.

This is very bad as it does not allow for completion from more than
one source, which is a quiet common use.  For example the global (LDAP
address book) which contains all users on the server and an private
address book containing individual contacts are often equally used at
the same time.

----------
assignedto: wrobel
keyword: web client
messages: 23338
nosy: martin, thomas, wilde, wrobel
status: unread
title: Webclient: Completion does not use all configured address books

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4079>
______________________________________


From issues at kolab.org  Wed Feb  3 17:56:08 2010
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 03 Feb 2010 16:56:08 +0000
Subject: [Kolab-devel] [issue4080] DIMP: Mails can not be copied to other
	folders
In-Reply-To: <1265216168.94.0.81635717838.issue4080@kolab.org>
Message-ID: <1265216168.94.0.81635717838.issue4080@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

In the dynamic web client (dimp) one can move mails between folders by means of
intuitive drag and drop.  Unfortunately there is no way to _copy_ mails to
another folder (without removing them from their origin).

This is an important feature, which has to be added.

----------
assignedto: wrobel
keyword: web client
messages: 23343
nosy: martin, thomas, wilde, wrobel
priority: bug
status: unread
title: DIMP: Mails can not be copied to other folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4080>
______________________________________


From math.parent at gmail.com  Thu Feb  4 11:01:38 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Thu, 4 Feb 2010 11:01:38 +0100
Subject: [Kolab-devel] wilde: server release-notes.txt, 1.398.2.104,
	1.398.2.105
In-Reply-To: <20100204094449.1819E60016F@lists.intevation.de>
References: <20100204094449.1819E60016F@lists.intevation.de>
Message-ID: <960738411002040201t81e6052v4176680ab62e0465@mail.gmail.com>

On Thu, Feb 4, 2010 at 10:44 AM,  <cvs at kolab.org> wrote:
> Author: wilde
>
> Update of /kolabrepository/server
> In directory doto:/tmp/cvs-serv28393
>
> Modified Files:
> ? ? ?Tag: kolab_2_2_branch
> ? ? ? ?release-notes.txt
> Log Message:
> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
>

Can you add it to http://wiki.kolab.org/index.php/Kolab-major-app-patches?

Thanks

Mathieu Parent


From wilde at intevation.de  Thu Feb  4 11:47:25 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Thu, 04 Feb 2010 11:47:25 +0100
Subject: [Kolab-devel] wilde: server release-notes.txt, 1.398.2.104,
	1.398.2.105
In-Reply-To: <960738411002040201t81e6052v4176680ab62e0465@mail.gmail.com>
	(Mathieu Parent's message of "Thu, 4 Feb 2010 11:01:38 +0100")
References: <20100204094449.1819E60016F@lists.intevation.de>
	<960738411002040201t81e6052v4176680ab62e0465@mail.gmail.com>
Message-ID: <s7wr5p1tgzm.fsf@intevation.de>

Mathieu Parent <math.parent at gmail.com> writes:
> On Thu, Feb 4, 2010 at 10:44 AM,  <cvs at kolab.org> wrote:
>> Author: wilde
[...]
>> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
>>
>
> Can you add it to http://wiki.kolab.org/index.php/Kolab-major-app-patches?

I did so[1].  The information I entered is somewhat specific to 2.2.x as
I didn't get around yet to put the patch into HEAD (which I will do
soon).

cheers
sascha

[1]  though I have to say that editing the wiki templates is -- at least
     to me -- a mayor pita.  Endless lines with `|' separated fields and
     text assigned to meaningless numbers are not what I'd call
     intuitive or easy to grasp...  :-/[2]
[2]  Yes, its a well known fact that I don't like wikis anyway. :)
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100204/e4320cbb/attachment.bin

From math.parent at gmail.com  Thu Feb  4 12:16:19 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Thu, 4 Feb 2010 12:16:19 +0100
Subject: [Kolab-devel] wilde: server release-notes.txt, 1.398.2.104,
	1.398.2.105
In-Reply-To: <s7wr5p1tgzm.fsf@intevation.de>
References: <20100204094449.1819E60016F@lists.intevation.de>
	<960738411002040201t81e6052v4176680ab62e0465@mail.gmail.com>
	<s7wr5p1tgzm.fsf@intevation.de>
Message-ID: <960738411002040316v6d41d1c5rccb1fa75c4761184@mail.gmail.com>

Hello,


On Thu, Feb 4, 2010 at 11:47 AM, Sascha Wilde <wilde at intevation.de> wrote:
> Mathieu Parent <math.parent at gmail.com> writes:
>> On Thu, Feb 4, 2010 at 10:44 AM, ?<cvs at kolab.org> wrote:
>>> Author: wilde
> [...]
>>> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
>>>
>>
>> Can you add it to http://wiki.kolab.org/index.php/Kolab-major-app-patches?
>
> I did so[1]. ?The information I entered is somewhat specific to 2.2.x as
> I didn't get around yet to put the patch into HEAD (which I will do
> soon).
OK


> cheers
> sascha
>
> [1] ?though I have to say that editing the wiki templates is -- at least
> ? ? to me -- a mayor pita. ?Endless lines with `|' separated fields and
> ? ? text assigned to meaningless numbers are not what I'd call
> ? ? intuitive or easy to grasp... ?:-/[2]

Agree. using named parameters would be better (but still not very intuivtive)

> [2] ?Yes, its a well known fact that I don't like wikis anyway. :)

I like them, but sometimes it is harder than writting C.

Mathieu Parent


From issues at kolab.org  Thu Feb  4 12:43:39 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Feb 2010 11:43:39 +0000
Subject: [Kolab-devel] [issue4081] Use of many kmail subwindows can lead to
	crash	(KMFolder::open)(rt#5854)
In-Reply-To: <1265283819.94.0.685092738136.issue4081@kolab.org>
Message-ID: <1265283819.94.0.685092738136.issue4081@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

A customer reported some crashs.
He uses many kmail subwindows like the composer, search window, etc.
and it crashs.
I couldn't reproduce it, so I just provide you with a backtrace.

Allen, can you have a look at the backtrace?
Backtrace: kontact-20100304.kcrash

----------
assignedto: allen
files: kontact-20100304.kcrash
keyword: enterprise35, kde client, kkc
messages: 23356
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Use of many kmail subwindows can lead to crash (KMFolder::open)(rt#5854)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4081>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-20100304.kcrash
Type: application/octet-stream
Size: 2224 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100204/dcd39844/kontact-20100304.exe

From issues at kolab.org  Thu Feb  4 13:36:36 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Feb 2010 12:36:36 +0000
Subject: [Kolab-devel] [issue4082] Wish: Search results in the mail list
	should have a	folder column(rt#5985)
In-Reply-To: <1265286996.38.0.385448672602.issue4082@kolab.org>
Message-ID: <1265286996.38.0.385448672602.issue4082@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Wish for a "folder" column in the normal mail list view, if the user looks at a
search result.

Test:
1. Switch to mail part.
2. Open Search messages dialog.
3. Create a new search "XXX"
4. Close the saerch message dialog.
5. Click on XXX under search results in the folder tree.
=> The mails of the search XXX are displayed in the normal mail list view.
If a search result is selected, the mail list view should also contain a column
"folder" with the folder of the mail. 

Please estimate first and wait on an okay before continuing

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23361
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: Search results in the mail list should have a folder column(rt#5985)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4082>
______________________________________


From issues at kolab.org  Thu Feb  4 13:49:09 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Feb 2010 12:49:09 +0000
Subject: [Kolab-devel] [issue4083] Wish: The composer of a forwared mail (as
	attachment)	should display the original mail(rt#5986)
In-Reply-To: <1265287749.31.0.183055864564.issue4083@kolab.org>
Message-ID: <1265287749.31.0.183055864564.issue4083@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Test:
1. Select a mail in the mail list view.
2. Press on "Forward as attachment"
=> A composer opens with the original mail as attachment.

The customer wishes, that this original mail is displayed.
The display should be like an embedded mail in the mail reader. 

Please estimate first and wait on an okay before continuing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23362
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: The composer of a forwared mail (as attachment) should display the original mail(rt#5986)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4083>
______________________________________


From issues at kolab.org  Thu Feb  4 14:02:07 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Feb 2010 13:02:07 +0000
Subject: [Kolab-devel] [issue4084] Overwriting of an address in the
	To/CC/BCC field of a	composer doesnt work with "Paste" of a
	copied address (rt#5988)
In-Reply-To: <1265288527.05.0.507444391885.issue4084@kolab.org>
Message-ID: <1265288527.05.0.507444391885.issue4084@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
1. Open a composer and enter a wrong address into the To: field.
2. Select a different mail address somewhere else and Copy it (e.g. Ctrl+c)
3. Select the wrong To address and use "Paste" (e.g. Ctrl+v)
=>The wrong address is not overwritten like expected, but the second address is
copied to the first one. In this case (selected wrong address) the address
should be overwritten.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23363
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Overwriting of an address in the To/CC/BCC field of a composer doesnt work with "Paste" of a copied address (rt#5988)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4084>
______________________________________


From wilde at intevation.de  Thu Feb  4 18:03:42 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Thu, 04 Feb 2010 18:03:42 +0100
Subject: [Kolab-devel] Brain Dump of the $ARBITRARY_TIME_SPAN -- heading for
	HEAD...
Message-ID: <s7wy6j9rl01.fsf@intevation.de>

Hi *,

yes its a long time since the last brain dump and I definitely failed on
establishing a weekly issue.  Anyway a lot of stuff happened and so at
least there are some interesting subjects to report on:

The year started with the traditional annual KDE PIM developer meeting.
It a client event and so I wasn't really part of it but there are
various reports on line.[1]  As every year it was an exiting event and
the reports are surly worthwhile reading.  The highlight this year seems
to have been a snowball fight which took place in the "Schlossgarten" of
Osnabr?ck.  You can find pics online, and when you look closely you
might spot some well known people, new to the kolab community.[2]

The server side of things was a bit less bright at January.  We had two
security advisories for the freshly released server 2.2.3: One bug in
spam assassin[3], which wasn't our fault and -- besides being a nuisance
-- was good for a laugh.  The other was a bug in the kolab web admin
interface, definitely our fault and at least in my eyes a bit
embarrassing: users weren't able to change their own user data --
including their passwords.[4]

The later problem showed once more how important thorough testing is,
even and especially of features which always used to work.  So Thomas
and I reactivated our plans to create a more complete formalized testing
protocol for Kolab Server.  Currently I'm evaluating an in house tool,
developed by another department, which allows online (web interface) and
offline use of test protocols.[5]  It looks promising and although it is
primarily intended for internal use at Intevation we will surly publish
the test protocols to community, once they are ready.

By end of January Gunnar finished the first sprint of his work on kolab
server HEAD and it finally builds and works again.  Even more: most of
the fixes from 2.2.3 have been merged and successfully tested!  Big
thanks to Gunnar for his great work!

As a final notice, and hands on feature to test: I committed today a
first version of Bernhard Herzog's Cross Domain ACL support[6].  Its in
2.2.branch (will be merged to HEAD soon).  As always testers are highly
welcome and any reports are appreciated!

That's all folks...
cheers and happy hacking
sascha

[1]  http://dot.kde.org/2010/01/14/annual-osnabr%C3%BCck-pim-meeting-brings-exciting-announcements-and-ambitious-plans
     http://www.linux-magazine.com/Online/News/Cold-War-at-the-Eighth-KDE-PIM-Gathering
     http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_8
[2]  I'm not entitled to state whether this has or has not something to
     do with the exiting news I promised you soon to come...  :)
[3]  http://kolab.org/security/kolab-vendor-notice-26.txt
[4]  http://kolab.org/security/kolab-vendor-notice-27.txt
[5]  For those nosy guys of you, the software can be found here:
     http://hg.intevation.org/intests/
     only the framework, nothing kolab specific yet.
[6]  https://issues.kolab.org/issue1141
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100204/e6ee1b2e/attachment.bin

From issues at kolab.org  Fri Feb  5 11:41:33 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 10:41:33 +0000
Subject: [Kolab-devel] [issue4085] Wish: Mail attachments only in the header
	of a	mail(rt#5987)
In-Reply-To: <1265366493.94.0.851799241683.issue4085@kolab.org>
Message-ID: <1265366493.94.0.851799241683.issue4085@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The customer wishes that mails with attachments only show their attachments in
the mail header. Exception: Mails with embedded mails as attachment should show
the embedded mails. If embedded mails contains attachments, these attachments
should be displayed in the mail body,too. 

At the moment attachments are displayed at two places of the mail:
1. In the header. 
2. At the end of the mail body.

So display place 2. should be removed. (with expections)

Please estimate first, and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23376
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: Mail attachments only in the header of a mail(rt#5987)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4085>
______________________________________


From issues at kolab.org  Fri Feb  5 11:55:37 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 10:55:37 +0000
Subject: [Kolab-devel] [issue4086] Wish: Save encrypted mail decrypted as
	mbox file(rt#5984)
In-Reply-To: <1265367337.55.0.834516893633.issue4086@kolab.org>
Message-ID: <1265367337.55.0.834516893633.issue4086@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The customer wants to save a S/MIME or OpenPGP encrypted mail decrypted to an
mbox file.

In the moment RMB->Save as... on a mail saves this mail encrypted. 
I think, the customer wants a "Save decrypted as..." action (if the mail is
encrypted.) This action should decrypt the mail and then save it into the mbox file.

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23377
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: Save encrypted mail decrypted as mbox file(rt#5984)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4086>
______________________________________


From issues at kolab.org  Fri Feb  5 13:52:45 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 12:52:45 +0000
Subject: [Kolab-devel] [issue4087] Composer: Deletion of one address with
	pressed backspace	jumps to the address field above and
	continues to delete. (rt#5989)
In-Reply-To: <1265374365.36.0.110963265876.issue4087@kolab.org>
Message-ID: <1265374365.36.0.110963265876.issue4087@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
1. Start to create a new mail.
2. Enter an address in the first address field (e.g. TO:)
3. Enter an address in the second address field (e.g. CC:)
4. Select the end of the second address field an press backspace.
=> After deletion of the second address the cursor jumps to the first address
field and continues to delete.
The customer wishs that the adress of the first address field shouldn't be deleted.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23378
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Composer: Deletion of one address with pressed backspace  jumps to the address field above and continues to delete. (rt#5989)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4087>
______________________________________


From issues at kolab.org  Fri Feb  5 14:17:27 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 13:17:27 +0000
Subject: [Kolab-devel] [issue4088] Wish: mail list sorting of a new folder
	should be	configurable(rt#5990)
In-Reply-To: <1265375847.67.0.410390744628.issue4088@kolab.org>
Message-ID: <1265375847.67.0.410390744628.issue4088@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

A user wishs that he has an option to configure the default mail list sorting of
a new created folder. Especially he wants that the mail list of new folder is
sorted with the most current mails up in the list xor down in the list.

In the moment the default sorting of new folders is the sorting of the inbox.

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23379
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: mail list sorting of a new folder should be configurable(rt#5990)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4088>
______________________________________


From issues at kolab.org  Fri Feb  5 14:31:28 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 13:31:28 +0000
Subject: [Kolab-devel] [issue4089] Composer: double click on a word should
	select the word	and not additional spaces, brackets etc.(rt#5991)
In-Reply-To: <1265376688.13.0.555548741723.issue4089@kolab.org>
Message-ID: <1265376688.13.0.555548741723.issue4089@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test (example)
1. Start an composer.
2. Enter "test   )" ( or "test," ) into the mail body.
3. Double click on test.
=> "test   )" is selected. I expect that only the word "test" is selected after 
clicking on it.

The customer wishs:
If he double-clicked on a word in the composer, only the word (first to last
char) should be selected.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23381
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Composer: double click on a word should select the word and not additional spaces, brackets etc.(rt#5991)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4089>
______________________________________


From issues at kolab.org  Fri Feb  5 14:55:55 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 13:55:55 +0000
Subject: [Kolab-devel] [issue4090] Wish:Mail: Double click on mail in search
	dialog should	open the mail in a window(rt#5992)
In-Reply-To: <1265378155.2.0.681150686096.issue4090@kolab.org>
Message-ID: <1265378155.2.0.681150686096.issue4090@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Test:
1. Switch to mail plugin.
2. Open the search dialog and search for a mail.
3. Select that mail in the search list and click on "Open message".
or
3.* Double click on the mail in the search list.
=> Nothing seems to happen. (The mail is selected in the mail viewer of kontact,
but this window is in the background under the search dialog.)

Wish of the customer: The mail is opened in a own window.

There are some kolab/issues which are related: kolab/issue2188, kolab/issue2140,
kolab/issue3360 (windows), kolab/issue2217.

Please estimate and wait on an okay before continuing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23382
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish:Mail: Double click on mail in search dialog should open the mail in a window(rt#5992)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4090>
______________________________________


From issues at kolab.org  Fri Feb  5 15:42:09 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Feb 2010 14:42:09 +0000
Subject: [Kolab-devel] [issue4091] Wish mail count of the mail icon in the
	system tray	should only count the "new" messages.(rt#5994)
In-Reply-To: <1265380929.93.0.992157188554.issue4091@kolab.org>
Message-ID: <1265380929.93.0.992157188554.issue4091@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The kmail icon in the system tray counts the mails with "unread" and "new" status.

The customer wants that only the mails with status "new" are counted.

Test:
Req: 2 unread mails in the inbox
     system tray icon is displayed.
1. Mark a mail as unread.
=> The count on the icon is three.(should be zero)
2. send two new mails to the account and sync.
=> The count is five. (should be two)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23385
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish mail count of the mail icon in the system tray should only count the "new" messages.(rt#5994)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4091>
______________________________________


From thomas at intevation.de  Fri Feb  5 16:01:15 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 5 Feb 2010 16:01:15 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20100108161200.64545k3ai5dxk1s0@webmail.pardus.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
	<20091229131129.146771067.thomas@intevation.de>
	<20100108161200.64545k3ai5dxk1s0@webmail.pardus.de>
Message-ID: <20100205155632.642555301.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20100108 16:12]:
> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>
>> * Richard Bos <ml at radoeka.nl> [20091209 08:51]:
>>> So, actually what you want to do is to move the directories
>>>  server/kolabd/kolabd           to src/kolabd
>>>  server/kolab-admin/kolab-admin to src/kolab-admin
>>>  and
>>>  server/perl-kolab              to src/perl-kolab
>>
>> Please keep everything somewhere below server, I don't want a
>> different module (or directory) here, only subdirectories of server.
>>
>
> Can you detail why?
>
> Keeping them on the same level would indicate to me that the source  
> directories have similar content to the packaging directories. Which  
> they don't.

In the past (before you moved much code to the Horde repositories)
all code specific to Kolab Server lived in "server". Now to see all
code I already have to look in other places.

When you move some things to "src" next to "server", I will have to
checkout yet another repository (even if on the same CVS server) and
have to do tagging/branching/thinking/whatever in two separate
places.

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
-------------- 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/20100205/03456957/attachment.bin

From issues at kolab.org  Sat Feb  6 09:52:20 2010
From: issues at kolab.org (Marc Mutz)
Date: Sat, 06 Feb 2010 08:52:20 +0000
Subject: [Kolab-devel] [issue4092] New Certificate Wizard: no Cetificate
	Usage when [x] show	all details
In-Reply-To: <1265446340.44.0.523172543442.issue4092@kolab.org>
Message-ID: <1265446340.44.0.523172543442.issue4092@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

To reproduce:
1. File -> New Certificate -> OpenPGP
2. Enter some details -> Next -> [x] show all details
=> Certificate Usage line disappears

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23393
nosy: emanuel, marc
priority: minor bug
status: in-progress
title: New Certificate Wizard: no Cetificate Usage when [x] show all details

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4092>
______________________________________


From issues at kolab.org  Mon Feb  8 11:00:43 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Feb 2010 10:00:43 +0000
Subject: [Kolab-devel] [issue4093] In "enterprise" mail header CC and BCC
	addresses are	displayed under the TO field (rt#5996)
In-Reply-To: <1265623243.45.0.927472124528.issue4093@kolab.org>
Message-ID: <1265623243.45.0.927472124528.issue4093@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
1. Send a mail to a different TO, CC and BCC address-
2. Switch header type to "enterprise"
3. Look at the test mail in the sent-mails folder.
=> All three addresses are displayed under "TO" (German: "An:")
CC/BCC should be displayed in own fields.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23406
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: In "enterprise" mail header CC and BCC addresses are displayed under the TO field (rt#5996)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4093>
______________________________________


From issues at kolab.org  Mon Feb  8 11:16:44 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Feb 2010 10:16:44 +0000
Subject: [Kolab-devel] [issue4094] Scrollbar position changes,
	if a new mail is synced into the folder.(rt#5997)
In-Reply-To: <1265624204.16.0.676115265569.issue4094@kolab.org>
Message-ID: <1265624204.16.0.676115265569.issue4094@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
Req: inbox folder with many mails.
     New mails should appear at the bottom. (date sorting)
1. Scroll to the bottom.
2. Send a new mail to the test account.
3. Sync.
=> The scrollbar is no longer at the bottom of the folder. So the new mail is
not displayed and could be missed.

The customer wishes, that the relativ position of the scrollbar stays the same.
So if I scroll to the bottom of the folder and new mails are synced into the
folder, they should be displayed.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23408
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Scrollbar position changes, if a new mail is synced into the folder.(rt#5997)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4094>
______________________________________


From issues at kolab.org  Mon Feb  8 11:28:24 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Feb 2010 10:28:24 +0000
Subject: [Kolab-devel] [issue4095] Wish: Multiselection of events to delete,
	move or copy(rt#5998)
In-Reply-To: <1265624904.19.0.571724985062.issue4095@kolab.org>
Message-ID: <1265624904.19.0.571724985062.issue4095@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The customer wishs, that it is possible to select some events (not just a single
one) (e.g. with Ctrl pressed), so that he can delete, move or copy these events.

This is an important wish for the customer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23409
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: Multiselection of events to delete, move or copy(rt#5998)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4095>
______________________________________


From issues at kolab.org  Mon Feb  8 11:58:13 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Feb 2010 10:58:13 +0000
Subject: [Kolab-devel] [issue4096] User with write access to a calendar
	folder should be	able to change the events (even if he isnot
	the organizer)(rt#5999)
In-Reply-To: <1265626693.45.0.490999626477.issue4096@kolab.org>
Message-ID: <1265626693.45.0.490999626477.issue4096@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Test:
Req: A and B has write access to calendar K
1. A invites B to an event and saves the event in K.
2. B changes the event in K.
=> At the moment B gets an warning, that he is not the organizer and no update
mails are sent to A. (So currently only the organizer can change the event.)
The user wishs, that B (even if he is not the organizer) can change the event
and an update mail is send to all attendees. 

This is an important wish for the customer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23412
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: User with write access to a calendar folder should be able to change the events (even if he isnot the organizer)(rt#5999)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4096>
______________________________________


From issues at kolab.org  Mon Feb  8 12:16:57 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Feb 2010 11:16:57 +0000
Subject: [Kolab-devel] [issue4097] Wish for an option: reply should always
	quote the whole	mail.(rt#5995)
In-Reply-To: <1265627817.97.0.229352303838.issue4097@kolab.org>
Message-ID: <1265627817.97.0.229352303838.issue4097@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20100129.1082029-kk1

Test:
1. Click on a mail in the mail list.
2. Select a part of the text.
3. Press reply.
=> Only the selected text is quoted.
The user wishes an option, that in this case always the whole mail is quoted.
He doesn't like the selected quotation. But other users like it this way. 

Another problem is the option (German) "Intelligent zitieren", this option
should be renamed, so that the users better understand, what it does.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23413
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish for an option: reply should always quote the whole mail.(rt#5995)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4097>
______________________________________


From issues at kolab.org  Mon Feb  8 14:04:01 2010
From: issues at kolab.org (Thomas Ribbrock)
Date: Mon, 08 Feb 2010 13:04:01 +0000
Subject: [Kolab-devel] [issue4098] Cannot import "archived" mails into local
	folders
In-Reply-To: <1265634241.03.0.723180234889.issue4098@kolab.org>
Message-ID: <1265634241.03.0.723180234889.issue4098@kolab.org>


New submission from Thomas Ribbrock <itsef-admin at brightsight.com>:

Just ran into this with enterprise35 20100204.1084898 (Kubuntu 8.04):

I was experimenting with the new folder archiving function (which is a feature
some of our users are probably eager to use...). I archived two folders from an
online IMAP account:
A) Folder with one subfolder and using tar.bz2 as format, ~9MB
B) Folder with no subfolder, tar.gz format ~750KB

I can re-import (B) (have not tried (A) yet due to time constraints) without
problems into another online IMAP folder. However, if I try to import any of the
two into a folder that is located under "Local Folders", I get a "Fatal Error"
dialogue stating "kontact: WARNING: KMail encountered a fatal error and will
terminate now.
The error was: Message could not be added to the folder, possibly disk space is
low." After clicking OK, Kontact vanishes/shuts down.

I've tried this with both existing and newly created folders in "Local Folders".
For some odd reasons, I am not able to pick the top level "Local Folders" folder
as target - that option is not given in the folder selection dialog that
"Import" brings up.

The Local Folders are located in $HOME/Mail on an NFS4 share - which has some
40GB left, so disk space in local folders itself cannot be the issue. /tmp has
more than 1GB left.

Hm. Very strange. I just ran another test, using archive (B):
 1) Create subfolder "000" in "Local Folders"
 2) "File -> Import Messages -> Import KMail Archive File"
 3) Select "Local Folders/000" as target and B.tar.gz as archive
 4) KMail shuts down with the error message mentioned above
 5) Check $HOME/Mail:
    - .000.directory exists as expected
    - .000.directory contains two directory "B" and ".B.directory", also as
expected.
    - BOTH directories miss the "x" permission - they are mode 600. That's odd,
this should be 700, no?
    - Directory "B" *does* contain the directories "cur", "tmp" and "new", with
correct permisions (700). For the rest, everything is empty.

Very odd...

If there's anything else I can test/provide you with, please let me know.

----------
keyword: enterprise35, kde client
messages: 23415
nosy: itsef_admin
priority: bug
status: unread
title: Cannot import "archived" mails into local folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4098>
______________________________________


From wrobel at pardus.de  Tue Feb  9 08:47:36 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 09 Feb 2010 08:47:36 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20100205155632.642555301.thomas@intevation.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
	<20091229131129.146771067.thomas@intevation.de>
	<20100108161200.64545k3ai5dxk1s0@webmail.pardus.de>
	<20100205155632.642555301.thomas@intevation.de>
Message-ID: <20100209084736.16225kze2spohc00@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> * Gunnar Wrobel <wrobel at pardus.de> [20100108 16:12]:
>> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>>
>>> * Richard Bos <ml at radoeka.nl> [20091209 08:51]:
>>>> So, actually what you want to do is to move the directories
>>>>  server/kolabd/kolabd           to src/kolabd
>>>>  server/kolab-admin/kolab-admin to src/kolab-admin
>>>>  and
>>>>  server/perl-kolab              to src/perl-kolab
>>>
>>> Please keep everything somewhere below server, I don't want a
>>> different module (or directory) here, only subdirectories of server.
>>>
>>
>> Can you detail why?
>>
>> Keeping them on the same level would indicate to me that the source
>> directories have similar content to the packaging directories. Which
>> they don't.
>
> In the past (before you moved much code to the Horde repositories)
> all code specific to Kolab Server lived in "server". Now to see all
> code I already have to look in other places.

The code I moved to the Horde repository is not "Kolab specific".  
Free/Busy is something other projects do as well. Resource management  
is also not specific to the Kolab server. Horde offers the same  
features - albeit currently not in the same complexity as the Kolab  
server does. Merging our libraries with the Horde code is an ongoing  
effort.

>
> When you move some things to "src" next to "server", I will have to
> checkout yet another repository (even if on the same CVS server) and
> have to do tagging/branching/thinking/whatever in two separate
> places.

I wanted to move the source code into "server/src".

We discussed the same issue on the phone yesterday and we agreed that we would
simply use the structure currently in place in "kolabd" and  
"kolab-webadmin". Having a second level directory that contains the  
source which is named in the same way as the top level directory. So  
the only change of the current system would be to add  
"server/perl-kolab/perl-kolab" and move the source code into that  
directory.

We'd build source tars in server/perl-kolab/perl-kolab (using  
Makefile.PL) and publish them on files.kolab.org. The Makefile and  
spec-file in "server/perl-kolab" would then download the source from  
there and package it.

Thomas mentioned he won't move directories on the server so I'll do it  
on the client side.

Cheers,

Gunnar
>
> 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
>



-- 
______ 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/20100209/a0fbcdfe/attachment.bin

From issues at kolab.org  Wed Feb 10 14:14:16 2010
From: issues at kolab.org (Marc Mutz)
Date: Wed, 10 Feb 2010 13:14:16 +0000
Subject: [Kolab-devel] [issue4099] Infinite loop when no smartcard reader is
	attached
In-Reply-To: <1265807656.41.0.491520299147.issue4099@kolab.org>
Message-ID: <1265807656.41.0.491520299147.issue4099@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

When running without a smartcard present, scdaemon 2.0.12 causes Kleopatra to 
go into an infinite loop, as it constantly re-writes reader_0.status:

ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__update__"  ; nullSlot= true
<update_cardinfo>
get_card_info( "/home/marc/.gnupg/reader_0.status" , 0 , 0xb5cbb0 , NoCard , 
true )
get_more_detailed_status( "/home/marc/.gnupg/reader_0.status" , 0 , 0xb5cbb0 )
gpgagent_transact( SCD SERIALNO )
gpgagent_transact( SCD SERIALNO ): "Card not present"
</update_cardinfo>
gpgagent_transact( GETEVENTCOUNTER )
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "295 0 295"
)
ReaderStatusThread[2nd]: .zZZ
kleopatra(12339) 
Kleo::FileSystemWatcher::Private::onFileChanged: "/home/marc/.gnupg/reader_0.status"
ReaderStatusThread[GUI]::ping()
ReaderStatusThread[2nd]: .oOO

Kleopatra should be more robust when faced with older scdaemons.
Setting to minor only, because current scdaemons don't show this problem.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23470
nosy: emanuel, marc
priority: minor bug
status: unread
title: Infinite loop when no smartcard reader is attached

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4099>
______________________________________


From issues at kolab.org  Wed Feb 10 14:43:22 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Feb 2010 13:43:22 +0000
Subject: [Kolab-devel] [issue4100] Wish: It should be possible to change the
	resource column	size in the side-by-side view (rt#6001)
In-Reply-To: <1265809402.71.0.83917499204.issue4100@kolab.org>
Message-ID: <1265809402.71.0.83917499204.issue4100@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

A customer wishes that it should be possible to resize the width of the agenda
columns in the side-by-side view.
At the moment the width of the resource columns/agenda columns are fixed.

Please estimate and wait on an okay before continuing

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23472
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: It should be possible to change the resource column size in the side-by-side view (rt#6001)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4100>
______________________________________


From issues at kolab.org  Wed Feb 10 15:03:08 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Feb 2010 14:03:08 +0000
Subject: [Kolab-devel] [issue4101] edit or copy/move/paste of an event with
	recurrence	should ask how to handle recurrence(rt#6002)
In-Reply-To: <1265810588.45.0.35948095219.issue4101@kolab.org>
Message-ID: <1265810588.45.0.35948095219.issue4101@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1087948-kk3

Test:
1. Create an event with recurrence(daily, 3 times)
2. Select the second event of these events.
3. Edit.
4. Change the time.
=> The event is changed without asking about the recurrence.
It is wrong. And the second event becomes the first in the series.
I expect that the user is asked, how to handle the recurrence. Like he is asked,
if he deletes an event with recurrence.

Another Test:
1. Create an event with recurrence(daily, 3 times)
2. Select the second event of these events.
3. Copy 
4. Select a different time.
5. Paste

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23473
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: edit or copy/move/paste of an event with recurrence should ask how to handle recurrence(rt#6002)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4101>
______________________________________


From issues at kolab.org  Wed Feb 10 15:32:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Feb 2010 14:32:06 +0000
Subject: [Kolab-devel] [issue4102] Wish: type of attendee of an event should
	be displayed in	the small event pane(rt#6004)
In-Reply-To: <1265812326.4.0.916677647959.issue4102@kolab.org>
Message-ID: <1265812326.4.0.916677647959.issue4102@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1087948-kk3

Test: 
1. Create an new event with attendees of different types (Observer,..)
2. Press Okay.
3. Select the event.
In the small event pane at the left side all attendees are displayed under
Attendees. The different types are not displayed.
The customer wishes that here different types of attendees are also displayed.
Change the tooltip, too.

Please estimate and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23474
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: type of attendee of an event should be displayed in the small event pane(rt#6004)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4102>
______________________________________


From issues at kolab.org  Wed Feb 10 15:40:22 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Feb 2010 14:40:22 +0000
Subject: [Kolab-devel] [issue4103] Wish: It should be possible to minimize a
	creation/edit	dialog of an event
In-Reply-To: <1265812822.05.0.632665733676.issue4103@kolab.org>
Message-ID: <1265812822.05.0.632665733676.issue4103@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1087948-kk3

Test:
1. Select an event.
2. Edit 
3. Look at the window header.
=> It is not possible to minimize the dialog.
The customer likes to minimize these dialogs.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23475
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: It should be possible to minimize a creation/edit dialog of an event

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4103>
______________________________________


From issues at kolab.org  Wed Feb 10 15:59:52 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Feb 2010 14:59:52 +0000
Subject: [Kolab-devel] [issue4104] accept invitations without activated
	calendar resource	(rt#6007)
In-Reply-To: <1265813992.9.0.55215850663.issue4104@kolab.org>
Message-ID: <1265813992.9.0.55215850663.issue4104@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Test:
1. A invites B to an event.
2. B deactives all his calendar resources.
3. B syncs, gets the invitation and accepts.
=> An error message is shown that he has no resource with write access.
The customer wants to add the event to a deactivated calendar resource.

Test:
1. A invites B to an event.
2. B deactives some of his calendar resources.
3. B syncs, gets the invitation and accepts
=> Now the customer also wants to enter the event into one of the deactivated
calendar resources.

So:
The deactived calendar resources should also be choosable, if the user accepts,
cond. accepts,... an event.

This is important for the customer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23476
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: accept invitations without activated calendar resource (rt#6007)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4104>
______________________________________


From thomas at btspuhler.com  Thu Feb 11 05:24:05 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Wed, 10 Feb 2010 21:24:05 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
Message-ID: <201002102124.05829.thomas@btspuhler.com>

I am packaging the kolab-2.2.3 on the Mandriva System.

I upgraded the installed kolab 2.1.0 and now
I can add and delete users using the /usr/lib/kolab/adduser scripts.
I then can read e-mails after the upgrade I sent and received before the 
upgrade.
I can send e-mails after the upgrade, but the don't go anywhere. the log shows 
problems with  kolabmailboxfilter
This filter was in kolab2.1.0 provided by the resource-manager, but this isn't 
used anymore. Where are these filters now?

Below is the relevant part of the log.


Feb 10 21:13:38 localhost imap[22474]: login: localhost [127.0.0.1] 
brigittespuhler at localhost plain+TLS User logged in
Feb 10 21:13:39 localhost imap[22474]: seen_db: user brigittespuhler at localhost 
opened /var/lib/imap/domain/l/localhost/user/b/brigittespuhler.seen
Feb 10 21:13:39 localhost postfix/pipe[22471]: 32C8521561: 
to=<thomasspuhler at localhost>, relay=kolabfilter, delay=2, 
delays=0.34/0.08/0/1.6, dsn=5.3.0, status=bounced (Command died with status 1: 
"/usr/bin/php". Command output: Could not open input file: /usr/bin/kolabfilter 
)
Feb 10 21:13:39 localhost postfix/cleanup[22470]: EDE1C215C7: message-
id=<20100211041339.EDE1C215C7 at localhost>
Feb 10 21:13:39 localhost postfix/qmgr[3154]: EDE1C215C7: from=<>, size=2785, 
nrcpt=1 (queue active)
Feb 10 21:13:39 localhost postfix/bounce[22480]: 32C8521561: sender non-
delivery notification: EDE1C215C7
Feb 10 21:13:39 localhost postfix/qmgr[3154]: 32C8521561: removed
Feb 10 21:13:40 localhost postfix/pipe[22482]: EDE1C215C7: 
to=<brigittespuhler at localhost>, relay=kolabmailboxfilter, delay=0.33, 
delays=0.02/0.04/0/0.28, dsn=5.3.0, status=bounced (Command died with status 
1: "/usr/bin/php". Command output: Could not open input file: 
/usr/bin/kolabmailboxfilter )
Feb 10 21:13:40 localhost postfix/qmgr[3154]: EDE1C215C7: removed

I would appreciate some help.
-- 
Thomas


From issues at kolab.org  Thu Feb 11 13:53:58 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Feb 2010 12:53:58 +0000
Subject: [Kolab-devel] [issue4105] Three warning dialogs appears,
	if I try to create an event and have deactivated the Task resources.
In-Reply-To: <1265892838.09.0.785075000942.issue4105@kolab.org>
Message-ID: <1265892838.09.0.785075000942.issue4105@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim   20100205.1088342-kk4

1. Switch to the calendar.
2. Deactivate the tasks subresources of the Kolab Server resource.
3. Switch to to-dos.
4. Try to create a new task with the textfield.
=> 1.warning.Press Ok. 2.warning. Press Ok. 3.warning.
Three warning appears.
1.warning (German) Keine Ressource mit Schreibzugriff gefunden. Speichern ist
daher nicht m?glich. ?ndern Sie zuerst die Einstellungen in KMail.
2. warning (German) Speichern von Todo "test" in den Kalender ausgew?hlt nicht
m?glich. (Wrong German)
3. warning (German) Speichern von Todo "test" nicht m?glich.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23486
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Three warning dialogs appears, if I try to create an event and have deactivated the Task resources.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4105>
______________________________________


From issues at kolab.org  Thu Feb 11 14:09:09 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Feb 2010 13:09:09 +0000
Subject: [Kolab-devel] [issue4106] Not possible to create an event or task,
	if all resources are deactivated(rt#6008)
In-Reply-To: <1265893749.31.0.220733980756.issue4106@kolab.org>
Message-ID: <1265893749.31.0.220733980756.issue4106@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

It should be possible to save a new created event or task to a deactivated resource.

Test (task):
1. Switch to the calendar.
2. Deactivate all task resources.
3. Press on the button and select "New task"
=> Task creation dialog appears
4. Enter a title.
5. Press Okay.
=> error msg appears: the event couldn't be saved.

Test (event):
1.Switch to the calendar.
2. Deactivate some of the event resources.
3. Create a new event with a title.
=> It is not possible to save the event to a deactivated resource, because the
deactivated calendar resources are not in the resource chooser dialog.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23487
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Not possible to create an event or task, if all resources are deactivated(rt#6008)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4106>
______________________________________


From issues at kolab.org  Thu Feb 11 14:23:10 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Feb 2010 13:23:10 +0000
Subject: [Kolab-devel] [issue4107] In workweek mode clicking on the month
	pane week number	selects whole week. (rt#6013)
In-Reply-To: <1265894590.93.0.991031429631.issue4107@kolab.org>
Message-ID: <1265894590.93.0.991031429631.issue4107@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

A customer expects that if he uses workweek agenda mode and clicks on the week
number in the month pane (upper left) that then the work week will be selected
and not the whole week.

Perhaps the user could configure how to handle the week numbers in the month
pane. (Select whole week or select work week)

Test:
1. Set option to select work week, if clicked on week numbers in the month pane.
2. Select a day in the month pane.
3. Click on the week number (left side in the month pane)
? Is the work week of the number is selected? (Should be: Yes)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23488
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: In workweek mode clicking on the month pane week number selects whole week. (rt#6013)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4107>
______________________________________


From issues at kolab.org  Thu Feb 11 15:10:32 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Feb 2010 14:10:32 +0000
Subject: [Kolab-devel] [issue4108] Reminder option "remind me later" should
	work even if I	closed the session (rt#6016)
In-Reply-To: <1265897432.92.0.00279152572505.issue4108@kolab.org>
Message-ID: <1265897432.92.0.00279152572505.issue4108@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

If a user choose "remind me later" in the reminder and selects 1 h and closes
the KDE session, he expects to get a reminder the next day after starting kontact.

tested with Kontact e35 kdepim   20100205.1088342-kk4

Test:
1. Create a new event with reminder in a few minutes.
2. Wait for the reminder.
=> reminder pops up.
3. Choose remind me later(2 mins).
4. Close the KDE test session.
5. Wait 4 minutes.
6. Restart the KDE test session and kontact
=> No reminder appears.
I expect the reminder to appear after the start of kontact.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23491
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Reminder option "remind me later" should work even if I closed the session (rt#6016)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4108>
______________________________________


From ml at radoeka.nl  Thu Feb 11 19:23:08 2010
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 11 Feb 2010 19:23:08 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002102124.05829.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
Message-ID: <201002111923.08513.ml@radoeka.nl>

Op donderdag 11 februari 2010 05:24:05 schreef Thomas Spuhler:
> I am packaging the kolab-2.2.3 on the Mandriva System.
> 
> I upgraded the installed kolab 2.1.0 and now
> I can add and delete users using the /usr/lib/kolab/adduser scripts.
> I then can read e-mails after the upgrade I sent and received before the 
> upgrade.
> I can send e-mails after the upgrade, but the don't go anywhere. the log
>  shows  problems with  kolabmailboxfilter
> This filter was in kolab2.1.0 provided by the resource-manager, but this
>  isn't  used anymore. Where are these filters now?

 kolab2:~ # rpm -qf /usr/bin/kolabfilter
kolab-filter-0.1.7-2.1

You can download it from:
http://pear.horde.org/index.php?package=Kolab_Filter&release=0.1.8&downloads

-- 
Richard


From wrobel at pardus.de  Thu Feb 11 22:10:10 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 11 Feb 2010 22:10:10 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <000301caa013$021da340$0658e9c0$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch>
	<201001251436.49129.bernhard@intevation.de>
	<000301caa013$021da340$0658e9c0$@ch>
Message-ID: <20100211221010.29291rrgipu49fe8@webmail.pardus.de>

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi
>
> It is from my point of view clear the search function but even I see the
> lines I can not identify what is false and why?:
>
> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>
>
> 201    function search( $base, $filter, $attrs = false ) {
>    202      $this->freeSearchResult();
>    203      if( $attrs ) {
>    204            $this->search_result = ldap_search( $this->connection,
> $base, $filter, $attrs );
>    205          } else {
>    206            $this->search_result = ldap_search( $this->connection,
> $base, $filter );
>    207          }
>    208      return $this->search_result;
>    209    }

The error sounds as if $base contains an invalid value. You could add  
a "var_dump($base);" in the code to display the value.

Both log entries you mentioned are just warnings though. The code  
won't stop on a warning. And the code of the web admin is not exactly  
clean when it comes to notices and warnings. Quite the contrary. So  
what you see might not be a real problem.

But I did not quite understand what kind of problems you saw in the  
actual frontend. Did you see any specific errors that were displayed?  
Or did the web admin just show you a blank page (the PHP white screen  
of death)?

Cheers,

Gunnar

>
>
> is not a valid ldap result resource in
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>
>    411    // Count the number of occurences of an email address
>    412    // in users' mail and alias attributes and in dist. lists.
>    413    // This can be used to check for uniqueness etc.
>    414    function countMail( $base, $mail , $excludedn=false ) {
>    415          // First count users
>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>    417                         (alias='.$this->escape($mail).')
>    418                       )
>    419                       (uid='.$this->escape($mail).')
>    420                     )';
>    421          $res = $this->search( $this->dn_escape($base), $filter,
> array( 'dn' ) );
>    422          $count = 0;
>    423
>    424          $entries = ldap_get_entries( $this->connection, $res );
>    425          if( $excludedn ) {
>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>    427                  if( is_null( $entries[$i] ) ) continue;
>    428                  if( KolabLDAP::unescape_dn_value($entries[$i]['dn'])
> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>    429                  debug("found ".$entries[$i]['dn'] );
>    430                  $count++;
>    431            }
>    432          } else $count += $entries['count'];
>
>
> Kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
> -----Urspr?ngliche Nachricht-----
> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Montag, 25. Januar 2010 14:37
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
> 204
>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied argument
>> is not a valid ldap result resource in
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>
>> Is this already recognized? Is it not known....I tried to figure out what
>> is wrong but actually I could not?!
>>
>> Any suggestion?
>
> My suggestion is to check the given line 204 and see which argument
> is used there (maybe add a statement to print it out).
>
>> By the way is there a documentation about Master/Slave configuration
>> meaning how this works etc. I could not find anything. Any hints would be
>> appriciated.
>
> I think the documentation is in the architecture documents.
> The idea is pretty simple: Replicate the directory server on the slave
> (for which there is a bootstrap) have all read access on the slave accounts
> go
> to the slave LDAP server and all write access (only by webadmin) to the
> master.
>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------



From issues at kolab.org  Fri Feb 12 10:18:45 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 09:18:45 +0000
Subject: [Kolab-devel] [issue4109] Task with recurrence: Startime not saved
	(rt#6019)
In-Reply-To: <1265966325.09.0.276990621106.issue4109@kolab.org>
Message-ID: <1265966325.09.0.276990621106.issue4109@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Switch to the todos
2. Start to create a new todo with the button.
3. Set time associate
4. Enter start time (e.g 2010-02-12 10:00) and different end time 
   (e.g.2010-02-12 12:00)
5. Set recurrence to daily.
6. Press okay.
7. Edit the test todo again.
=> Now the start time equals the end time (is changed). I expect that the start
time is saved and used if the todo is edited again or displayed in this case.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23501
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Task with recurrence: Startime not saved (rt#6019)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4109>
______________________________________


From issues at kolab.org  Fri Feb 12 10:31:14 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 09:31:14 +0000
Subject: [Kolab-devel] [issue4110] Task with recurrence: due of a selected
	task in calendar	doesn't match the right date.(rt#6020)
In-Reply-To: <1265967074.13.0.74838951075.issue4110@kolab.org>
Message-ID: <1265967074.13.0.74838951075.issue4110@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Create a daily recurrence todo today at 10:00 to 12:00
2. Switch to the calendar.
3. Select the test todo at the date of tomorrow.
4. Look at the small display of the todo.
=> the due part displays today, but the start is tomorrow. This is confusing for
the user. He wishes that the due is of the day of the todo.
Please also look at the edit dialog,the tooltip and the month view.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23502
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Task with recurrence: due of a selected task in calendar doesn't match the right date.(rt#6020)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4110>
______________________________________


From issues at kolab.org  Fri Feb 12 10:44:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 09:44:06 +0000
Subject: [Kolab-devel] [issue4111] Side-by-side view: Horizontal Scrollbar
	is always	displayed, even when there is enough space. (rt#6014)
In-Reply-To: <1265967846.73.0.216604126163.issue4111@kolab.org>
Message-ID: <1265967846.73.0.216604126163.issue4111@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Switch to the calendar.
2. Change to side-by-side view.
=> a horizontal scrollbar is displayed.
3. Resize kontact.
4. Just activate only one calendar resource.
=> the horizontal scrollbar is displayed.
The user expects that the scroll bar disappears, if he resizes kontact to a big
size and selects just one or two calendar resources.
It should be possible with activation of just a few calendar resources and
resizeing the width of kontact to get ride of this horizontal scrollbar.

Please estimate first and wait for an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23504
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Side-by-side view: Horizontal Scrollbar is always displayed, even when there is enough space. (rt#6014)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4111>
______________________________________


From issues at kolab.org  Fri Feb 12 11:07:23 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 10:07:23 +0000
Subject: [Kolab-devel] [issue4112] Event/Task conflict dialog is too
	difficult. (rt#6009)
In-Reply-To: <1265969243.82.0.157668453247.issue4112@kolab.org>
Message-ID: <1265969243.82.0.157668453247.issue4112@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

The difficult text and the many options of the event/task conflict dialog
confuses some users. They don't understand the problem and always click on "use
local entry".
Please have a look at the dialog and improve it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23506
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Event/Task conflict dialog is too difficult. (rt#6009)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4112>
______________________________________


From issues at kolab.org  Fri Feb 12 11:26:28 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 10:26:28 +0000
Subject: [Kolab-devel] [issue4113] Parallel events in the agenda view: last
	changed events	always on the right side (rt#6011)
In-Reply-To: <1265970388.9.0.0295221429808.issue4113@kolab.org>
Message-ID: <1265970388.9.0.0295221429808.issue4113@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Switch to the calendar
2. Create test event1 at 10:00-16:00 today. 
3. Create test event2 at 14:00-18:00 today.
=> Both test events are parallel and test event 2 is on the right side.
4. Resize test event1 to 10:00-15:45.
=> The test events switches, now test event 1 is on the right side.
This switching is the problem. The users want that the left to right order is
calculated on how early the event starts. (So event1 should be on the left side
and test event2 on the right side)

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23508
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Parallel events in the agenda view: last changed events always on the right side (rt#6011)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4113>
______________________________________


From issues at kolab.org  Fri Feb 12 11:43:14 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Fri, 12 Feb 2010 10:43:14 +0000
Subject: [Kolab-devel] [issue4114] Kleopatra: S/MIME encrypted pem file was
	detected as	attached signature file
In-Reply-To: <1265971394.68.0.272640392478.issue4114@kolab.org>
Message-ID: <1265971394.68.0.272640392478.issue4114@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleoptra Version 2.0.13-svn1084205 (Windows):
1. create text file
1. encrypt file with SMIME and option "ASCII armor"
-> pem file created, don't delete original text file (in the same directory)
2. try to decrypt pem file with Kleo
-> Kleo's auto detaction select the checkbox that the input file (=original text
file) is an attached signature file (wrong - option shouldn't activate for
decrypt only!)
3. Click on Decrypt/verify button
-> operation failed

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23509
nosy: emanuel, marc
priority: urgent
status: unread
title: Kleopatra: S/MIME encrypted pem file was detected as attached signature file

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4114>
______________________________________


From issues at kolab.org  Fri Feb 12 11:45:25 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 10:45:25 +0000
Subject: [Kolab-devel] [issue4115] Monthview: multi day events are displayed
	with leaps	(rt#6015)
In-Reply-To: <1265971525.53.0.204911728473.issue4115@kolab.org>
Message-ID: <1265971525.53.0.204911728473.issue4115@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

The user wants that multi day events are displayed as one line in the month
view. The event shouldn't have leaps. 

Test:
Req: No events are at the 2010-02-08 to 2010-02-10
0. Switch to the calendar and the month view.
1. Create whole day event (test1) at 2010-02-08
2. Create a multi day event (test2) at 2010-02-08 to 2010-02-10
=> test2 is displayed with a leap, because of test1.

Updating of an event changes this order. This also shouldn't happen.

If many different events are in the calendar, this could be difficult. (I think)
So please estimate and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23510
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Monthview: multi day events are displayed with leaps (rt#6015)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4115>
______________________________________


From issues at kolab.org  Fri Feb 12 11:56:16 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 10:56:16 +0000
Subject: [Kolab-devel] [issue4116] Wish: calendar selection with shift and
	mouse.(rt#6012)
In-Reply-To: <1265972176.56.0.750146286387.issue4116@kolab.org>
Message-ID: <1265972176.56.0.750146286387.issue4116@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The user wishes for this feature:
It should be possible to select a part of the calendar grid with:
1. Press Shift.
2. Click on a time (this should be the start date/time).
3. Click on another time (this should be the end date/time)

Now it should be possible to create an event with this selected times in the
usual ways. (RMB->Create new event, button, double click on the time, just
typing something)

Please estimate first and wait on an okay before continuing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23511
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: calendar selection with shift and mouse.(rt#6012)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4116>
______________________________________


From issues at kolab.org  Fri Feb 12 12:18:26 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 11:18:26 +0000
Subject: [Kolab-devel] [issue4117] Reminder: Preselected "remind me later"
	time should	always be 5 mins.(rt#6017)
In-Reply-To: <1265973506.15.0.629485064549.issue4117@kolab.org>
Message-ID: <1265973506.15.0.629485064549.issue4117@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The user wants the remind me later time always to be 5 mins.
Sometimes user just click on remind me later and didn't check the time before.

Test:
1. Switch to the calendar.
2. Create test event with reminder in a few minutes.
3. Create another test event with reminder in a few minutes.
4. Wait on the reminder of the first event.
=> Set reminder time to 1 d and click on remind me later.
5. Wait for the reminder of event 2.
=> The remind me later time should also be selected at 5 minutes.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23512
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Reminder: Preselected "remind me later" time should always be 5 mins.(rt#6017)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4117>
______________________________________


From issues at kolab.org  Fri Feb 12 13:32:59 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 12:32:59 +0000
Subject: [Kolab-devel] [issue4118] Wish: next/previous week buttons in the
	small month	pane(rt#6024)
In-Reply-To: <1265977979.32.0.117622740232.issue4118@kolab.org>
Message-ID: <1265977979.32.0.117622740232.issue4118@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The customers wish additionally to the next/previous year and month buttons a
pair of next/previous week buttons in the small month pane (upper left).

Background: A common use case is the switching between weeks.

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23515
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: next/previous week buttons in the small month pane(rt#6024)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4118>
______________________________________


From issues at kolab.org  Fri Feb 12 14:59:26 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 13:59:26 +0000
Subject: [Kolab-devel] [issue4119] Enter a distribution list as attendee
	into an event,
	should expand the members of the dist list into the attendee
	field	(rt#6027)
In-Reply-To: <1265983166.44.0.43093342885.issue4119@kolab.org>
Message-ID: <1265983166.44.0.43093342885.issue4119@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Create a dist list "testdist1" with some members.
2. Switch to the calendar.
3. Start to create a new event and switch to the attendee tab.
4. Click on the attendee field.
5. Enter testdist1 into the name-textfield.
=> It seems like the address testdist1 is added to the attendees. But: The
customer expects that the dist list is now expanded into its members.
So that the attendee field contains member_1,..., member_n of the distribution list.
(Click on "Select Adresses..." and select the distribution list, works in this way.)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23523
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Enter a distribution list as attendee into an event, should expand the members of the dist list into the attendee field (rt#6027)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4119>
______________________________________


From thomas at btspuhler.com  Fri Feb 12 15:09:03 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Fri, 12 Feb 2010 07:09:03 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002111923.08513.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002111923.08513.ml@radoeka.nl>
Message-ID: <201002120709.03524.thomas@btspuhler.com>

On Thursday 11 February 2010 11:23:08 am Richard Bos wrote:
> Op donderdag 11 februari 2010 05:24:05 schreef Thomas Spuhler:
> > I am packaging the kolab-2.2.3 on the Mandriva System.
> >
> > I upgraded the installed kolab 2.1.0 and now
> > I can add and delete users using the /usr/lib/kolab/adduser scripts.
> > I then can read e-mails after the upgrade I sent and received before the
> > upgrade.
> > I can send e-mails after the upgrade, but the don't go anywhere. the log
> >  shows  problems with  kolabmailboxfilter
> > This filter was in kolab2.1.0 provided by the resource-manager, but this
> >  isn't  used anymore. Where are these filters now?
>
>  kolab2:~ # rpm -qf /usr/bin/kolabfilter
> kolab-filter-0.1.7-2.1
>
> You can download it from:
> http://pear.horde.org/index.php?package=Kolab_Filter&release=0.1.8&download
>s
Thanks a lot. How are they provided in the Kolab package? The "kolab-filter" 
directory is empty.
-- 
Thomas


From issues at kolab.org  Fri Feb 12 15:12:57 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Feb 2010 14:12:57 +0000
Subject: [Kolab-devel] [issue4120] Wish: Sharing a calendar folder from the
	calendar	part(rt#6028)
In-Reply-To: <1265983977.59.0.6917829565.issue4120@kolab.org>
Message-ID: <1265983977.59.0.6917829565.issue4120@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

The user wishes:
RMB on a calendar subresource of a Kolab account should show the same dialog as
if he clicks with the RMB on the same folder in the Kmail part.

Especially he wants to share this folder with different user.

Test:
1. Switch to the calendar.
2. RMB on a calendar resource.
3. Choose Properties.
4. Click on the access tab.
5. Share the folder to a different account.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23525
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: Sharing a calendar folder from the calendar part(rt#6028)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4120>
______________________________________


From wrobel at pardus.de  Fri Feb 12 15:39:33 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 12 Feb 2010 15:39:33 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002120709.03524.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002111923.08513.ml@radoeka.nl>
	<201002120709.03524.thomas@btspuhler.com>
Message-ID: <20100212153933.12033g0ulystok00@webmail.pardus.de>

Quoting Thomas Spuhler <thomas at btspuhler.com>:

> On Thursday 11 February 2010 11:23:08 am Richard Bos wrote:
>> Op donderdag 11 februari 2010 05:24:05 schreef Thomas Spuhler:
>> > I am packaging the kolab-2.2.3 on the Mandriva System.
>> >
>> > I upgraded the installed kolab 2.1.0 and now
>> > I can add and delete users using the /usr/lib/kolab/adduser scripts.
>> > I then can read e-mails after the upgrade I sent and received before the
>> > upgrade.
>> > I can send e-mails after the upgrade, but the don't go anywhere. the log
>> >  shows  problems with  kolabmailboxfilter
>> > This filter was in kolab2.1.0 provided by the resource-manager, but this
>> >  isn't  used anymore. Where are these filters now?
>>
>>  kolab2:~ # rpm -qf /usr/bin/kolabfilter
>> kolab-filter-0.1.7-2.1
>>
>> You can download it from:
>> http://pear.horde.org/index.php?package=Kolab_Filter&release=0.1.8&download
>> s
> Thanks a lot. How are they provided in the Kolab package? The "kolab-filter"
> directory is empty.

Do you mean which files the package installs?

This is from a 2.2.3 machine:

/kolab/var/kolab/www  > /kolab/bin/openpkg rpm -q -l Kolab_Filter
/kolab/bin/kolabfilter
/kolab/bin/kolabmailboxfilter
/kolab/lib/php
/kolab/lib/php/.registry
/kolab/lib/php/.registry/.channel.__uri
/kolab/lib/php/.registry/.channel.pear.horde.org
/kolab/lib/php/.registry/.channel.pear.horde.org/kolab_filter.reg
/kolab/lib/php/.registry/.channel.pecl.php.net
/kolab/lib/php/Horde
/kolab/lib/php/Horde/Kolab
/kolab/lib/php/Horde/Kolab/Filter
/kolab/lib/php/Horde/Kolab/Filter/Base.php
/kolab/lib/php/Horde/Kolab/Filter/Content.php
/kolab/lib/php/Horde/Kolab/Filter/Incoming.php
/kolab/lib/php/Horde/Kolab/Filter/Outlook.php
/kolab/lib/php/Horde/Kolab/Filter/Response.php
/kolab/lib/php/Horde/Kolab/Filter/Transport
/kolab/lib/php/Horde/Kolab/Filter/Transport.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/DovecotLDA.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/LMTPTLS.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/drop.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/echo.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/lda.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/lmtp.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/smtp.php
/kolab/lib/php/Horde/Kolab/Filter/Transport/stdout.php
/kolab/lib/php/Horde/Kolab/Resource.php
/kolab/lib/php/Horde/Kolab/Test
/kolab/lib/php/Horde/Kolab/Test/Filter.php
/kolab/lib/php/data
/kolab/lib/php/data/Kolab_Filter
/kolab/lib/php/data/Kolab_Filter/locale
/kolab/lib/php/data/Kolab_Filter/locale/de_DE
/kolab/lib/php/data/Kolab_Filter/locale/de_DE/LC_MESSAGES
/kolab/lib/php/data/Kolab_Filter/locale/de_DE/LC_MESSAGES/Kolab_Filter.mo
/kolab/lib/php/doc
/kolab/lib/php/doc/Kolab_Filter
/kolab/lib/php/doc/Kolab_Filter/COPYING
/kolab/lib/php/doc/Kolab_Filter/man
/kolab/lib/php/doc/Kolab_Filter/man/man1
/kolab/lib/php/doc/Kolab_Filter/man/man1/kolabfilter.1
/kolab/lib/php/test
/kolab/lib/php/test/Kolab_Filter
/kolab/lib/php/test/Kolab_Filter/Horde
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/FilterTest.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/IncomingTest.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/LoadTest.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/empty.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/empty2.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged_trans.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/invitation_forward.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/longstring_invitation.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/null.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/privileged.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/recur_invitation.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple2.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple_out.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/test.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/tiny.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/tiny.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/vacation.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/vacation.ret
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/validation.eml
/kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/validation.ret
/kolab/man/man1/kolabfilter.1
/kolab/var/kolab-filter
/kolab/var/kolab-filter/log
/kolab/var/kolab-filter/tmp


Cheers,

Gunnar

> --
> Thomas
>
> _______________________________________________
> 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/20100212/f3224aea/attachment.bin

From wrobel at pardus.de  Fri Feb 12 16:39:19 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 12 Feb 2010 16:39:19 +0100
Subject: [Kolab-devel] Brain dump of the week: Horde roadmap
Message-ID: <20100212163919.180751tnfayy1zwg@webmail.pardus.de>

Hi!

A working Horde 3 installation for the Kolab Server appeared first in  
middle of 2008. At that time I said that I would support this  
installation for three years. After that we'd switch to Horde 4.

Now, after one and a half years it still looks like my estimate wasn't  
too far off. Horde 4 is of course still work in progress but the mail  
client is already in stabilization phase and the dynamic calender is  
progressing towards it. Of course there are also other things worth  
mentioning but I don't want to give a complete overview of the Horde 4  
changes here but rather stick to the time line I have in mind.

When I started working on the Horde/Kolab integration 4 years ago  
Horde 3 was already released. So I had to compromise on some issues  
for reasons of backward compatibility. In addition there was not much  
time for testing before the client went on the Kolab server.  
Consequently using the Kolab web client has not always be a pleasant  
experience for the users.

So for Horde 4 I wanted to ensure I'd be involved as early as possible  
in the development and I also wanted to release test packages for the  
Kolab server at an early time point.

As far as I can tell this worked out as planned. Of course I could  
have even had more time than I had for the development and there is  
still a lot to do for Horde 4. But taking into account that most of  
this is unpaid work I can say I'm still pretty happy with the progress.

The first set of Horde 4 test packages went into Kolab CVS last week.  
Nothing fancy yet: You only get the Horde base application at the  
moment. The mail  (Imp) and calendar (kronolith) applications are  
still missing. Should be added soon though.

So far, so good. I'll try to tell you more next week. Or the one after  
that :) We'll see.

Cheers,

Gunnar

-- 
______ 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/20100212/2f540a57/attachment-0001.bin

From wilde at intevation.de  Fri Feb 12 17:44:31 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 12 Feb 2010 17:44:31 +0100
Subject: [Kolab-devel] z-push: problematic license
Message-ID: <s7w3a16iets.fsf@intevation.de>

Hi Bernhard,
hi everyone in the Kolab community,

in the past few months and weeks z-push for Kolab[1] turned out to be an
interesting alternative to the currently immature sync-ml support of the
server.  Actually many of those who gave it a try seem quite excited
about it!  :)

That's why I just wanted to install a test setup of z-push support on
demo.kolab.org.  And even more: I was planing to evaluate z-push support
for integration in Kolab Server HEAD...

Being quite careful about license issues I first had a look at the
LICENSE file of the original z-push source and immediately stumbled
across the following introducing paragraph:

  NOTE: According to sec. 8 of the GNU General Public License (GPL), 
  Version 2, the distribution of the Program in or to the 
  United States of America is excluded from the scope of this license. 
  The Program is licensed under GPL Version 2 only.

While its true, that this limitation does perfectly coincide with
section eight, IMNSHO it would be a unbearable burden for Kolab Server.

This is not to say I'm all again using z-push with Kolab Server -- I'm
not, it is a possibly great extension for everybody outside the US.

BUT: 
- I'd suggest mentioning this limitation on the z-push wiki page.
- I advice against any incorporation in the official Kolab Server CVS or
  packaging as long as the current z-push license pertains.
- I would suggest to contact z-push upstream and ask about the reasons
  for this license limitation.[2]
- I'm totally unsure about the legal implications of adding this code to
  a world wide accessible service like demo.kolab.org.  My feeling says
  it would be ok, but INAL and so I will not do it for now.

Comments?

cheers
sascha

ps: fwiw: the license information in the kolab specific archive
    backend_0_2.zip is defective to: 
    - the source headers reference an non existing LICENSE file.
    - only one of the two source files contains copyright information
      other than the original copyright of Zarafa Deutschland GmbH.
    It would be good if this could be fixed for the next version.

[1]  http://wiki.kolab.org/index.php/Z_push
[2]  of cause the idea would be to evaluate if a removal of this
     limiting clause would be possible some way or the other
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100212/556faee6/attachment.bin

From bernhard at intevation.de  Fri Feb 12 18:10:09 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 12 Feb 2010 18:10:09 +0100
Subject: [Kolab-devel] z-push: problematic license
In-Reply-To: <s7w3a16iets.fsf@intevation.de>
References: <s7w3a16iets.fsf@intevation.de>
Message-ID: <201002121810.12669.bernhard@intevation.de>

Am Freitag, 12. Februar 2010 17:44:31 schrieb Sascha Wilde:
> - I would suggest to contact z-push upstream and ask about the reasons
> ? for this license limitation.[2]

Maybe the activesync "licensing" issues? (Just guessing.) 

> - I'm totally unsure about the legal implications of adding this code to
> ? a world wide accessible service like demo.kolab.org. ?My feeling says
> ? it would be ok, but INAL and so I will not do it for now.

Offering a service is not distributing a software that is quite clear.

-- 
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/20100212/2ff36667/attachment.bin

From thomas at btspuhler.com  Sat Feb 13 06:55:01 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Fri, 12 Feb 2010 22:55:01 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <20100212153933.12033g0ulystok00@webmail.pardus.de>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002120709.03524.thomas@btspuhler.com>
	<20100212153933.12033g0ulystok00@webmail.pardus.de>
Message-ID: <201002122255.01216.thomas@btspuhler.com>

On Friday 12 February 2010 07:39:33 am Gunnar Wrobel wrote:
> Quoting Thomas Spuhler <thomas at btspuhler.com>:
> > On Thursday 11 February 2010 11:23:08 am Richard Bos wrote:
> >> Op donderdag 11 februari 2010 05:24:05 schreef Thomas Spuhler:
> >> > I am packaging the kolab-2.2.3 on the Mandriva System.
> >> >
> >> > I upgraded the installed kolab 2.1.0 and now
> >> > I can add and delete users using the /usr/lib/kolab/adduser scripts.
> >> > I then can read e-mails after the upgrade I sent and received before
> >> > the upgrade.
> >> > I can send e-mails after the upgrade, but the don't go anywhere. the
> >> > log shows  problems with  kolabmailboxfilter
> >> > This filter was in kolab2.1.0 provided by the resource-manager, but
> >> > this isn't  used anymore. Where are these filters now?
> >>
> >>  kolab2:~ # rpm -qf /usr/bin/kolabfilter
> >> kolab-filter-0.1.7-2.1
> >>
> >> You can download it from:
> >> http://pear.horde.org/index.php?package=Kolab_Filter&release=0.1.8&downl
> >>oad s
> >
> > Thanks a lot. How are they provided in the Kolab package? The
> > "kolab-filter" directory is empty.
>
> Do you mean which files the package installs?
>
> This is from a 2.2.3 machine:
>
> /kolab/var/kolab/www  > /kolab/bin/openpkg rpm -q -l Kolab_Filter
> /kolab/bin/kolabfilter
> /kolab/bin/kolabmailboxfilter
> /kolab/lib/php
> /kolab/lib/php/.registry
> /kolab/lib/php/.registry/.channel.__uri
> /kolab/lib/php/.registry/.channel.pear.horde.org
> /kolab/lib/php/.registry/.channel.pear.horde.org/kolab_filter.reg
> /kolab/lib/php/.registry/.channel.pecl.php.net
> /kolab/lib/php/Horde
> /kolab/lib/php/Horde/Kolab
> /kolab/lib/php/Horde/Kolab/Filter
> /kolab/lib/php/Horde/Kolab/Filter/Base.php
> /kolab/lib/php/Horde/Kolab/Filter/Content.php
> /kolab/lib/php/Horde/Kolab/Filter/Incoming.php
> /kolab/lib/php/Horde/Kolab/Filter/Outlook.php
> /kolab/lib/php/Horde/Kolab/Filter/Response.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport
> /kolab/lib/php/Horde/Kolab/Filter/Transport.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/DovecotLDA.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/LMTPTLS.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/drop.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/echo.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/lda.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/lmtp.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/smtp.php
> /kolab/lib/php/Horde/Kolab/Filter/Transport/stdout.php
> /kolab/lib/php/Horde/Kolab/Resource.php
> /kolab/lib/php/Horde/Kolab/Test
> /kolab/lib/php/Horde/Kolab/Test/Filter.php
> /kolab/lib/php/data
> /kolab/lib/php/data/Kolab_Filter
> /kolab/lib/php/data/Kolab_Filter/locale
> /kolab/lib/php/data/Kolab_Filter/locale/de_DE
> /kolab/lib/php/data/Kolab_Filter/locale/de_DE/LC_MESSAGES
> /kolab/lib/php/data/Kolab_Filter/locale/de_DE/LC_MESSAGES/Kolab_Filter.mo
> /kolab/lib/php/doc
> /kolab/lib/php/doc/Kolab_Filter
> /kolab/lib/php/doc/Kolab_Filter/COPYING
> /kolab/lib/php/doc/Kolab_Filter/man
> /kolab/lib/php/doc/Kolab_Filter/man/man1
> /kolab/lib/php/doc/Kolab_Filter/man/man1/kolabfilter.1
> /kolab/lib/php/test
> /kolab/lib/php/test/Kolab_Filter
> /kolab/lib/php/test/Kolab_Filter/Horde
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/AllTests.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/FilterTest.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/IncomingTest.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/LoadTest.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/ResourceTest.php
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/empty.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/empty2.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged_trans.r
>et
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/invitation_for
>ward.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/longstring_inv
>itation.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/null.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/privileged.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/recur_invitati
>on.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple2.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/simple_out.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/test.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/tiny.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/tiny.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/vacation.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/vacation.ret
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/validation.eml
> /kolab/lib/php/test/Kolab_Filter/Horde/Kolab/Filter/fixtures/validation.ret
> /kolab/man/man1/kolabfilter.1
> /kolab/var/kolab-filter
> /kolab/var/kolab-filter/log
> /kolab/var/kolab-filter/tmp
>
>
> Cheers,
>
> Gunnar
>
> > --
> > Thomas
> >
> > _______________________________________________
> > Kolab-devel mailing list
> > Kolab-devel at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-devel
Thanks. 
To build this package php-pear-channel-horde-1.0
is required. 
OR
***************
Installing packages from pear.horde.org is easy. Just follow the simple steps 
below.

Note: You need a working PEAR 1.4 environment. For more information on PEAR 
and how to install PEAR, see our FAQ

   1. First, add the channel server using:
      pear channel-discover pear.horde.org
   2. Once this is complete, you can install any of our packages using:
      pear install horde/some_package_name
**************
I am afraid, this is not going to work on a native installation such as 
Mandriva. I can build it on my own box but not on the Mandriva build cluster.

Is there a workaround for this?

-- 
Thomas


From ml at radoeka.nl  Sat Feb 13 14:04:28 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 13 Feb 2010 14:04:28 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002122255.01216.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<20100212153933.12033g0ulystok00@webmail.pardus.de>
	<201002122255.01216.thomas@btspuhler.com>
Message-ID: <201002131404.28885.ml@radoeka.nl>

Op zaterdag 13 februari 2010 06:55:01 schreef Thomas Spuhler:
> To build this package php-pear-channel-horde-1.0
> is required. 
> OR
> ***************
> Installing packages from pear.horde.org is easy. Just follow the simple
>  steps  below.
> 
> Note: You need a working PEAR 1.4 environment. For more information on
>  PEAR  and how to install PEAR, see our FAQ
> 
>    1. First, add the channel server using:
>       pear channel-discover pear.horde.org
>    2. Once this is complete, you can install any of our packages using:
>       pear install horde/some_package_name
> **************
> I am afraid, this is not going to work on a native installation such as 
> Mandriva. I can build it on my own box but not on the Mandriva build
>  cluster.
> 
> Is there a workaround for this?

Of course.  Just add the channel with an rpm
See 
http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.2/src/php5-
pear-channel-horde-1.0-1.1.src.rpm
or
http://download.opensuse.org/repositories/server:/php:/applications/openSUSE_11.2/src/ 
(look for rpms with channel in their name) and the rest of the internet for 
other examples.

-- 
Richard


From thomas at btspuhler.com  Sat Feb 13 16:15:01 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 13 Feb 2010 08:15:01 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002131404.28885.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002122255.01216.thomas@btspuhler.com>
	<201002131404.28885.ml@radoeka.nl>
Message-ID: <201002130815.02022.thomas@btspuhler.com>

On Saturday 13 February 2010 06:04:28 am Richard Bos wrote:
> Op zaterdag 13 februari 2010 06:55:01 schreef Thomas Spuhler:
> > To build this package php-pear-channel-horde-1.0
> > is required.
> > OR
> > ***************
> > Installing packages from pear.horde.org is easy. Just follow the simple
> >  steps  below.
> >
> > Note: You need a working PEAR 1.4 environment. For more information on
> >  PEAR  and how to install PEAR, see our FAQ
> >
> >    1. First, add the channel server using:
> >       pear channel-discover pear.horde.org
> >    2. Once this is complete, you can install any of our packages using:
> >       pear install horde/some_package_name
> > **************
> > I am afraid, this is not going to work on a native installation such as
> > Mandriva. I can build it on my own box but not on the Mandriva build
> >  cluster.
> >
> > Is there a workaround for this?
>
> Of course.  Just add the channel with an rpm
> See
> http://download.opensuse.org/repositories/server:/php:/applications/openSUS
>E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> or
> http://download.opensuse.org/repositories/server:/php:/applications/openSUS
>E_11.2/src/ (look for rpms with channel in their name) and the rest of the
> internet for other examples.
I may didn't express myself correctly. the php-pear-channel-horde needs to be 
installed on the build system? for getting the kolab-filter rpm to build on the 
build server. Mandriva will not install the rpm on their build server.

(yes, kolab-filter built nicely on my box,and forgive me, I used Richard's spec 
file with minor changes)

-- 
Thomas


From ml at radoeka.nl  Sat Feb 13 17:16:25 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 13 Feb 2010 17:16:25 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002130815.02022.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002131404.28885.ml@radoeka.nl>
	<201002130815.02022.thomas@btspuhler.com>
Message-ID: <201002131716.25289.ml@radoeka.nl>

Op zaterdag 13 februari 2010 16:15:01 schreef Thomas Spuhler:
> > > Is there a workaround for this?
> >
> > Of course.  Just add the channel with an rpm
> > See
> > http://download.opensuse.org/repositories/server:/php:/applications/openS
> >US E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> > or
> > http://download.opensuse.org/repositories/server:/php:/applications/openS
> >US E_11.2/src/ (look for rpms with channel in their name) and the rest of
> > the internet for other examples.
> 
> I may didn't express myself correctly. the php-pear-channel-horde needs to
>  be  installed on the build system? for getting the kolab-filter rpm to
>  build on the build server. Mandriva will not install the rpm on their
>  build server.

Same with openSUSE's build server.  Hence you add the channel (which is 
basically an xml formatted file, with some info) with an rpm.  

> (yes, kolab-filter built nicely on my box,and forgive me, I used Richard's
>  spec  file with minor changes)

Just use / build the src.rpm providing the channel and use it on Mandriva's 
build server, you'll that it gets on installed there.

-- 
Richard


From ml at radoeka.nl  Sat Feb 13 21:15:46 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 13 Feb 2010 21:15:46 +0100
Subject: [Kolab-devel] wilde: server/imapd/patches/cyrus-imapd-2.3.16
	cyrus-imapd-cross-domain-acls.patch, NONE, 1.1
In-Reply-To: <20100208171942.E2253600574@lists.intevation.de>
References: <20100208171942.E2253600574@lists.intevation.de>
Message-ID: <201002132115.46733.ml@radoeka.nl>

Op maandag 08 februari 2010 18:19:42 schreef cvs at kolab.org:
> Update of /kolabrepository/server/imapd/patches/cyrus-imapd-2.3.16
> In directory doto:/tmp/cvs-serv24076/imapd/patches/cyrus-imapd-2.3.16
> 
> Added Files:
>         cyrus-imapd-cross-domain-acls.patch 
> Log Message:
> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).

Is it possible to rename this patch (cyrus-imapd-cross-domain-acls.patch) to:
KOLAB_cyrus-imapd-cross-domain-acls.patch

Similar to the other patches in:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/cyrus-
imapd-2.3.16/
It's very handy to be able to determine kolab patches by their name, 
especially when there are much more patches (in case of openSUSE) involved:
Patch1:         cyrus-imapd-2.3.16-autocreate-0.10-0.drac.diff
Patch2:         authid_normalize.patch
Patch3:         auth_krb5-sentinel.patch
Patch4:         luser_relay.patch
Patch5:         cyrus-imapd-perl.patch
Patch8:         tail-1-fix.patch
Patch10:        cyrus-imapd-openslp.patch
Patch12:        pie.patch
Patch18:        cyrus-imapd-perl-path.patch
Patch100:        KOLAB_cyrus-imapd-%{version}_Cyradm_Annotations.patch
Patch102:        KOLAB_cyrus-imapd-%{version}_Folder-names.patch
Patch103:        KOLAB_cyrus-imapd-%{version}_Groups2.patch
Patch104:        KOLAB_cyrus-imapd-%{version}_Logging.patch
Patch105:        KOLAB_cyrus-imapd-%{version}_timsieved_starttls-
sendcaps.patch
Patch106:        KOLAB_cyrus-imapd-%{version}_UID.patch
Patch107:        cyrus-imapd-cross-domain-acls.patch

The patch with number 107, is a kolab patch, but it is unfortenately not 
recognizable as such.

-- 
Richard


From alain.abbas at libertech.fr  Sun Feb 14 01:39:05 2010
From: alain.abbas at libertech.fr (Alain abbas)
Date: Sun, 14 Feb 2010 01:39:05 +0100
Subject: [Kolab-devel] z-push: problematic license
In-Reply-To: <s7w3a16iets.fsf@intevation.de>
References: <s7w3a16iets.fsf@intevation.de>
Message-ID: <4B774629.4020605@libertech.fr>

hi
type Activesync patent in google you will see .
Active sync is patented it think is why that US are exclued to the GPL 
license.

Note : i m not jurist :-)

Regards

Sascha Wilde a ?crit :
> Hi Bernhard,
> hi everyone in the Kolab community,
>
> in the past few months and weeks z-push for Kolab[1] turned out to be an
> interesting alternative to the currently immature sync-ml support of the
> server.  Actually many of those who gave it a try seem quite excited
> about it!  :)
>
> That's why I just wanted to install a test setup of z-push support on
> demo.kolab.org.  And even more: I was planing to evaluate z-push support
> for integration in Kolab Server HEAD...
>
> Being quite careful about license issues I first had a look at the
> LICENSE file of the original z-push source and immediately stumbled
> across the following introducing paragraph:
>
>   NOTE: According to sec. 8 of the GNU General Public License (GPL), 
>   Version 2, the distribution of the Program in or to the 
>   United States of America is excluded from the scope of this license. 
>   The Program is licensed under GPL Version 2 only.
>
> While its true, that this limitation does perfectly coincide with
> section eight, IMNSHO it would be a unbearable burden for Kolab Server.
>
> This is not to say I'm all again using z-push with Kolab Server -- I'm
> not, it is a possibly great extension for everybody outside the US.
>
> BUT: 
> - I'd suggest mentioning this limitation on the z-push wiki page.
> - I advice against any incorporation in the official Kolab Server CVS or
>   packaging as long as the current z-push license pertains.
> - I would suggest to contact z-push upstream and ask about the reasons
>   for this license limitation.[2]
> - I'm totally unsure about the legal implications of adding this code to
>   a world wide accessible service like demo.kolab.org.  My feeling says
>   it would be ok, but INAL and so I will not do it for now.
>
> Comments?
>
> cheers
> sascha
>
> ps: fwiw: the license information in the kolab specific archive
>     backend_0_2.zip is defective to: 
>     - the source headers reference an non existing LICENSE file.
>     - only one of the two source files contains copyright information
>       other than the original copyright of Zarafa Deutschland GmbH.
>     It would be good if this could be fixed for the next version.
>
> [1]  http://wiki.kolab.org/index.php/Z_push
> [2]  of cause the idea would be to evaluate if a removal of this
>      limiting clause would be possible some way or the other
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alain.abbas at libertech.fr  Sun Feb 14 01:47:39 2010
From: alain.abbas at libertech.fr (Alain abbas)
Date: Sun, 14 Feb 2010 01:47:39 +0100
Subject: [Kolab-devel] z-push: problematic license
In-Reply-To: <s7w3a16iets.fsf@intevation.de>
References: <s7w3a16iets.fsf@intevation.de>
Message-ID: <4B77482B.9030201@libertech.fr>

hi
ths link is interesting about Activesync Patent
http://boycottnovell.com/2009/11/02/activesync-patent-trap-bilski/

Sascha Wilde a ?crit :
> Hi Bernhard,
> hi everyone in the Kolab community,
>
> in the past few months and weeks z-push for Kolab[1] turned out to be an
> interesting alternative to the currently immature sync-ml support of the
> server.  Actually many of those who gave it a try seem quite excited
> about it!  :)
>
> That's why I just wanted to install a test setup of z-push support on
> demo.kolab.org.  And even more: I was planing to evaluate z-push support
> for integration in Kolab Server HEAD...
>
> Being quite careful about license issues I first had a look at the
> LICENSE file of the original z-push source and immediately stumbled
> across the following introducing paragraph:
>
>   NOTE: According to sec. 8 of the GNU General Public License (GPL), 
>   Version 2, the distribution of the Program in or to the 
>   United States of America is excluded from the scope of this license. 
>   The Program is licensed under GPL Version 2 only.
>
> While its true, that this limitation does perfectly coincide with
> section eight, IMNSHO it would be a unbearable burden for Kolab Server.
>
> This is not to say I'm all again using z-push with Kolab Server -- I'm
> not, it is a possibly great extension for everybody outside the US.
>
> BUT: 
> - I'd suggest mentioning this limitation on the z-push wiki page.
> - I advice against any incorporation in the official Kolab Server CVS or
>   packaging as long as the current z-push license pertains.
> - I would suggest to contact z-push upstream and ask about the reasons
>   for this license limitation.[2]
> - I'm totally unsure about the legal implications of adding this code to
>   a world wide accessible service like demo.kolab.org.  My feeling says
>   it would be ok, but INAL and so I will not do it for now.
>
> Comments?
>
> cheers
> sascha
>
> ps: fwiw: the license information in the kolab specific archive
>     backend_0_2.zip is defective to: 
>     - the source headers reference an non existing LICENSE file.
>     - only one of the two source files contains copyright information
>       other than the original copyright of Zarafa Deutschland GmbH.
>     It would be good if this could be fixed for the next version.
>
> [1]  http://wiki.kolab.org/index.php/Z_push
> [2]  of cause the idea would be to evaluate if a removal of this
>      limiting clause would be possible some way or the other
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From soliva at comcept.ch  Sun Feb 14 11:49:39 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Sun, 14 Feb 2010 11:49:39 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <20100211221010.29291rrgipu49fe8@webmail.pardus.de>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch>
	<20100211221010.29291rrgipu49fe8@webmail.pardus.de>
Message-ID: <001101caad63$684e4d10$38eae730$@ch>

Hi Gunnar

Sorry was in holidays for a fiew days :-)

I tried to include your suggested stuff "var_dump($base);" in the Code of:

/opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204

But as a pity without success....I'm not so familar with php :-( can you
please advice how you would include it.

Regarding your suggstion what the symptomes are if this error occurs
following:

The error occures "ONLY" if a user is added or modified within the manager
interface. It happens also if a Distribution List ist added or modified. For
the manager itself which add's or modifies the users or distribution list on
the manager interface nothing occured meanining I added over 20 domains with
50 email address's and aliases but I never was kicked out or saw a blank
white page or a error from php or whatever. I'm using kolab since years and
this never occoured but I have to say what I did this time was to add a
Domain Maintainer which I never used before...could this be the reason? If I
looked in as the Domain Maintainer and added a user I had some kick outs and
blank white pages? I have a strange feeling about this function but that we
have no misunderstandig at all as Kolab Manager I had never blank pages or
uncontrolled kicke outs.

If you could advice where to add the code etc. I can follow up on this....

PS: One more thing which you are probably interessted....I did in rc.conf
template a modification....this means in the past for config the entry in
this file was:

openldap_url="ldap:// ldaps://"

This was working fine without any problems...in the newewst version the
entry is:

openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"

This was given errors and a lot of problems because the real entry in the
/kolab/etc/rc.conf was looking:

openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"

This does not work and I changed to 127.0.0.1 or back to the old style. Both
is working fine:

openldap_url="ldap:// ldaps://"

I do not think so that this has something to do with the issue which we are
discussion here even I do not understand the "openldap_url="ldap://0.0.0.0/
ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that the
bind_addr did not work as expected because I'm using Kolab in a Solaris Zone
and the localhost as the 127.0.0.1 is handled in some circumstances in
another way.....this only for your information. I documented the overall
stuff on the Wiki:

https://wiki.kolab.org/index.php/Solaris


Kind regards

Andrea

Mail: soliva at comcept.ch 

-----Urspr?ngliche Nachricht-----
Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Donnerstag, 11. Februar 2010 22:10
An: kolab-devel at kolab.org
Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi
>
> It is from my point of view clear the search function but even I see the
> lines I can not identify what is false and why?:
>
> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
204
>
>
> 201    function search( $base, $filter, $attrs = false ) {
>    202      $this->freeSearchResult();
>    203      if( $attrs ) {
>    204            $this->search_result = ldap_search( $this->connection,
> $base, $filter, $attrs );
>    205          } else {
>    206            $this->search_result = ldap_search( $this->connection,
> $base, $filter );
>    207          }
>    208      return $this->search_result;
>    209    }

The error sounds as if $base contains an invalid value. You could add  
a "var_dump($base);" in the code to display the value.

Both log entries you mentioned are just warnings though. The code  
won't stop on a warning. And the code of the web admin is not exactly  
clean when it comes to notices and warnings. Quite the contrary. So  
what you see might not be a real problem.

But I did not quite understand what kind of problems you saw in the  
actual frontend. Did you see any specific errors that were displayed?  
Or did the web admin just show you a blank page (the PHP white screen  
of death)?

Cheers,

Gunnar

>
>
> is not a valid ldap result resource in
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>
>    411    // Count the number of occurences of an email address
>    412    // in users' mail and alias attributes and in dist. lists.
>    413    // This can be used to check for uniqueness etc.
>    414    function countMail( $base, $mail , $excludedn=false ) {
>    415          // First count users
>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>    417                         (alias='.$this->escape($mail).')
>    418                       )
>    419                       (uid='.$this->escape($mail).')
>    420                     )';
>    421          $res = $this->search( $this->dn_escape($base), $filter,
> array( 'dn' ) );
>    422          $count = 0;
>    423
>    424          $entries = ldap_get_entries( $this->connection, $res );
>    425          if( $excludedn ) {
>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>    427                  if( is_null( $entries[$i] ) ) continue;
>    428                  if(
KolabLDAP::unescape_dn_value($entries[$i]['dn'])
> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>    429                  debug("found ".$entries[$i]['dn'] );
>    430                  $count++;
>    431            }
>    432          } else $count += $entries['count'];
>
>
> Kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
> -----Urspr?ngliche Nachricht-----
> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Montag, 25. Januar 2010 14:37
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
> 204
>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
argument
>> is not a valid ldap result resource in
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>
>> Is this already recognized? Is it not known....I tried to figure out what
>> is wrong but actually I could not?!
>>
>> Any suggestion?
>
> My suggestion is to check the given line 204 and see which argument
> is used there (maybe add a statement to print it out).
>
>> By the way is there a documentation about Master/Slave configuration
>> meaning how this works etc. I could not find anything. Any hints would be
>> appriciated.
>
> I think the documentation is in the architecture documents.
> The idea is pretty simple: Replicate the directory server on the slave
> (for which there is a bootstrap) have all read access on the slave
accounts
> go
> to the slave LDAP server and all write access (only by webadmin) to the
> master.
>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From thomas at btspuhler.com  Sun Feb 14 20:08:11 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 14 Feb 2010 12:08:11 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002131716.25289.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002130815.02022.thomas@btspuhler.com>
	<201002131716.25289.ml@radoeka.nl>
Message-ID: <201002141208.12294.thomas@btspuhler.com>

On Saturday 13 February 2010 09:16:25 am Richard Bos wrote:
> Op zaterdag 13 februari 2010 16:15:01 schreef Thomas Spuhler:
> > > > Is there a workaround for this?
> > >
> > > Of course.  Just add the channel with an rpm
> > > See
> > > http://download.opensuse.org/repositories/server:/php:/applications/ope
> > >nS US E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> > > or
> > > http://download.opensuse.org/repositories/server:/php:/applications/ope
> > >nS US E_11.2/src/ (look for rpms with channel in their name) and the
> > > rest of the internet for other examples.
> >
> > I may didn't express myself correctly. the php-pear-channel-horde needs
> > to be  installed on the build system? for getting the kolab-filter rpm to
> > build on the build server. Mandriva will not install the rpm on their
> > build server.
>
> Same with openSUSE's build server.  Hence you add the channel (which is
> basically an xml formatted file, with some info) with an rpm.
>
> > (yes, kolab-filter built nicely on my box,and forgive me, I used
> > Richard's spec  file with minor changes)
>
> Just use / build the src.rpm providing the channel and use it on Mandriva's
> build server, you'll that it gets on installed there.
 I am making progress. all the 25 horde-xx packages built and installed.
But I still have dependancy problems with kolab-filter packagage. It builds fine 
but then when trying to install, I get a lot of dependencies missing.
http://mandriva.pastebin.fr/6825
I have all the spec required packages installed

-- 
Thomas


From ml at radoeka.nl  Sun Feb 14 20:59:14 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 14 Feb 2010 20:59:14 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002141208.12294.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002131716.25289.ml@radoeka.nl>
	<201002141208.12294.thomas@btspuhler.com>
Message-ID: <201002142059.14948.ml@radoeka.nl>

Op zondag 14 februari 2010 20:08:11 schreef Thomas Spuhler:
> > Just use / build the src.rpm providing the channel and use it on
> > Mandriva's build server, you'll that it gets on installed there.
> 
>  I am making progress. all the 25 horde-xx packages built and installed.
> But I still have dependancy problems with kolab-filter packagage. It builds
>  fine  but then when trying to install, I get a lot of dependencies
>  missing. http://mandriva.pastebin.fr/6825
> I have all the spec required packages installed

Perhaps this helps:
=== Horde/Date/Recurrence.php ===                                                                                
kolab-webclient-1.2-3.1
horde-date-0.1.0-3.13

=== Horde/Kolab/Server.php ===
kolab-webclient-1.2-3.1
kolab-server-0.5.0-4.6

=== Horde/Kolab/Storage/List.php ===
kolab-webclient-1.2-3.1
kolab-storage-0.4.0-3.12

=== Horde/Kolab/Test/Storage.php ===
kolab-storage-0.4.0-3.12

=== Horde/NLS.php ===
kolab-webclient-1.2-3.1
horde-nls-0.0.2-3.11

=== PHPUnit/Extensions/OutputTestCase.php ===
=== PHPUnit/Extensions/PerformanceTestCase.php ===
=== PHPUnit/Framework.php ===
=== PHPUnit/Framework/TestSuite.php ===
=== PHPUnit/TextUI/TestRunner.php ===
php5-pear-phpunit-3.3.15-1.5


-- 
Richard


From thomas at btspuhler.com  Sun Feb 14 21:13:15 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 14 Feb 2010 13:13:15 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002142059.14948.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002141208.12294.thomas@btspuhler.com>
	<201002142059.14948.ml@radoeka.nl>
Message-ID: <201002141313.15362.thomas@btspuhler.com>

On Sunday 14 February 2010 12:59:14 pm Richard Bos wrote:
> Op zondag 14 februari 2010 20:08:11 schreef Thomas Spuhler:
> > > Just use / build the src.rpm providing the channel and use it on
> > > Mandriva's build server, you'll that it gets on installed there.
> >
> >  I am making progress. all the 25 horde-xx packages built and installed.
> > But I still have dependancy problems with kolab-filter packagage. It
> > builds fine  but then when trying to install, I get a lot of dependencies
> > missing. http://mandriva.pastebin.fr/6825
> > I have all the spec required packages installed
>
> Perhaps this helps:
> === Horde/Date/Recurrence.php ===
> kolab-webclient-1.2-3.1
> horde-date-0.1.0-3.13
>
> === Horde/Kolab/Server.php ===
> kolab-webclient-1.2-3.1
> kolab-server-0.5.0-4.6
>
> === Horde/Kolab/Storage/List.php ===
> kolab-webclient-1.2-3.1
> kolab-storage-0.4.0-3.12
>
> === Horde/Kolab/Test/Storage.php ===
> kolab-storage-0.4.0-3.12
>
> === Horde/NLS.php ===
> kolab-webclient-1.2-3.1
> horde-nls-0.0.2-3.11
>
> === PHPUnit/Extensions/OutputTestCase.php ===
> === PHPUnit/Extensions/PerformanceTestCase.php ===
> === PHPUnit/Framework.php ===
> === PHPUnit/Framework/TestSuite.php ===
> === PHPUnit/TextUI/TestRunner.php ===
> php5-pear-phpunit-3.3.15-1.5
Yep, php-pear-PHPUNit helped. I will add that to the requirement. All that is 
left now is http://mandriva.pastebin.fr/6826
-- 
Thomas


From thomas at btspuhler.com  Mon Feb 15 00:15:54 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 14 Feb 2010 16:15:54 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002142059.14948.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002141208.12294.thomas@btspuhler.com>
	<201002142059.14948.ml@radoeka.nl>
Message-ID: <201002141615.54667.thomas@btspuhler.com>

On Sunday 14 February 2010 12:59:14 pm Richard Bos wrote:
> Op zondag 14 februari 2010 20:08:11 schreef Thomas Spuhler:
> > > Just use / build the src.rpm providing the channel and use it on
> > > Mandriva's build server, you'll that it gets on installed there.
> >
> >  I am making progress. all the 25 horde-xx packages built and installed.
> > But I still have dependancy problems with kolab-filter packagage. It
> > builds fine  but then when trying to install, I get a lot of dependencies
> > missing. http://mandriva.pastebin.fr/6825
> > I have all the spec required packages installed
>
> Perhaps this helps:
> === Horde/Date/Recurrence.php ===
> kolab-webclient-1.2-3.1
> horde-date-0.1.0-3.13
>
> === Horde/Kolab/Server.php ===
> kolab-webclient-1.2-3.1
> kolab-server-0.5.0-4.6
>
> === Horde/Kolab/Storage/List.php ===
> kolab-webclient-1.2-3.1
> kolab-storage-0.4.0-3.12
>
> === Horde/Kolab/Test/Storage.php ===
> kolab-storage-0.4.0-3.12
>
> === Horde/NLS.php ===
> kolab-webclient-1.2-3.1
> horde-nls-0.0.2-3.11
>
> === PHPUnit/Extensions/OutputTestCase.php ===
> === PHPUnit/Extensions/PerformanceTestCase.php ===
> === PHPUnit/Framework.php ===
> === PHPUnit/Framework/TestSuite.php ===
> === PHPUnit/TextUI/TestRunner.php ===
> php5-pear-phpunit-3.3.15-1.5

I think I miss one package (can't see the forest because of all the trees)

# rpm -ivh  kolab-storage-0.4.0-1mdv2010.0.noarch.rpm
error: Failed dependencies:
        pear(Horde/Share.php) is needed by kolab-
storage-0.4.0-1mdv2010.0.noarch
I cannot find this horde/Share.php

-- 
Thomas


From thomas at btspuhler.com  Mon Feb 15 04:13:37 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 14 Feb 2010 20:13:37 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002142059.14948.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002141208.12294.thomas@btspuhler.com>
	<201002142059.14948.ml@radoeka.nl>
Message-ID: <201002142013.37626.thomas@btspuhler.com>

On Sunday 14 February 2010 12:59:14 pm Richard Bos wrote:
> Op zondag 14 februari 2010 20:08:11 schreef Thomas Spuhler:
> > > Just use / build the src.rpm providing the channel and use it on
> > > Mandriva's build server, you'll that it gets on installed there.
> >
> >  I am making progress. all the 25 horde-xx packages built and installed.
> > But I still have dependancy problems with kolab-filter packagage. It
> > builds fine  but then when trying to install, I get a lot of dependencies
> > missing. http://mandriva.pastebin.fr/6825
> > I have all the spec required packages installed
>
> Perhaps this helps:
> === Horde/Date/Recurrence.php ===
> kolab-webclient-1.2-3.1
> horde-date-0.1.0-3.13
>
> === Horde/Kolab/Server.php ===
> kolab-webclient-1.2-3.1
> kolab-server-0.5.0-4.6
>
> === Horde/Kolab/Storage/List.php ===
> kolab-webclient-1.2-3.1
> kolab-storage-0.4.0-3.12
>
> === Horde/Kolab/Test/Storage.php ===
> kolab-storage-0.4.0-3.12
>
> === Horde/NLS.php ===
> kolab-webclient-1.2-3.1
> horde-nls-0.0.2-3.11
>
> === PHPUnit/Extensions/OutputTestCase.php ===
> === PHPUnit/Extensions/PerformanceTestCase.php ===
> === PHPUnit/Framework.php ===
> === PHPUnit/Framework/TestSuite.php ===
> === PHPUnit/TextUI/TestRunner.php ===
> php5-pear-phpunit-3.3.15-1.5

Another quirk: What is PreReq in the spec file standing for? Mandriva doesn't 
permit it in the spec file.
-- 
Thomas


From wrobel at pardus.de  Mon Feb 15 10:00:00 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 15 Feb 2010 10:00:00 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <001101caad63$684e4d10$38eae730$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch>
	<20100211221010.29291rrgipu49fe8@webmail.pardus.de>
	<001101caad63$684e4d10$38eae730$@ch>
Message-ID: <20100215100000.59382tahnkzoqk9c@webmail.pardus.de>

Hi Andrea,

actually the error you see is probably a side effect of the bug I  
introduced with the fix for https://issues.kolab.org/issue3499. I'll  
try to provide a patch for that today. Please add yourself in nosy  
there. Would be great if you could provide feedback if that works.

Cheers,

Gunnar

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> Sorry was in holidays for a fiew days :-)
>
> I tried to include your suggested stuff "var_dump($base);" in the Code of:
>
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>
> But as a pity without success....I'm not so familar with php :-( can you
> please advice how you would include it.
>
> Regarding your suggstion what the symptomes are if this error occurs
> following:
>
> The error occures "ONLY" if a user is added or modified within the manager
> interface. It happens also if a Distribution List ist added or modified. For
> the manager itself which add's or modifies the users or distribution list on
> the manager interface nothing occured meanining I added over 20 domains with
> 50 email address's and aliases but I never was kicked out or saw a blank
> white page or a error from php or whatever. I'm using kolab since years and
> this never occoured but I have to say what I did this time was to add a
> Domain Maintainer which I never used before...could this be the reason? If I
> looked in as the Domain Maintainer and added a user I had some kick outs and
> blank white pages? I have a strange feeling about this function but that we
> have no misunderstandig at all as Kolab Manager I had never blank pages or
> uncontrolled kicke outs.
>
> If you could advice where to add the code etc. I can follow up on this....
>
> PS: One more thing which you are probably interessted....I did in rc.conf
> template a modification....this means in the past for config the entry in
> this file was:
>
> openldap_url="ldap:// ldaps://"
>
> This was working fine without any problems...in the newewst version the
> entry is:
>
> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>
> This was given errors and a lot of problems because the real entry in the
> /kolab/etc/rc.conf was looking:
>
> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>
> This does not work and I changed to 127.0.0.1 or back to the old style. Both
> is working fine:
>
> openldap_url="ldap:// ldaps://"
>
> I do not think so that this has something to do with the issue which we are
> discussion here even I do not understand the "openldap_url="ldap://0.0.0.0/
> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that the
> bind_addr did not work as expected because I'm using Kolab in a Solaris Zone
> and the localhost as the 127.0.0.1 is handled in some circumstances in
> another way.....this only for your information. I documented the overall
> stuff on the Wiki:
>
> https://wiki.kolab.org/index.php/Solaris
>
>
> Kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Donnerstag, 11. Februar 2010 22:10
> An: kolab-devel at kolab.org
> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Hi Andrea,
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi
>>
>> It is from my point of view clear the search function but even I see the
>> lines I can not identify what is false and why?:
>>
>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
> 204
>>
>>
>> 201    function search( $base, $filter, $attrs = false ) {
>>    202      $this->freeSearchResult();
>>    203      if( $attrs ) {
>>    204            $this->search_result = ldap_search( $this->connection,
>> $base, $filter, $attrs );
>>    205          } else {
>>    206            $this->search_result = ldap_search( $this->connection,
>> $base, $filter );
>>    207          }
>>    208      return $this->search_result;
>>    209    }
>
> The error sounds as if $base contains an invalid value. You could add
> a "var_dump($base);" in the code to display the value.
>
> Both log entries you mentioned are just warnings though. The code
> won't stop on a warning. And the code of the web admin is not exactly
> clean when it comes to notices and warnings. Quite the contrary. So
> what you see might not be a real problem.
>
> But I did not quite understand what kind of problems you saw in the
> actual frontend. Did you see any specific errors that were displayed?
> Or did the web admin just show you a blank page (the PHP white screen
> of death)?
>
> Cheers,
>
> Gunnar
>
>>
>>
>> is not a valid ldap result resource in
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>
>>    411    // Count the number of occurences of an email address
>>    412    // in users' mail and alias attributes and in dist. lists.
>>    413    // This can be used to check for uniqueness etc.
>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>    415          // First count users
>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>    417                         (alias='.$this->escape($mail).')
>>    418                       )
>>    419                       (uid='.$this->escape($mail).')
>>    420                     )';
>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>> array( 'dn' ) );
>>    422          $count = 0;
>>    423
>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>    425          if( $excludedn ) {
>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>    427                  if( is_null( $entries[$i] ) ) continue;
>>    428                  if(
> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>    429                  debug("found ".$entries[$i]['dn'] );
>>    430                  $count++;
>>    431            }
>>    432          } else $count += $entries['count'];
>>
>>
>> Kind regards
>>
>> Andrea Soliva
>>
>> Mail: soliva at comcept.ch
>> -----Urspr?ngliche Nachricht-----
>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Montag, 25. Januar 2010 14:37
>> An: kolab-devel at kolab.org
>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>> 204
>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
> argument
>>> is not a valid ldap result resource in
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>
>>> Is this already recognized? Is it not known....I tried to figure out what
>>> is wrong but actually I could not?!
>>>
>>> Any suggestion?
>>
>> My suggestion is to check the given line 204 and see which argument
>> is used there (maybe add a statement to print it out).
>>
>>> By the way is there a documentation about Master/Slave configuration
>>> meaning how this works etc. I could not find anything. Any hints would be
>>> appriciated.
>>
>> I think the documentation is in the architecture documents.
>> The idea is pretty simple: Replicate the directory server on the slave
>> (for which there is a bootstrap) have all read access on the slave
> accounts
>> go
>> to the slave LDAP server and all write access (only by webadmin) to the
>> master.
>>
>> 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
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> --
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
> Fax    : +49 721 1513 52322                        D-20146 Hamburg
> --------------------------------------------------------------------
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
> _______________________________________________
> 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/20100215/f54f0570/attachment-0001.bin

From issues at kolab.org  Mon Feb 15 10:25:40 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 09:25:40 +0000
Subject: [Kolab-devel] [issue4121] Decrypt an unencrypted file shows
	'assertion failed' error
In-Reply-To: <1266225940.85.0.180022847738.issue4121@kolab.org>
Message-ID: <1266225940.85.0.180022847738.issue4121@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleopatra/Win 2.0.13-svn1084205 (gpg4win-2.0.2-rc1):

Try to decrypt/verify an unencrypted file.
-> error: "Kleopatra: assertion "prot != UnknownProtocol" failed in void Kleo ..."
(see kleo log)

Kleopatra should inform the user that this file is unencrypted.

----------
assignedto: marc
files: kleo-log.txt
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23539
nosy: emanuel, marc
priority: urgent
status: unread
title: Decrypt an unencrypted file shows 'assertion failed' error

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4121>
______________________________________
-------------- next part --------------
Startup timing: 331 ms elapsed: Application created 
Startup timing: 361 ms elapsed: UiServer created 
Startup timing: 431 ms elapsed: UiServer started 
UiServer: client connect on fd 1400
[1948.1400] DBG: -> OK GPG UI server (Kleopatra/2.0.13-svn1084205 (2010-02-02)) ready to serve
UiServer: client connection 0BD7BC00 established successfully
[1948.1400] DBG: <- GETINFO pid
[1948.1400] DBG: -> D 1948
[1948.1400] DBG: -> OK
Server PID = 1948 
AllowSetForegroundWindow( 1948 ) failed:  5 
[1948.1400] DBG: <- BYE
[1948.1400] DBG: -> OK closing connection
UiServer: connection 0BD7BC00 closed
Startup timing: 1853 ms elapsed: SelfCheck completed 
ReaderStatusThread[2nd]: new iteration command= "__update__"  ; nullSlot= true 
<update_cardinfo> 
get_card_info( "C:/Dokumente und Einstellungen/test/Anwendungsdaten/gnupg/reader_0.status" , 0 , 0xbd351e0 , NoCard , true ) 
read_status: file "C:/Dokumente und Einstellungen/test/Anwendungsdaten/gnupg/reader_0.status" does not exist 
get_more_detailed_status( "C:/Dokumente und Einstellungen/test/Anwendungsdaten/gnupg/reader_0.status" , 0 , 0xbd351e0 ) 
gpgagent_transact( SCD SERIALNO ) 
gpgagent_transact( SCD SERIALNO ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
Startup timing: 2254 ms elapsed: KeyCache loaded 
KeyFilterManager::reload: final filter count is 12
Startup timing: 2534 ms elapsed: new instance created 
returning from waiting for gpg-agent ...oOO 
gpgagent_transact( SCD SERIALNO ), try # 1 
gpgagent_transact( SCD SERIALNO ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
returning from waiting for gpg-agent ...oOO 
gpgagent_transact( SCD SERIALNO ), try # 2 
gpgagent_transact( SCD SERIALNO ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
UiServer: client connect on fd 1444
[1948.1444] DBG: -> OK GPG UI server (Kleopatra/2.0.13-svn1084205 (2010-02-02)) ready to serve
UiServer: client connection 0BA2D268 established successfully
[1948.1444] DBG: <- GETINFO pid
[1948.1444] DBG: -> D 1948
[1948.1444] DBG: -> OK
[1948.1444] DBG: <- OPTION window-id=1008c
[1948.1444] DBG: -> OK
[1948.1444] DBG: <- [Error: Resource temporarily unavailable]
[1948.1444] DBG: <- FILE C%3a\Dokumente%20und%20Einstellungen\test\Desktop\Neu%20Textdokument.txt
[1948.1444] DBG: -> OK
[1948.1444] DBG: <- DECRYPT_FILES --nohup
dirs ("C:/Dokumente und Einstellungen/test/Desktop/") 
[1948.1444] DBG: -> OK
[1948.1444] DBG: <- BYE
[1948.1444] DBG: -> OK closing connection
[1948.-1] DBG: <- [Error: Invalid argument]
returning from waiting for gpg-agent ...oOO 
Max. retries reached, giving up. 
gpgagent_transact( SCD GETATTR APPTYPE ) 
gpgagent_transact( SCD GETATTR APPTYPE ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
AssuanCommand::done(): Error:  "Kleopatra: assertion "prot != UnknownProtocol" failed in void Kleo::Crypto::DecryptVerifyTask::setProtocol(GpgME::Protocol) (/tmp/builder-home/src/kdepim/kleopatra/crypto/decryptverifytask.cpp:837): Interner Fehler (218103871)" 
UiServer: connection 0BA2D268 closed
returning from waiting for gpg-agent ...oOO 
gpgagent_transact( SCD GETATTR APPTYPE ), try # 1 
gpgagent_transact( SCD GETATTR APPTYPE ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
returning from waiting for gpg-agent ...oOO 
gpgagent_transact( SCD GETATTR APPTYPE ), try # 2 
gpgagent_transact( SCD GETATTR APPTYPE ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 
returning from waiting for gpg-agent ...oOO 
Max. retries reached, giving up. 
scd_getattr_status( APPTYPE ): t == NULL 
parse_app_type(  ) 
ReaderStatus::UnknownApplication 0 
</update_cardinfo> 
ReaderStatusThread[2nd]: slot 0 : NoCard -> CardUsable 
gpgagent_transact( GETEVENTCOUNTER ) 
gpgagent_transact( GETEVENTCOUNTER ): "IPC "connect" Aufruf fehlgeschlagen" 
Assuan problem, try re-creating the assuan context in  2 sec. 
waiting for gpg-agent ...zZZ 

From issues at kolab.org  Mon Feb 15 10:34:18 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 09:34:18 +0000
Subject: [Kolab-devel] [issue4122] New Certificate - Advanced Settings: Tab
	'Technical	Details' should be in front of 'Personal Details'
In-Reply-To: <1266226458.97.0.517955320399.issue4122@kolab.org>
Message-ID: <1266226458.97.0.517955320399.issue4122@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Change tab order in Advanced Settings dialog of the certificate creation wizard.
(Technical Details should be the first tab, because user should check the key
length with one click.)

Tested with Kleopatra 2.0.13-svn1084205 (gpg4win2.0.2-rc1).

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23540
nosy: emanuel, marc
priority: bug
status: unread
title: New Certificate - Advanced Settings: Tab 'Technical Details' should be in front of 'Personal Details'

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4122>
______________________________________


From issues at kolab.org  Mon Feb 15 10:50:01 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 09:50:01 +0000
Subject: [Kolab-devel] [issue4123] Kleopatra's progress bar doesn't show
	progress
In-Reply-To: <1266227401.44.0.973152037748.issue4123@kolab.org>
Message-ID: <1266227401.44.0.973152037748.issue4123@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Encrypt/Decrypt a big file (>40MB) with Kleopatra (tested with
2.0.13-svn1084205, gpg4win-2.0.2rc1).
The progress bar shows always 0% for nearly the whole process (for a 70MB file
it takes about 40-50sec). User could think Kleopatra is freezed. If the process
is nearly finished the value jump to 100% in one step.

The progress bar should increase while the whole crypto process.

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23541
nosy: emanuel, marc
priority: bug
status: unread
title: Kleopatra's progress bar doesn't show progress

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4123>
______________________________________


From issues at kolab.org  Mon Feb 15 11:01:45 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 10:01:45 +0000
Subject: [Kolab-devel] [issue4124] SmartCard: Click on toggled
	Kleopatra-SmartCard-Icon in	SystemTray should run LearnCard command
In-Reply-To: <1266228105.6.0.515389804211.issue4124@kolab.org>
Message-ID: <1266228105.6.0.515389804211.issue4124@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleo 2.0.13-svn1084205 (gpg4win-2.0.2rc1):

- insert smart card
-> SystemTray icon toggled (between Kleopatra and smart card icon)

- click on SystemTray icon:
-> No reaction!

- select context menu SmartCard->LearnCard
=> Ok.

It would be easier to click directly on the (toggled) SystemTray icon to start
learncard command. Maybe it's better to show first a info dialog to confirm the
start of learncard command...

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23542
nosy: emanuel, marc
priority: bug
status: unread
title: SmartCard: Click on toggled Kleopatra-SmartCard-Icon in SystemTray should run LearnCard command

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4124>
______________________________________


From issues at kolab.org  Mon Feb 15 11:06:12 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 15 Feb 2010 10:06:12 +0000
Subject: [Kolab-devel] [issue4125] Event with recurrence: Changing attendee
	of one event, changes it for every event.(rt#6029)
In-Reply-To: <1266228372.03.0.121924839377.issue4125@kolab.org>
Message-ID: <1266228372.03.0.121924839377.issue4125@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100205.1088342-kk4

Test:
1. Create a new event with recurrence(daily, 3 times) and attendee
2. Edit the second event (delete attendee and enter new one)
3. Look at the third event.
=> It has the new attendee. But the user expects, that the change of attendees
is possible only for one event. There should appear a choose how to handle
recurrence dialog.
This is related to kolab/issue4101

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23544
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Event with recurrence: Changing attendee of one event, changes it for every event.(rt#6029)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4125>
______________________________________


From issues at kolab.org  Mon Feb 15 11:46:04 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 10:46:04 +0000
Subject: [Kolab-devel] [issue4127] New certificate: Disabling certificate
	usage 'signing'	doesn't work
In-Reply-To: <1266230764.98.0.381472756843.issue4127@kolab.org>
Message-ID: <1266230764.98.0.381472756843.issue4127@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleo 2.0.13-svn1084205 (gpg4win-2.0.2rc1):
- create new OpenPGP certificate; with Advanced Settings -> Technical Details ->
_Disable_"Signing"
- view certificate details after creation:
=> tab overview: "Certificate usage" shows "Signing EMails and Files" although
signing option was disabled.

Note: Disabling/enabling option "encrytion" and "authentication" works correctly.

----------
assignedto: marc
files: x.509-update-failed.jpg
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23547
nosy: emanuel, marc
priority: urgent
status: unread
title: New certificate: Disabling certificate usage 'signing' doesn't work

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4127>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x.509-update-failed.jpg
Type: image/jpeg
Size: 46360 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/678568d4/x.509-update-failed-0001.jpg

From wilde at intevation.de  Mon Feb 15 12:19:23 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 15 Feb 2010 12:19:23 +0100
Subject: [Kolab-devel] wilde: server/imapd/patches/cyrus-imapd-2.3.16
	cyrus-imapd-cross-domain-acls.patch, NONE, 1.1
In-Reply-To: <201002132115.46733.ml@radoeka.nl> (Richard Bos's message of
	"Sat, 13 Feb 2010 21:15:46 +0100")
References: <20100208171942.E2253600574@lists.intevation.de>
	<201002132115.46733.ml@radoeka.nl>
Message-ID: <s7wljeu7nlw.fsf@intevation.de>

Richard Bos <ml at radoeka.nl> writes:
> Op maandag 08 februari 2010 18:19:42 schreef cvs at kolab.org:
>> Update of /kolabrepository/server/imapd/patches/cyrus-imapd-2.3.16
>> In directory doto:/tmp/cvs-serv24076/imapd/patches/cyrus-imapd-2.3.16
>> 
>> Added Files:
>>         cyrus-imapd-cross-domain-acls.patch 
>> Log Message:
>> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
>
> Is it possible to rename this patch (cyrus-imapd-cross-domain-acls.patch) to:
> KOLAB_cyrus-imapd-cross-domain-acls.patch
>
> Similar to the other patches in:
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/cyrus-
> imapd-2.3.16/

Yes, I agree that's a good idea.  Feel free to rename it.  Please make
sure that the patch still applies after the change.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/12333139/attachment.bin

From wilde at intevation.de  Mon Feb 15 12:24:47 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 15 Feb 2010 12:24:47 +0100
Subject: [Kolab-devel] Brain dump of the week: Horde roadmap
In-Reply-To: <20100212163919.180751tnfayy1zwg@webmail.pardus.de> (Gunnar
	Wrobel's message of "Fri, 12 Feb 2010 16:39:19 +0100")
References: <20100212163919.180751tnfayy1zwg@webmail.pardus.de>
Message-ID: <s7weikm7ncw.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:

Hi Gunnar,

thanks for providing some insights to your horde 4 affords!

> The first set of Horde 4 test packages went into Kolab CVS last week.
> Nothing fancy yet: You only get the Horde base application at the
> moment.

Could you please provide a short receipt on how to give the horde 4
stuff a try?

> The mail  (Imp) 

Is this only imp or the dimp, too?

> and calendar (kronolith) applications are
> still missing. Should be added soon though.

Once again is this the old calendar or the new dynamic one, that is
currently missing?

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/be51e104/attachment.bin

From wilde at intevation.de  Mon Feb 15 12:51:14 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 15 Feb 2010 12:51:14 +0100
Subject: [Kolab-devel] Future of the Webclient: lets take a modest approach,
	dropping IMP and MIMP
Message-ID: <s7waava7m4t.fsf@intevation.de>

Hi *,

Thomas and I had a little talk on various aspects of Kolab and
Kolab-Server, one topic was the web client and one immediate outcome
was, that as long as we still use the current Horde3 based solution
(which surly will be the case for a couple of releases to come) we need
to get it as good and usable as possible with as few afford as
possible[1].

One important step to make this possible is to drop support for IMP and
MIMP.  Currently we are advertising three variations of the web client
on the login screen and all of them are having there specific set of
problems and limitations.

We want to concentrate on one of them to get it as good as possible.
The natural choice is DIMP, as it is the most advanced with regard to
user experience and a bunch of improvements have already been made,
which are not ported yet to the other incarnations[2].

What are the practical implications of this?
- We will remove the choice between IMP,DIMP and MIMP from the login
  screen of the web client.  DIMP will be used always.
- Problems with DIMP gain higher priority, as the alternative IMP will
  no longer be valid.[3]
- Problems with IMP, which don't exist in DIMP might not be fixed.
- Requested feature only have to be realized in DIMP, which makes them
  more likely to get realized.

We hope that we get by this a better tested, more stable and less ugly
client until the time is ripe for greater changes.

Any objections to this plan?  "Speak Now or Forever Hold Your Peace!"
;-) 

cheers
sascha

[1]  no surprise here, we currently don't have big resources to spend.
[2]  partly because no one has gotten around to do it, partly because
     porting would be hart or impossible for technical reasons.
[3]  kolab/issue4080 (DIMP: Mails can not be copied to other folders)
     comes to mind...
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/4952d78c/attachment.bin

From wrobel at pardus.de  Mon Feb 15 13:24:00 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 15 Feb 2010 13:24:00 +0100
Subject: [Kolab-devel] Brain dump of the week: Horde roadmap
In-Reply-To: <s7weikm7ncw.fsf@intevation.de>
References: <20100212163919.180751tnfayy1zwg@webmail.pardus.de>
	<s7weikm7ncw.fsf@intevation.de>
Message-ID: <20100215132400.15233n8quuej4kqo@webmail.pardus.de>

Hi Sascha,

Quoting Sascha Wilde <wilde at intevation.de>:

> Gunnar Wrobel <wrobel at pardus.de> writes:
>
> Hi Gunnar,
>
> thanks for providing some insights to your horde 4 affords!
>
>> The first set of Horde 4 test packages went into Kolab CVS last week.
>> Nothing fancy yet: You only get the Horde base application at the
>> moment.
>
> Could you please provide a short receipt on how to give the horde 4
> stuff a try?

Currently it should be sufficient to compile the packages in  
"server/pear-h4" and "kolab-webclient-h4" and install them. I did not  
yet add a "make dist-h4" target to our central makefile but I think I  
will be able to add one this week.

>
>> The mail  (Imp)
>
> Is this only imp or the dimp, too?

That needs an important piece of background information that was not  
included in my last mail: For horde4 there is only imp. Dimp and Mimp  
have been integrated and are no longer separate applications.

>
>> and calendar (kronolith) applications are
>> still missing. Should be added soon though.
>
> Once again is this the old calendar or the new dynamic one, that is
> currently missing?

Same here. There is just one kronolith with two different frontends in Horde4.

So when installing this right now it really does not offer much.  
Basically only the Horde portal page.

My plan was to add Imp this week and I hope I find a free evening for  
this during the next days.

Cheers,

Gunnar

>
> cheers
> sascha
> --
> Sascha Wilde                                          OpenPGP key: 4BB86568
> http://www.intevation.de/~wilde/                  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
>



-- 
____ 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/20100215/8a995783/attachment.bin

From issues at kolab.org  Mon Feb 15 14:18:14 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 13:18:14 +0000
Subject: [Kolab-devel] [issue4129] Add Key-ID to certificate details
In-Reply-To: <1266239894.81.0.768098147086.issue4129@kolab.org>
Message-ID: <1266239894.81.0.768098147086.issue4129@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Currently (with gpg4win2.0.2-rc1) the certificate details dialog shows
fingerprint only. The key-id is missing in this dialog. Please add!

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23563
nosy: emanuel, marc
priority: bug
status: unread
title: Add Key-ID to certificate details

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4129>
______________________________________


From issues at kolab.org  Mon Feb 15 14:25:18 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 13:25:18 +0000
Subject: [Kolab-devel] [issue4130] Make Kleopatra's columns configurable
In-Reply-To: <1266240318.47.0.563333009786.issue4130@kolab.org>
Message-ID: <1266240318.47.0.563333009786.issue4130@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Wish:
* Show context menu to enable/disable columns if right clicking on column
headers (like in KMail)
* Drag'n'Drop columns to change order of columns (like in KMail)
* Add new column key-id

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23566
nosy: emanuel, marc
priority: wish
status: unread
title: Make Kleopatra's columns configurable

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4130>
______________________________________


From wilde at intevation.de  Mon Feb 15 15:37:18 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 15 Feb 2010 15:37:18 +0100
Subject: [Kolab-devel] z-push: problematic license
In-Reply-To: <s7w3a16iets.fsf@intevation.de> (Sascha Wilde's message of "Fri, 
	12 Feb 2010 17:44:31 +0100")
References: <s7w3a16iets.fsf@intevation.de>
Message-ID: <s7w7hqezhsx.fsf@intevation.de>

Sascha Wilde <wilde at intevation.de> writes:

> - I would suggest to contact z-push upstream and ask about the reasons
>   for this license limitation.[2]

FYI: We (Intevation) made contact to Zarafa and will talk with them
about this problem.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/d09ebb8b/attachment.bin

From issues at kolab.org  Mon Feb 15 16:43:05 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 15 Feb 2010 15:43:05 +0000
Subject: [Kolab-devel] [issue4131] Kleopatra keylisting is too slow
In-Reply-To: <1266248585.93.0.948640917275.issue4131@kolab.org>
Message-ID: <1266248585.93.0.948640917275.issue4131@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

Kleopatra should diff the keys from the new keylisting with those from the old 
and update the view only where things have changed.

This would also solve the problem that, in hierarchical mode, the items 
collapse on refresh.

----------
keyword: gpg4win2, kleo
messages: 23575
nosy: marc
priority: minor bug
status: unread
title: Kleopatra keylisting is too slow

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4131>
______________________________________


From wrobel at pardus.de  Mon Feb 15 20:45:45 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 15 Feb 2010 20:45:45 +0100
Subject: [Kolab-devel] Future of the Webclient: lets take a
	modest	approach, dropping IMP and MIMP
In-Reply-To: <s7waava7m4t.fsf@intevation.de>
References: <s7waava7m4t.fsf@intevation.de>
Message-ID: <20100215204545.22621hwibjwuqa9w@webmail.pardus.de>

Hi Sascha,

Quoting Sascha Wilde <wilde at intevation.de>:

> Hi *,
>
> Thomas and I had a little talk on various aspects of Kolab and
> Kolab-Server, one topic was the web client and one immediate outcome
> was, that as long as we still use the current Horde3 based solution
> (which surly will be the case for a couple of releases to come) we need
> to get it as good and usable as possible with as few afford as
> possible[1].
>
> One important step to make this possible is to drop support for IMP and
> MIMP.  Currently we are advertising three variations of the web client
> on the login screen and all of them are having there specific set of
> problems and limitations.
>
> We want to concentrate on one of them to get it as good as possible.
> The natural choice is DIMP, as it is the most advanced with regard to
> user experience and a bunch of improvements have already been made,
> which are not ported yet to the other incarnations[2].
>
> What are the practical implications of this?
> - We will remove the choice between IMP,DIMP and MIMP from the login
>   screen of the web client.  DIMP will be used always.
> - Problems with DIMP gain higher priority, as the alternative IMP will
>   no longer be valid.[3]
> - Problems with IMP, which don't exist in DIMP might not be fixed.
> - Requested feature only have to be realized in DIMP, which makes them
>   more likely to get realized.
>
> We hope that we get by this a better tested, more stable and less ugly
> client until the time is ripe for greater changes.
>
> Any objections to this plan?  "Speak Now or Forever Hold Your Peace!"
> ;-)

While I don't have objections in general I'm still uncertain about the  
specific course of action.

Right now it looks to me that we do not have a concrete  
"must-have"-list for dimp. There are of course a few shortcomings we  
already identified but to my knowledge we didn't have time for a  
thorough analysis yet. Thus it is hard to estimate the required effort.

And I assume there will be some overlaps with things that have already  
been completed in Horde 4 (e.g. support for PGP in Dimp).

I'm certain we will have a good amount of testing on the web client  
anyhow. So if we are going to invest that it might be the better  
choice to go for Horde4 even if that is not maximally stable yet.

I'm not at all saying that this is the best way to go. I just want to  
consider that option which is why I'd like to add the corresponding  
Horde4 packages as soon as possible so that we can evaluate it.

Cheers,

Gunnar

>
> cheers
> sascha
>
> [1]  no surprise here, we currently don't have big resources to spend.
> [2]  partly because no one has gotten around to do it, partly because
>      porting would be hart or impossible for technical reasons.
> [3]  kolab/issue4080 (DIMP: Mails can not be copied to other folders)
>      comes to mind...
> --
> Sascha Wilde                                          OpenPGP key: 4BB86568
> http://www.intevation.de/~wilde/                  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
>



-- 
______ 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/20100215/60e00888/attachment.bin

From ml at radoeka.nl  Mon Feb 15 21:49:17 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Feb 2010 21:49:17 +0100
Subject: [Kolab-devel] Good article that shows that calendaring and
	synchronization are important functions for a business
Message-ID: <201002152149.17297.ml@radoeka.nl>

Good article that shows that calendaring and synchronization are important 
functions for a business:
http://blog.internode.on.net/2010/02/12/microsoft-exchange-at-internode/

-- 
Richard


From ml at radoeka.nl  Mon Feb 15 21:58:10 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Feb 2010 21:58:10 +0100
Subject: [Kolab-devel] wilde: server/imapd/patches/cyrus-imapd-2.3.16
	cyrus-imapd-cross-domain-acls.patch, NONE, 1.1
In-Reply-To: <s7wljeu7nlw.fsf@intevation.de>
References: <20100208171942.E2253600574@lists.intevation.de>
	<201002132115.46733.ml@radoeka.nl> <s7wljeu7nlw.fsf@intevation.de>
Message-ID: <201002152158.10737.ml@radoeka.nl>

Op maandag 15 februari 2010 12:19:23 schreef Sascha Wilde:
> Richard Bos <ml at radoeka.nl> writes:
> > Op maandag 08 februari 2010 18:19:42 schreef cvs at kolab.org:
> >> Update of /kolabrepository/server/imapd/patches/cyrus-imapd-2.3.16
> >> In directory doto:/tmp/cvs-serv24076/imapd/patches/cyrus-imapd-2.3.16
> >>
> >> Added Files:
> >>         cyrus-imapd-cross-domain-acls.patch
> >> Log Message:
> >> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
> >
> > Is it possible to rename this patch (cyrus-imapd-cross-domain-acls.patch)
> > to: KOLAB_cyrus-imapd-cross-domain-acls.patch
> >
> > Similar to the other patches in:
> > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/cyrus-
> > imapd-2.3.16/
> 
> Yes, I agree that's a good idea.  Feel free to rename it.  Please make
> sure that the patch still applies after the change.

The latter has nothing to do with a name change.  Someone that packages cyrus 
for openpkg would be a better candidate to rename.  He can do the renaming and 
the change in the spec file at the same time.   That will take care that the 
patch continues to apply...

-- 
Richard


From ml at radoeka.nl  Mon Feb 15 22:04:04 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Feb 2010 22:04:04 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002141615.54667.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002142059.14948.ml@radoeka.nl>
	<201002141615.54667.thomas@btspuhler.com>
Message-ID: <201002152204.04735.ml@radoeka.nl>

Op maandag 15 februari 2010 00:15:54 schreef Thomas Spuhler:
> I think I miss one package (can't see the forest because of all the trees)

I believe that I miss the same one ;)

> # rpm -ivh  kolab-storage-0.4.0-1mdv2010.0.noarch.rpm
> error: Failed dependencies:
>         pear(Horde/Share.php) is needed by kolab-
> storage-0.4.0-1mdv2010.0.noarch
> I cannot find this horde/Share.php

$ locate Share.php
/srv/www/htdocs/client/lib/Horde/Share.php

I would expect Share.php to be installed under Pear.  The file above is 
delivered by: 
$  rpm -qf /srv/www/htdocs/client/lib/Horde/Share.php
kolab-webclient-1.2-3.1

But that is an additional package...  

I assume that the package horde-share is missing:
http://pear.horde.org/index.php?package=Horde_Share&downloads

-- 
Richard


From ml at radoeka.nl  Mon Feb 15 22:06:49 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 15 Feb 2010 22:06:49 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002142013.37626.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002142059.14948.ml@radoeka.nl>
	<201002142013.37626.thomas@btspuhler.com>
Message-ID: <201002152206.49744.ml@radoeka.nl>

Op maandag 15 februari 2010 04:13:37 schreef Thomas Spuhler:
> Another quirk: What is PreReq in the spec file standing for? Mandriva
>  doesn't  permit it in the spec file.

Internet is your friend ;)
http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
"The PreReq tag is the same as Requires, originally with one additional 
property. Using it used to tell RPM that the package marked as PreReq should 
be installed before the package containing the dependency. However, as of RPM 
version 4.4, this special property is being phased out, and PreReq and 
Requires will soon have no functional differences."

-- 
Richard


From thomas at btspuhler.com  Tue Feb 16 04:46:45 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Mon, 15 Feb 2010 20:46:45 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002152204.04735.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002141615.54667.thomas@btspuhler.com>
	<201002152204.04735.ml@radoeka.nl>
Message-ID: <201002152046.45227.thomas@btspuhler.com>

On Monday 15 February 2010 02:04:04 pm Richard Bos wrote:
> Op maandag 15 februari 2010 00:15:54 schreef Thomas Spuhler:
> > I think I miss one package (can't see the forest because of all the
> > trees)
>
> I believe that I miss the same one ;)
>
> > # rpm -ivh  kolab-storage-0.4.0-1mdv2010.0.noarch.rpm
> > error: Failed dependencies:
> >         pear(Horde/Share.php) is needed by kolab-
> > storage-0.4.0-1mdv2010.0.noarch
> > I cannot find this horde/Share.php
>
> $ locate Share.php
> /srv/www/htdocs/client/lib/Horde/Share.php
>
> I would expect Share.php to be installed under Pear.  The file above is
> delivered by:
> $  rpm -qf /srv/www/htdocs/client/lib/Horde/Share.php
> kolab-webclient-1.2-3.1
>
> But that is an additional package...
>
> I assume that the package horde-share is missing:
> http://pear.horde.org/index.php?package=Horde_Share&downloads

Yep, it contains the file
-- 
Thomas


From thomas at btspuhler.com  Tue Feb 16 04:48:15 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Mon, 15 Feb 2010 20:48:15 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002152206.49744.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002142013.37626.thomas@btspuhler.com>
	<201002152206.49744.ml@radoeka.nl>
Message-ID: <201002152048.15630.thomas@btspuhler.com>

On Monday 15 February 2010 02:06:49 pm Richard Bos wrote:
> Op maandag 15 februari 2010 04:13:37 schreef Thomas Spuhler:
> > Another quirk: What is PreReq in the spec file standing for? Mandriva
> >  doesn't  permit it in the spec file.
>
> Internet is your friend ;)
> http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
> "The PreReq tag is the same as Requires, originally with one additional
> property. Using it used to tell RPM that the package marked as PreReq
> should be installed before the package containing the dependency. However,
> as of RPM version 4.4, this special property is being phased out, and
> PreReq and Requires will soon have no functional differences."

Yea, I discussed it on IRC. I replaced it with Requires(pre)
PreReq is rejected on the Mandriva build server.

-- 
Thomas


From thomas at btspuhler.com  Tue Feb 16 06:20:21 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Mon, 15 Feb 2010 22:20:21 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002131404.28885.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002122255.01216.thomas@btspuhler.com>
	<201002131404.28885.ml@radoeka.nl>
Message-ID: <201002152220.21545.thomas@btspuhler.com>

On Saturday 13 February 2010 06:04:28 am Richard Bos wrote:
> Op zaterdag 13 februari 2010 06:55:01 schreef Thomas Spuhler:
> > To build this package php-pear-channel-horde-1.0
> > is required.
> > OR
> > ***************
> > Installing packages from pear.horde.org is easy. Just follow the simple
> >  steps  below.
> >
> > Note: You need a working PEAR 1.4 environment. For more information on
> >  PEAR  and how to install PEAR, see our FAQ
> >
> >    1. First, add the channel server using:
> >       pear channel-discover pear.horde.org
> >    2. Once this is complete, you can install any of our packages using:
> >       pear install horde/some_package_name
> > **************
> > I am afraid, this is not going to work on a native installation such as
> > Mandriva. I can build it on my own box but not on the Mandriva build
> >  cluster.
> >
> > Is there a workaround for this?
>
> Of course.  Just add the channel with an rpm
> See
> http://download.opensuse.org/repositories/server:/php:/applications/openSUS
>E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> or
> http://download.opensuse.org/repositories/server:/php:/applications/openSUS
>E_11.2/src/ (look for rpms with channel in their name) and the rest of the
> internet for other examples.

It seems this php-pear-channel package is the problem for not building the 
other packages that depend on it.
I have in the xml file: 
pear.horde.org Horde PEAR Channel horde    
http://pear.horde.org/Chiara_PEAR_Server_REST/ 
http://pear.horde.org/Chiara_PEAR_Server_RESor should it be:

pear channel-discover pear.horde.org

is this correct?

-- 
Thomas


From wrobel at pardus.de  Tue Feb 16 07:27:15 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 16 Feb 2010 07:27:15 +0100
Subject: [Kolab-devel] wilde:
	server/imapd/patches/cyrus-imapd-2.3.16	cyrus-imapd-cross-domain-acls.patch,
	NONE, 1.1
In-Reply-To: <201002152158.10737.ml@radoeka.nl>
References: <20100208171942.E2253600574@lists.intevation.de>
	<201002132115.46733.ml@radoeka.nl> <s7wljeu7nlw.fsf@intevation.de>
	<201002152158.10737.ml@radoeka.nl>
Message-ID: <20100216072715.561811fb90zik340@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op maandag 15 februari 2010 12:19:23 schreef Sascha Wilde:
>> Richard Bos <ml at radoeka.nl> writes:
>> > Op maandag 08 februari 2010 18:19:42 schreef cvs at kolab.org:
>> >> Update of /kolabrepository/server/imapd/patches/cyrus-imapd-2.3.16
>> >> In directory doto:/tmp/cvs-serv24076/imapd/patches/cyrus-imapd-2.3.16
>> >>
>> >> Added Files:
>> >>         cyrus-imapd-cross-domain-acls.patch
>> >> Log Message:
>> >> Added Bernhard Herzog's cross domain acl patch (see kolab/issue1141).
>> >
>> > Is it possible to rename this patch (cyrus-imapd-cross-domain-acls.patch)
>> > to: KOLAB_cyrus-imapd-cross-domain-acls.patch
>> >
>> > Similar to the other patches in:
>> > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/cyrus-
>> > imapd-2.3.16/
>>
>> Yes, I agree that's a good idea.  Feel free to rename it.  Please make
>> sure that the patch still applies after the change.
>
> The latter has nothing to do with a name change.  Someone that packages cyrus
> for openpkg would be a better candidate to rename.  He can do the  
> renaming and
> the change in the spec file at the same time.   That will take care that the
> patch continues to apply...

Done. Still builds fine but I did not yet check the functionality.

While I personally think the starting "KOLAB" tag is not that  
important it is nice to have as an indicator where the patch comes  
from. The version tag in the file name has technical reasons though  
and we should try to keep it. It is useful within the spec files and  
helps when migrating the patch queue to a newer version.

@sascha: There is also a "series" file in the  
"patches/cyrus-imapd-2.3.16" directory that indicates the patch order.  
I know that we have the information in the spec file, too. But the  
series file helps with quickly updating the patch queue when a new  
cyrus imap server version arrives. The "imapd/patches/Makefile"  
contains some magic which automates the process using the mercurial  
patch queue management.

Cheers,

Gunnar

>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- 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/20100216/a7dcfd10/attachment.bin

From alain.abbas at libertech.fr  Tue Feb 16 10:11:08 2010
From: alain.abbas at libertech.fr (Alain abbas)
Date: Tue, 16 Feb 2010 10:11:08 +0100
Subject: [Kolab-devel] Good article that shows that calendaring
 and	synchronization are important functions for a business
In-Reply-To: <201002152149.17297.ml@radoeka.nl>
References: <201002152149.17297.ml@radoeka.nl>
Message-ID: <4B7A612C.6060608@libertech.fr>

hi
thats why zpush integration to kolab  is urgent ...    we working ....


Richard Bos a ?crit :
> Good article that shows that calendaring and synchronization are important 
> functions for a business:
> http://blog.internode.on.net/2010/02/12/microsoft-exchange-at-internode/
>
>   


From greve at intevation.de  Tue Feb 16 12:37:34 2010
From: greve at intevation.de (Georg C. F. Greve)
Date: Tue, 16 Feb 2010 12:37:34 +0100
Subject: [Kolab-devel] Introductions
Message-ID: <201002161237.35200.greve@intevation.de>

Hi all,

After speaking to some people personally over the past weeks, I think it is 
time to also introduce myself here as I am "one of the new guys" in the Kolab 
universe. You can find information about me and my prior work at 
http://fsfe.org/about/greve/ or http://www.linkedin.com/in/GeorgGreve

When I began preparing the handover at FSFE, Bernhard cleverly began roping me 
into the Kolab world, and ultimately Bernhard and Till managed to convince 
myself and Dr. Paul Adams (who I will let introduce himself) to drive the 
process of re-launching the Kolab business into a new company that should 
bring more energy, developers, customers and partners into Kolab.

So while Paul started working with KDAB I spent the past months primarily in 
Osnabr?ck with Thomas, Sascha, Bernhard at Intevation wrapping our heads 
around the Kolab ecoystem and talking to many businesses in the Kolab world, 
developing our future business concept and starting to work out the 
implementation plans.

Meanwhile we are coming close to being able to launch the new business, and so 
we would like to introduce ourselves and say hi. Our hope is to work together 
with all of you as we bring more people into this list.

So if you have something you would like to talk about, if you would like to 
talk technology or business with either of us, please don't hesitate to het in 
touch. 

Best regards,
Georg


From thomas at koch.ro  Tue Feb 16 13:41:47 2010
From: thomas at koch.ro (Thomas Koch)
Date: Tue, 16 Feb 2010 13:41:47 +0100
Subject: [Kolab-devel] Introductions
In-Reply-To: <201002161237.35200.greve@intevation.de>
References: <201002161237.35200.greve@intevation.de>
Message-ID: <201002161341.47494.thomas@koch.ro>

> Hi all,
Hi Georg,

nice to hear from you on this list. I'm only a listener here, because I'm 
interested in groupware and once thought, kolab would be an interesting 
option.
I'm looking forward to see more details about partner options and will try to 
recheck on the kolab code in the next weeks!

Hast Du noch den GPG fingerprint von der FOSDEM? :-)

Gr??e,

Thomas Koch, http://www.koch.ro


From issues at kolab.org  Tue Feb 16 14:10:17 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 13:10:17 +0000
Subject: [Kolab-devel] [issue4132] pinentry-qt4: implement confirm
	yes/no/cancel
In-Reply-To: <1266325817.39.0.278829160914.issue4132@kolab.org>
Message-ID: <1266325817.39.0.278829160914.issue4132@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

Says Marcus Brinkmann:
pinentry's confirm command can now have three results: yes, no, cancel.  This
was implemented to get rid of the do-you-trust messages (answering "no" will
get rid of them).

This is not yet implemented in pinentry-qt4.  Here is how it works:

  if (!pinentry->pin && !pinentry->one_button && pinentry->notok)
    {
      /* Add button with text "pinentry->notok".  */
      [...]
    }

Furthermore:

If "cancel" or window close:

  pinentry->canceled = 1
  return 0;

If OK:
  return 1;

If NOT OK:
  return 0;

----------
assignedto: marc
keyword: enterprise4, gpg4win2
messages: 23595
nosy: bernhard, emanuel, marc, till
status: unread
title: pinentry-qt4: implement confirm yes/no/cancel

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4132>
______________________________________


From issues at kolab.org  Tue Feb 16 14:22:35 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Tue, 16 Feb 2010 13:22:35 +0000
Subject: [Kolab-devel] [issue4133] New Certificate Wizard: Show warning if
	required text	fields not valid
In-Reply-To: <1266326555.76.0.0498887626377.issue4133@kolab.org>
Message-ID: <1266326555.76.0.0498887626377.issue4133@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleopatra from gpg4win 2.0.2-rc1:
- Create new OpenPGP certificate
- Use Name: "test" and E-Mail: "test at example.com"
=> NEXT button is still disabled!
User doesn't know why. 

- add one character to name field (e.g. test1)
=> NEXT button is enabled.

For all required text fields (OpenPGP and X.509) user needs feedback if input
not valid (e.g. to short, email not correct etc.). Please implement same "live
check" function for add new user-id dialog.

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23597
nosy: emanuel, marc
priority: urgent
status: unread
title: New Certificate Wizard: Show warning if required text fields not valid

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4133>
______________________________________


From issues at kolab.org  Tue Feb 16 14:28:11 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 13:28:11 +0000
Subject: [Kolab-devel] [issue4134] SetInitialPinDialog: cancel pinentry ->
	dialog thinks it	succeeded
In-Reply-To: <1266326891.36.0.0307030128584.issue4134@kolab.org>
Message-ID: <1266326891.36.0.0307030128584.issue4134@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

To reproduce:
1. Insert NetKey v3 card w/nullpin
2. Start Kleopatra
3. Click on blinking Kleo icon
-> dialog come up
4. Click on "Set Initial PIN (NKS)" button
5. Cancel the pinentry that comes up
=> "Set Initial PIN (SigG)" button is enabled, "Set Initial PIN (NKS)" is 
disabled.
Expected: It should be the other way around.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23598
nosy: emanuel, marc
priority: bug
status: unread
title: SetInitialPinDialog: cancel pinentry -> dialog thinks it succeeded

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4134>
______________________________________


From issues at kolab.org  Tue Feb 16 14:29:31 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 13:29:31 +0000
Subject: [Kolab-devel] [issue4135] SetInitialPinDialog: widgets not properly
	disabled while	pinentry is up
In-Reply-To: <1266326971.62.0.32688563905.issue4135@kolab.org>
Message-ID: <1266326971.62.0.32688563905.issue4135@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

To reproduce:
1. Insert NetKey v3 card w/nullpin
2. Start Kleopatra
3. Click on blinking Kleo icon
-> dialog come up
4. Click on "Set Initial PIN (NKS)" button
=> "Set Initial PIN (SigG)" button is enabled
Expected: It shouldn't be.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23599
nosy: emanuel, marc
priority: bug
status: unread
title: SetInitialPinDialog: widgets not properly disabled while pinentry is up

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4135>
______________________________________


From issues at kolab.org  Tue Feb 16 14:31:31 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Tue, 16 Feb 2010 13:31:31 +0000
Subject: [Kolab-devel] [issue4136] Add Power-User-Mode with config option
In-Reply-To: <1266327091.5.0.481348608658.issue4136@kolab.org>
Message-ID: <1266327091.5.0.481348608658.issue4136@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Please add a Kleopatra config option to enable "power user mode" (or similar).
Default: disabled

If user enabled this option all crypto operations run without any dialog of
result or confirmation.
Only in case of conflict (there are more than one certificate which matchs with
sender/recipient) or errors (verification/decrytion failed) Kleopatra should
show a certificate choice dialog / result dialog.

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23600
nosy: emanuel, marc
priority: urgent
status: unread
title: Add Power-User-Mode with config option

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4136>
______________________________________


From issues at kolab.org  Tue Feb 16 14:38:43 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Tue, 16 Feb 2010 13:38:43 +0000
Subject: [Kolab-devel] [issue4137] Kleopatra freezed if run GpgEX
	via	sign/encrypt-file-open-dialog
In-Reply-To: <1266327523.22.0.0112931201211.issue4137@kolab.org>
Message-ID: <1266327523.22.0.0112931201211.issue4137@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleopatra from gpg4win-2.0.2-rc1:

- open Kleopatra menu: file > sign/encrypt files...
- select a file and run GPGEX context menu entry "sign and encrypt" 
=> Kleopatra freezed - no reaction! User have to kill kleopatra.

----------
assignedto: marc
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23601
nosy: emanuel, marc
priority: bug
status: unread
title: Kleopatra freezed if run GpgEX via sign/encrypt-file-open-dialog

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4137>
______________________________________


From issues at kolab.org  Tue Feb 16 17:09:07 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 16:09:07 +0000
Subject: [Kolab-devel] [issue4138] After Set Initial PIN: card status isn't
	updated
In-Reply-To: <1266336547.72.0.0792302055422.issue4138@kolab.org>
Message-ID: <1266336547.72.0.0792302055422.issue4138@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

To reproduce:
1. Set an initial PIN, two steps.
=> Learn Card is still disabled, Set Initial Pin enabled, in the smartcard 
menu.
Expected: The other way around.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23608
nosy: emanuel, marc
priority: bug
status: unread
title: After Set Initial PIN: card status isn't updated

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4138>
______________________________________


From issues at kolab.org  Tue Feb 16 17:11:32 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 16:11:32 +0000
Subject: [Kolab-devel] [issue4139] Show Card Serial-No. in Details and
	Tooltip.
In-Reply-To: <1266336692.13.0.264693510794.issue4139@kolab.org>
Message-ID: <1266336692.13.0.264693510794.issue4139@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

There's currently no way to see which card (= serial no) a listed key comes 
from.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23609
nosy: emanuel, marc
priority: minor bug
status: unread
title: Show Card Serial-No. in Details and Tooltip.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4139>
______________________________________


From issues at kolab.org  Tue Feb 16 17:21:33 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 16:21:33 +0000
Subject: [Kolab-devel] [issue4140] Show fake entry for non-available CAs in
	the main window, and group subjects under it
In-Reply-To: <1266337293.81.0.201200469389.issue4140@kolab.org>
Message-ID: <1266337293.81.0.201200469389.issue4140@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

Much like the Details -> Chain view.

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23610
nosy: emanuel, marc
priority: wish
status: unread
title: Show fake entry for non-available CAs in the main window, and group subjects under it

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4140>
______________________________________


From issues at kolab.org  Tue Feb 16 17:27:57 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 16 Feb 2010 16:27:57 +0000
Subject: [Kolab-devel] [issue4141] Implement revoke key/uid/signature/subkey;
	create revocation certificate
In-Reply-To: <1266337677.63.0.573113280651.issue4141@kolab.org>
Message-ID: <1266337677.63.0.573113280651.issue4141@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

.

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23611
nosy: bernhard, emanuel, marc
priority: wish
status: unread
title: Implement revoke key/uid/signature/subkey; create revocation certificate

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4141>
______________________________________


From soliva at comcept.ch  Tue Feb 16 18:35:04 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Tue, 16 Feb 2010 18:35:04 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <20100215100000.59382tahnkzoqk9c@webmail.pardus.de>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch>
	<20100215100000.59382tahnkzoqk9c@webmail.pardus.de>
Message-ID: <001b01caaf2e$5ffbbbd0$1ff33370$@ch>

Hi Gunnar

No problem can give a try...give me a hint as soon as the patch is
available....

Kind regards

Andrea

Mail: soliva at comcept.ch 

-----Urspr?ngliche Nachricht-----
Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Montag, 15. Februar 2010 10:00
An: kolab-devel at kolab.org
Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search

Hi Andrea,

actually the error you see is probably a side effect of the bug I  
introduced with the fix for https://issues.kolab.org/issue3499. I'll  
try to provide a patch for that today. Please add yourself in nosy  
there. Would be great if you could provide feedback if that works.

Cheers,

Gunnar

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> Sorry was in holidays for a fiew days :-)
>
> I tried to include your suggested stuff "var_dump($base);" in the Code of:
>
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>
> But as a pity without success....I'm not so familar with php :-( can you
> please advice how you would include it.
>
> Regarding your suggstion what the symptomes are if this error occurs
> following:
>
> The error occures "ONLY" if a user is added or modified within the manager
> interface. It happens also if a Distribution List ist added or modified.
For
> the manager itself which add's or modifies the users or distribution list
on
> the manager interface nothing occured meanining I added over 20 domains
with
> 50 email address's and aliases but I never was kicked out or saw a blank
> white page or a error from php or whatever. I'm using kolab since years
and
> this never occoured but I have to say what I did this time was to add a
> Domain Maintainer which I never used before...could this be the reason? If
I
> looked in as the Domain Maintainer and added a user I had some kick outs
and
> blank white pages? I have a strange feeling about this function but that
we
> have no misunderstandig at all as Kolab Manager I had never blank pages or
> uncontrolled kicke outs.
>
> If you could advice where to add the code etc. I can follow up on this....
>
> PS: One more thing which you are probably interessted....I did in rc.conf
> template a modification....this means in the past for config the entry in
> this file was:
>
> openldap_url="ldap:// ldaps://"
>
> This was working fine without any problems...in the newewst version the
> entry is:
>
> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>
> This was given errors and a lot of problems because the real entry in the
> /kolab/etc/rc.conf was looking:
>
> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>
> This does not work and I changed to 127.0.0.1 or back to the old style.
Both
> is working fine:
>
> openldap_url="ldap:// ldaps://"
>
> I do not think so that this has something to do with the issue which we
are
> discussion here even I do not understand the
"openldap_url="ldap://0.0.0.0/
> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
the
> bind_addr did not work as expected because I'm using Kolab in a Solaris
Zone
> and the localhost as the 127.0.0.1 is handled in some circumstances in
> another way.....this only for your information. I documented the overall
> stuff on the Wiki:
>
> https://wiki.kolab.org/index.php/Solaris
>
>
> Kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Donnerstag, 11. Februar 2010 22:10
> An: kolab-devel at kolab.org
> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Hi Andrea,
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi
>>
>> It is from my point of view clear the search function but even I see the
>> lines I can not identify what is false and why?:
>>
>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
> 204
>>
>>
>> 201    function search( $base, $filter, $attrs = false ) {
>>    202      $this->freeSearchResult();
>>    203      if( $attrs ) {
>>    204            $this->search_result = ldap_search( $this->connection,
>> $base, $filter, $attrs );
>>    205          } else {
>>    206            $this->search_result = ldap_search( $this->connection,
>> $base, $filter );
>>    207          }
>>    208      return $this->search_result;
>>    209    }
>
> The error sounds as if $base contains an invalid value. You could add
> a "var_dump($base);" in the code to display the value.
>
> Both log entries you mentioned are just warnings though. The code
> won't stop on a warning. And the code of the web admin is not exactly
> clean when it comes to notices and warnings. Quite the contrary. So
> what you see might not be a real problem.
>
> But I did not quite understand what kind of problems you saw in the
> actual frontend. Did you see any specific errors that were displayed?
> Or did the web admin just show you a blank page (the PHP white screen
> of death)?
>
> Cheers,
>
> Gunnar
>
>>
>>
>> is not a valid ldap result resource in
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>
>>    411    // Count the number of occurences of an email address
>>    412    // in users' mail and alias attributes and in dist. lists.
>>    413    // This can be used to check for uniqueness etc.
>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>    415          // First count users
>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>    417                         (alias='.$this->escape($mail).')
>>    418                       )
>>    419                       (uid='.$this->escape($mail).')
>>    420                     )';
>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>> array( 'dn' ) );
>>    422          $count = 0;
>>    423
>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>    425          if( $excludedn ) {
>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>    427                  if( is_null( $entries[$i] ) ) continue;
>>    428                  if(
> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>    429                  debug("found ".$entries[$i]['dn'] );
>>    430                  $count++;
>>    431            }
>>    432          } else $count += $entries['count'];
>>
>>
>> Kind regards
>>
>> Andrea Soliva
>>
>> Mail: soliva at comcept.ch
>> -----Urspr?ngliche Nachricht-----
>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Montag, 25. Januar 2010 14:37
>> An: kolab-devel at kolab.org
>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
DN
>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>> 204
>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
> argument
>>> is not a valid ldap result resource in
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>
>>> Is this already recognized? Is it not known....I tried to figure out
what
>>> is wrong but actually I could not?!
>>>
>>> Any suggestion?
>>
>> My suggestion is to check the given line 204 and see which argument
>> is used there (maybe add a statement to print it out).
>>
>>> By the way is there a documentation about Master/Slave configuration
>>> meaning how this works etc. I could not find anything. Any hints would
be
>>> appriciated.
>>
>> I think the documentation is in the architecture documents.
>> The idea is pretty simple: Replicate the directory server on the slave
>> (for which there is a bootstrap) have all read access on the slave
> accounts
>> go
>> to the slave LDAP server and all write access (only by webadmin) to the
>> master.
>>
>> 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
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> --
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
> Fax    : +49 721 1513 52322                        D-20146 Hamburg
> --------------------------------------------------------------------
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
> _______________________________________________
> 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 <<
--------------------------------------------------------------------


From wilde at intevation.de  Tue Feb 16 18:39:33 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 16 Feb 2010 18:39:33 +0100
Subject: [Kolab-devel] Kolab Server 2.3 Goals
Message-ID: <s7w1vglrsfe.fsf@intevation.de>

Hi *,

as reported in my mail on the short time web client future I and Thomas
developed ideas on some aspects of Kolab development.  Another
important aspect is the set of features we want to get into Kolab Server
2.3 (which will be released from the current CVS HEAD).

Here is a short list of the highlights:

-  LDAP DN:

   Its a well known fact, that the dn of kolab users currently contains
   the users cn, which is an awfully bad thing, as you can not have two
   users with the same name on one Kolab Server installation, not even
   in different domains.

   We will change this for 2.3.  It might be a good opportunity to
   introduce further improvements of the LDAP schmema, too -- but we
   are currently not sure if this will happen for 2.3.

   But it is set: we will fix the user dn.[1]

-  Cross Domain ACLs

   As I announced in an other thread, experimental cross domain acl
   support has been merged to HEAD and 2.2-branch -- and of cause we
   want to get it in a stable state, so that it can be part of 2.3 at
   least in beta quality.

-  Zpush

   Announced elsewhere, too: I want Zpush in 2.3.  There are currently
   licensing issues, but in case we get them resolved it will be part of
   the next major release.

-  OpenPKG Update

   We will incorporate all the last freely released OpenPKG packages.
   Gunnar already updated cyrus imapd, openldap, apache, postfix and
   some more will follow!

-  Map IMAP groups on LDAP groups

   Thomas suggested, that this should be possible by now and would make
   things a whole lot cleaner.  If we really get it into 2.3 will depend
   on the afford it would really take, but we should keep it in mind in
   any case!

-  Experimental Dovecot Support

   Well, about a year ago I committed some basic support for Dovecot as
   an IMAP back end to the cvs.  It basically works for simple setups
   (Bernhard Herzog and I did bunch of work on the Dovecot side too,
   which is already part of the current dovecot releases) and the next
   step is to make it install- and configurable with limited manual
   afford.

   This is medium priority work, but it is long time pending and really
   should happen for 2.3 -- most likely it will get an "experimental"
   status.

As always input and support on this topics is highly welcome..!

cheers
sascha

[1]  Standard disclaimer: unless something really unexpected and bad
     happens and keeps us from implementing this promised new feature.
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100216/ad0bf820/attachment.bin

From ml at radoeka.nl  Tue Feb 16 20:36:15 2010
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 16 Feb 2010 20:36:15 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002152220.21545.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002131404.28885.ml@radoeka.nl>
	<201002152220.21545.thomas@btspuhler.com>
Message-ID: <201002162036.15904.ml@radoeka.nl>

Op dinsdag 16 februari 2010 06:20:21 schreef Thomas Spuhler:
> > Of course.  Just add the channel with an rpm
> > See
> > http://download.opensuse.org/repositories/server:/php:/applications/openS
> >US E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> > or
> > http://download.opensuse.org/repositories/server:/php:/applications/openS
> >US E_11.2/src/ (look for rpms with channel in their name) and the rest of
> > the internet for other examples.
> 
> It seems this php-pear-channel package is the problem for not building the 
> other packages that depend on it.
> I have in the xml file: 
> pear.horde.org Horde PEAR Channel horde    
> http://pear.horde.org/Chiara_PEAR_Server_REST/ 
> http://pear.horde.org/Chiara_PEAR_Server_RESor should it be:
> 
> pear channel-discover pear.horde.org
> 
> is this correct?

The http line works.  Just try it in your browser, and see the result.
Have you tried to install the package your self, on your workstation e.g.?  
Does it work?

-- 
Richard


From ml at radoeka.nl  Tue Feb 16 21:06:37 2010
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 16 Feb 2010 21:06:37 +0100
Subject: [Kolab-devel] Kolab Server 2.3 Goals
In-Reply-To: <s7w1vglrsfe.fsf@intevation.de>
References: <s7w1vglrsfe.fsf@intevation.de>
Message-ID: <201002162106.37061.ml@radoeka.nl>

Op dinsdag 16 februari 2010 18:39:33 schreef Sascha Wilde:
> As always input and support on this topics is highly welcome..!

I would like to see issue3942 "Split httpd.conf.template in an kolab specific 
part and a main part" (https://issues.kolab.org/issue3942) be part of 
kolab-2.3 as well.  Would that be possible?
The patches are available they only need to be applied, and the spec file 
should be adapted accordingly.  Seems to be a job for Gunnar ;)  Perhaps we 
can schedule a slot to this, while be are both present in the IRC kolab 
channel?

-- 
Richard


From wilde at intevation.de  Wed Feb 17 15:54:30 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 17 Feb 2010 15:54:30 +0100
Subject: [Kolab-devel] Kolab Server 2.3 Goals
In-Reply-To: <201002162106.37061.ml@radoeka.nl> (Richard Bos's message of
	"Tue, 16 Feb 2010 21:06:37 +0100")
References: <s7w1vglrsfe.fsf@intevation.de> <201002162106.37061.ml@radoeka.nl>
Message-ID: <s7wbpfnc3q1.fsf@intevation.de>

Richard Bos <ml at radoeka.nl> writes:

> Op dinsdag 16 februari 2010 18:39:33 schreef Sascha Wilde:
>> As always input and support on this topics is highly welcome..!
>
> I would like to see issue3942 "Split httpd.conf.template in an kolab specific 
> part and a main part" (https://issues.kolab.org/issue3942) be part of 
> kolab-2.3 as well.  Would that be possible?
> The patches are available they only need to be applied, and the spec file 
> should be adapted accordingly.

Sounds reasonable to me.  Thomas?

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100217/c1c7e179/attachment.bin

From thomas at btspuhler.com  Thu Feb 18 05:29:58 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Wed, 17 Feb 2010 21:29:58 -0700
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002162036.15904.ml@radoeka.nl>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002152220.21545.thomas@btspuhler.com>
	<201002162036.15904.ml@radoeka.nl>
Message-ID: <201002172129.59356.thomas@btspuhler.com>

On Tuesday 16 February 2010 12:36:15 pm Richard Bos wrote:
> Op dinsdag 16 februari 2010 06:20:21 schreef Thomas Spuhler:
> > > Of course.  Just add the channel with an rpm
> > > See
> > > http://download.opensuse.org/repositories/server:/php:/applications/ope
> > >nS US E_11.2/src/php5- pear-channel-horde-1.0-1.1.src.rpm
> > > or
> > > http://download.opensuse.org/repositories/server:/php:/applications/ope
> > >nS US E_11.2/src/ (look for rpms with channel in their name) and the
> > > rest of the internet for other examples.
> >
> > It seems this php-pear-channel package is the problem for not building
> > the other packages that depend on it.
> > I have in the xml file:
> > pear.horde.org Horde PEAR Channel horde
> > http://pear.horde.org/Chiara_PEAR_Server_REST/
> > http://pear.horde.org/Chiara_PEAR_Server_RESor should it be:
> >
> > pear channel-discover pear.horde.org
> >
> > is this correct?
>
> The http line works.  Just try it in your browser, and see the result.
> Have you tried to install the package your self, on your workstation e.g.?
> Does it work?
Yes, it was very strange, a day later the same packages built and installed 
with the very same command.
Now I am running into a new hurdle, on my box and on the Mandriva build 
service:
$ rpm -ivh horde-form-0.0.2-1mdv2010.0.noarch.rpm
error: Failed dependencies:
        pear(Horde/UI/VarRenderer.php) is needed by horde-
form-0.0.2-1mdv2010.0.noarch


But rpm -ql horde gives
....
....
/usr/share/horde/lib/Horde/UI/VarRenderer.php
.....
....

and 
$ locate Horde/UI/VarRenderer.php
/usr/share/horde/lib/Horde/UI/VarRenderer.php
/usr/share/kolab/horde/Horde/UI/VarRenderer.php


I cannot even find where in horde-form this requirement comes from


-- 
Thomas


From ml at radoeka.nl  Thu Feb 18 08:46:20 2010
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 18 Feb 2010 08:46:20 +0100
Subject: [Kolab-devel] Kolab-2.2.3 filters
In-Reply-To: <201002172129.59356.thomas@btspuhler.com>
References: <201002102124.05829.thomas@btspuhler.com>
	<201002152220.21545.thomas@btspuhler.com>
	<201002162036.15904.ml@radoeka.nl>
	<201002172129.59356.thomas@btspuhler.com>
Message-ID: <20100218074620.GA14431@xs4all.nl>

On Wed, Feb 17, 2010 at 09:29:58PM -0700, Thomas Spuhler wrote:
> On Tuesday 16 February 2010 12:36:15 pm Richard Bos wrote:
> > The http line works.  Just try it in your browser, and see the result.
> > Have you tried to install the package your self, on your workstation e.g.?
> > Does it work?
> Yes, it was very strange, a day later the same packages built and installed 
> with the very same command.
> Now I am running into a new hurdle, on my box and on the Mandriva build 
> service:
> $ rpm -ivh horde-form-0.0.2-1mdv2010.0.noarch.rpm
> error: Failed dependencies:
>         pear(Horde/UI/VarRenderer.php) is needed by horde-
> form-0.0.2-1mdv2010.0.noarch
> 
> 
> But rpm -ql horde gives
> ....
> ....
> /usr/share/horde/lib/Horde/UI/VarRenderer.php
> .....
> ....
> 
> and 
> $ locate Horde/UI/VarRenderer.php
> /usr/share/horde/lib/Horde/UI/VarRenderer.php
> /usr/share/kolab/horde/Horde/UI/VarRenderer.php
> 
> 
> I cannot even find where in horde-form this requirement comes from

Probably an rpm script that looks for required dependencies.
It seems to be correct though:
$ rpm -ql horde-form
rpm -ql horde-form
/usr/share/php5/PEAR/Horde/Form.php
/usr/share/php5/PEAR/Horde/Form/Action.php
/usr/share/php5/PEAR/Horde/Form/Action/conditional_enable.php
/usr/share/php5/PEAR/Horde/Form/Action/conditional_setvalue.php
/usr/share/php5/PEAR/Horde/Form/Action/reload.php
/usr/share/php5/PEAR/Horde/Form/Action/submit.php
/usr/share/php5/PEAR/Horde/Form/Action/sum_fields.php
/usr/share/php5/PEAR/Horde/Form/Action/updatefield.php
/usr/share/php5/PEAR/Horde/Form/Renderer.php
/usr/share/php5/PEAR/Horde/Form/Type/tableset.php
/var/lib/pear/Horde_Form.xml

# grep VarRender $FILES
/usr/share/php5/PEAR/Horde/Form/Renderer.php:     *                           parameter to Horde_UI_VarRenderer::factory().
/usr/share/php5/PEAR/Horde/Form/Renderer.php:        require_once 'Horde/UI/VarRenderer.php';
/usr/share/php5/PEAR/Horde/Form/Renderer.php:        $this->_varRenderer = &Horde_UI_VarRenderer::factory($driver, $params);

$FILES contains the horde-form files, and there you have
the dependency...

-- 
RIchard


From wilde at intevation.de  Thu Feb 18 11:01:06 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Thu, 18 Feb 2010 11:01:06 +0100
Subject: [Kolab-devel] Future of the Webclient: lets take a
	modest	approach, dropping IMP and MIMP
In-Reply-To: <20100215204545.22621hwibjwuqa9w@webmail.pardus.de> (Gunnar
	Wrobel's message of "Mon, 15 Feb 2010 20:45:45 +0100")
References: <s7waava7m4t.fsf@intevation.de>
	<20100215204545.22621hwibjwuqa9w@webmail.pardus.de>
Message-ID: <s7wzl3650d9.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:
> Quoting Sascha Wilde <wilde at intevation.de>:
[Continue web client development for DIMP only]
>> What are the practical implications of this?
>> - We will remove the choice between IMP,DIMP and MIMP from the login
>>   screen of the web client.  DIMP will be used always.
>> - Problems with DIMP gain higher priority, as the alternative IMP will
>>   no longer be valid.[3]
>> - Problems with IMP, which don't exist in DIMP might not be fixed.
>> - Requested feature only have to be realized in DIMP, which makes them
>>   more likely to get realized.
>>
>> We hope that we get by this a better tested, more stable and less ugly
>> client until the time is ripe for greater changes.
>>
>> Any objections to this plan?  "Speak Now or Forever Hold Your Peace!"
>> ;-)
>
> While I don't have objections in general I'm still uncertain about the
> specific course of action.
>
> Right now it looks to me that we do not have a concrete
> "must-have"-list for dimp.

We will have one, once the resources are in place to realize a
development sprint.  Till then we will concentrate on continues work to
solve issues from the kolab tracker.  Concentration on dimp exclusively
will reduce testing and implementation efforts and help setting
priorities.

> And I assume there will be some overlaps with things that have already
> been completed in Horde 4 (e.g. support for PGP in Dimp).

After talking to Gunnar (who had a fresh look at the current development
status of horde 4) on this, we agreed that Horde 4 is no option when it
comes to short term improvements for the Kolab Web Client.

So I will readjust priorities for the web client related issues in the
tracker within the next days to reflect our decision.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100218/702653c9/attachment.bin

From issues at kolab.org  Thu Feb 18 11:05:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Feb 2010 10:05:06 +0000
Subject: [Kolab-devel] [issue4142] Composer: view all fields layout and
	small	problems(rt#6032)
In-Reply-To: <1266487506.18.0.200577680541.issue4142@kolab.org>
Message-ID: <1266487506.18.0.200577680541.issue4142@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Open the composer and select view all fields.
Four small problems:
1. German "Antwort an" should be renamed into: "Antwortadresse:"
2. To/CC/BCC fields are at the left side not in order
3. From and Reply-To fields are at the right side not in order.
4. Dictionary should also have a "Save" /(German) "Beibehalten" checkbox, which
works.

Please have a look at the screnshot.

Please estimate first.

----------
assignedto: allen
files: composer-problems-20100218.png
keyword: enterprise35, kde client, kkc
messages: 23637
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Composer: view all fields layout and small problems(rt#6032)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4142>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: composer-problems-20100218.png
Type: image/png
Size: 53484 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100218/f7dc83c4/composer-problems-20100218-0001.png

From issues at kolab.org  Thu Feb 18 11:23:39 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Feb 2010 10:23:39 +0000
Subject: [Kolab-devel] [issue4143] Calendar: Changing Workweek to day.
	(rt#6034)
In-Reply-To: <1266488619.22.0.520344547897.issue4143@kolab.org>
Message-ID: <1266488619.22.0.520344547897.issue4143@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. Switch to the calendar part.
2. View-> Workweek
3. Move to-> Move to today.
4. View-> day.
=> the first day of the workweek is seleted. But the user expects that today is
selected.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23639
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Calendar: Changing Workweek to day. (rt#6034)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4143>
______________________________________


From issues at kolab.org  Thu Feb 18 12:27:22 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Feb 2010 11:27:22 +0000
Subject: [Kolab-devel] [issue4144] Calendar: event with recurrence yearly :
	broken	translation
In-Reply-To: <1266492442.21.0.512102314184.issue4144@kolab.org>
Message-ID: <1266492442.21.0.512102314184.issue4144@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1
                        kde-i18n 20100212.1089099-kk1
Test:
German language used.
1. Start to create a new event.
2. Click on the recurrence button.
3. Set recurrence, yearly ((German)"J?hrlich"), Select a day-number. ((German)
   "Wiederholt an Tag Nr des Jahres")
4. Press okay.
=> The recurrence description field is "BROKEN TRANSLATION" and the text in
English. It should be German without "BROKEN TRANSLATION".

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23640
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Calendar: event with recurrence yearly : broken translation

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4144>
______________________________________


From issues at kolab.org  Thu Feb 18 12:31:57 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Feb 2010 11:31:57 +0000
Subject: [Kolab-devel] [issue4145] Calendar: month view/agenda view
	inconsistence with	events with recurrence.
In-Reply-To: <1266492717.22.0.322110399979.issue4145@kolab.org>
Message-ID: <1266492717.22.0.322110399979.issue4145@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. switch to the calendar in agenda view.
2. Create a new event today with recurrence(weekly, every week on a different
weekday)
3. Look at the agenda view today. 
=> event is not displayed.
4. Switch to month view.
=> The event is displayed at the creation date(today).
Slight inonsistence. I expect the event not to be displayed in the monthview at
the creation date.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23641
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Calendar: month view/agenda view inconsistence with events with recurrence.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4145>
______________________________________


From issues at kolab.org  Thu Feb 18 14:53:24 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Feb 2010 13:53:24 +0000
Subject: [Kolab-devel] [issue4146] Calendar: Events with recurrence : delete
	all future	recurrence.
In-Reply-To: <1266501204.08.0.20955268905.issue4146@kolab.org>
Message-ID: <1266501204.08.0.20955268905.issue4146@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. Create a test event with daily recurrence.
2. Delete the event with all future recurrences.
=> The event disappears from the current day.
3. Deactivate the calendar resource and reactivate it.
=> The event reappears.
I expect the event to stay deleted.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23642
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Calendar: Events with recurrence : delete all future recurrence.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4146>
______________________________________


From issues at kolab.org  Fri Feb 19 12:34:00 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 19 Feb 2010 11:34:00 +0000
Subject: [Kolab-devel] [issue4147] Event/Task conflict dialog "Take Both"
	should be	default(rt#6009)
In-Reply-To: <1266579240.47.0.688009259484.issue4147@kolab.org>
Message-ID: <1266579240.47.0.688009259484.issue4147@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Related to kolab/issue4112:

In the event/task conflict dialog the option "Use Both" should be 
preselected/default. (instead of "Use local entry")

kkc and important.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23658
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: Event/Task conflict dialog "Take Both" should be default(rt#6009)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4147>
______________________________________


From issues at kolab.org  Fri Feb 19 15:04:43 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 19 Feb 2010 14:04:43 +0000
Subject: [Kolab-devel] [issue4148] New event,
	attendee dialog: entry with comma format should stay in comma
	format	in the attendee pane. (rt#6035)
In-Reply-To: <1266588283.76.0.756122774153.issue4148@kolab.org>
Message-ID: <1266588283.76.0.756122774153.issue4148@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. Start to create a new event.
2. Switch to the attendee tab.
3. Enter a attendee entry:
Testy, Test <testy at xxx>
or:
"Testy, Test" <test at yyy>
=>Both are displayed in the attendee pane like:
Test Testy <testy at xxx>

The customer dislikes this, he wants that the name is displayed the way it is
entered. (The format of the name should not change.)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23661
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: New event, attendee dialog: entry with comma format should stay in comma format in the attendee pane. (rt#6035)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4148>
______________________________________


From issues at kolab.org  Fri Feb 19 15:28:44 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 19 Feb 2010 14:28:44 +0000
Subject: [Kolab-devel] [issue4149] Search Directory Services and
	comma-formated	names(rt#5954)
In-Reply-To: <1266589724.83.0.0066225495211.issue4149@kolab.org>
Message-ID: <1266589724.83.0.0066225495211.issue4149@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. Sync in the mail part.
2. Open Properties of a folder.
3. Access Control tab->Add->...
=> the Address Selecion dialog pops up.
4. Click on "Search Directory Services".
5. Add selected on an entry with "last_name, first_name <mailaddress>"
=> in the Address Selection dialog this entry is only displayed:
firstname <mailaddress>
The user expect, that the name is here also displayed like 
"last_name, first_name <mailaddresse>" in this case.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23663
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Search Directory Services and comma-formated names(rt#5954)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4149>
______________________________________


From issues at kolab.org  Fri Feb 19 17:36:34 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Fri, 19 Feb 2010 16:36:34 +0000
Subject: [Kolab-devel] [issue4150] Kleopatra crashes if sign/encrypt a file
In-Reply-To: <1266597394.57.0.563597482756.issue4150@kolab.org>
Message-ID: <1266597394.57.0.563597482756.issue4150@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleopatra 2.0.14-svn1092065 (Windows) with gpg4win:

1. Test: GpgEX
- Kleopatra isn't startet
- try to sign/enc file with gpgex (right mouse click)
-> Kleopatra starts (in systray), but no dialog (mainwindow, file crypto) comes up.
-> GpgEX shows error dialog "internal error"

2. Test: Sign/enc file with Kleoaptra only
- use menu file -> sign/enc
- select a file
-> Kleopatra crashs

kleo log attached for both tests.

----------
assignedto: marc
files: kleo-log_sig-enc-file.txt
keyword: gpg4win2, kleo
messages: 23666
nosy: emanuel, marc
priority: urgent
status: unread
title: Kleopatra crashes if sign/encrypt a file

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4150>
______________________________________
-------------- next part --------------
Startup timing: 344 ms elapsed: Application created 
Startup timing: 375 ms elapsed: UiServer created 
Startup timing: 391 ms elapsed: UiServer started 
UiServer: client connect on fd 3468
[1880.3468] DBG: -> OK GPG UI server (Kleopatra/2.0.14-svn1092065 (2010-02-18)) ready to serve
UiServer: client connection 0149D880 established successfully
UiServer: client connect on fd 3412
[1880.3412] DBG: -> OK GPG UI server (Kleopatra/2.0.14-svn1092065 (2010-02-18)) ready to serve
UiServer: client connection 01199938 established successfully
[1880.3468] DBG: <- GETINFO pid
[1880.3468] DBG: -> D 1880
[1880.3468] DBG: -> OK
[1880.3468] DBG: <- OPTION window-id=10086
[1880.3468] DBG: -> OK
[1880.3468] DBG: <- [Error: Resource temporarily unavailable]
[1880.3412] DBG: <- GETINFO pid
[1880.3412] DBG: -> D 1880
[1880.3412] DBG: -> OK
Server PID = 1880 
[1880.3412] DBG: <- BYE
[1880.3412] DBG: -> OK closing connection
UiServer: connection 01199938 closed
[1880.3468] DBG: <- FILE C%3a\Dokumente%20und%20Einstellungen\admin\Desktop\Neu%20Textdokument.txt
[1880.3468] DBG: -> OK
[1880.3468] DBG: <- ENCRYPT_SIGN_FILES --nohup
[1880.3468] DBG: <- [Error: Resource temporarily unavailable]
Startup timing: 1313 ms elapsed: SelfCheck completed 
ReaderStatusThread[2nd]: new iteration command= "__update__"  ; nullSlot= true 
<update_cardinfo> 
get_card_status( "C:/Dokumente und Einstellungen/admin/Anwendungsdaten/gnupg/reader_0.status" , 0 , 0x11ab678 ) 
gpgagent_transact( SCD SERIALNO ) 
gpgagent_transact( SCD GETATTR APPTYPE ) 
scd_getattr_status( APPTYPE ): got ( status( "APPTYPE" ) = "NKS" 
) 
parse_app_type( NKS ) 
static_cast<ReaderStatus::AppType>( it - begin( app_types ) ) 2 
gpgagent_transact( SCD GETATTR NKS-VERSION ) 
scd_getattr_status( NKS-VERSION ): got ( status( "NKS-VERSION" ) = "3" 
) 
gpgagent_transact( SCD GETATTR CHV-STATUS ) 
Startup timing: 2359 ms elapsed: KeyCache loaded 
ArchiveDefinition[ "tar" ] ("tar", "cf", "-") 
AssuanCommand::done(): Error:  "Unbekannte Ausnahme aufgetreten: Fehler muss in Anwendung behoben werden." 
[1880.3468] DBG: -> ERR 218103871 Interner Fehler <Kleopatra> - Unbekannte Ausnahme aufgetreten: Fehler muss in Anwendung behoben werden.
[1880.3468] DBG: <- BYE
[1880.3468] DBG: -> OK closing connection
UiServer: connection 0149D880 closed
scd_getattr_status( CHV-STATUS ): got ( status( "CHV-STATUS" ) = "3 0 3 0" 
) 
gpgagent_transact( SCD LEARN --keypairinfo ) 
parse_keypairinfo_and_lookup_key: pattern= &A34AC4E4D7D360A689545375F30DE95BB7FC2E3E 
QFileSystemWatcher: failed to add paths: C:/Dokumente und Einstellungen/admin/Anwendungsdaten/gnupg/pubring.k__
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &16D832C20863EA148C28DD2D830C01F22F8A7F17 
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &3705E0F1A44804A93550523B7B6318E1959DDEBE 
KeyFilterManager::reload: final filter count is 12
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &41F1126045BFE90CA6E33922E4E6D0051F122EF2 
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
get_card_status: ci.status  CardUsable 
</update_cardinfo> 
ReaderStatusThread[2nd]: slot 0 : NoCard -> CardUsable 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "70 4 66" 
) 
ReaderStatusThread[2nd]: .zZZ
QFileSystemWatcher: failed to add paths: C:/Dokumente und Einstellungen/admin/Anwendungsdaten/gnupg/pubring.k__
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "70 4 66" 
) 
ReaderStatusThread[2nd]: .zZZ
KeyListController::registerCommand( 015887A0 )
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "70 4 66" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "70 4 66" 
) 
ReaderStatusThread[2nd]: .zZZ
ArchiveDefinition[ "tar" ] ("tar", "cf", "-") 
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "70 4 66" 
) 
ReaderStatusThread[2nd]: .zZZ

From issues at kolab.org  Fri Feb 19 18:37:04 2010
From: issues at kolab.org (Marc Mutz)
Date: Fri, 19 Feb 2010 17:37:04 +0000
Subject: [Kolab-devel] [issue4151] pinentry-qt4: icon doesn't work with Qt
	4.5.3 from Debian	Sid.
In-Reply-To: <1266601024.11.0.459610707584.issue4151@kolab.org>
Message-ID: <1266601024.11.0.459610707584.issue4151@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

Works for Marc with self-compiled Qt 4.4.3, 4.5.2, 4.6.1 (Etch, amd64).
Works for Werner with 4.4.3, fails with Debian Qt 4.5.3 (Sid).

Not critical as it works with the version from gpg4win2.

----------
assignedto: marc
keyword: enterprise4, gpg4win2
messages: 23668
nosy: emanuel, marc
priority: minor bug
status: unread
title: pinentry-qt4: icon doesn't work with Qt 4.5.3 from Debian Sid.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4151>
______________________________________


From issues at kolab.org  Sun Feb 21 05:36:31 2010
From: issues at kolab.org (Gunnar Wrobel)
Date: Sun, 21 Feb 2010 04:36:31 +0000
Subject: [Kolab-devel] [issue4152] Turba: Autocompletion sometimes failes
In-Reply-To: <1266726991.55.0.223209502711.issue4152@kolab.org>
Message-ID: <1266726991.55.0.223209502711.issue4152@kolab.org>


New submission from Gunnar Wrobel <p at rdus.de>:

>From the mailing list
(http://kolab.org/pipermail/kolab-users/2010-February/010963.html)

On Mon, 15 Feb 2010, Gavin McCullagh wrote:
So, I'm assuming this is something local for me at the minute but another
possibility is a regression in v2.2.3 which breaks the autocompleter.  I'll
try and track it down but thought I'd mention this in case it rings a bell
for someone else.
That assumption has been borne out in that by removing my .prefs file from
/kolab/var/kolab/www/client/storage/ and letting it recreate, this was
fixed.  I had tracked this down in the code to the global address book not
being in the list of address books to consult.

What's strange is that the same thing seems to have happened to every other
user (of which there are 6-8 test users).  The first time they login, their
preferences get automatically set in such a way that the global address
book is not being consulted.  Then, if I delete the prefs file and they
login again, the global addressbook is set right.  This is pretty odd.
Again, it might be a bug, or it might be a local issue.

Gavin

----------
assignedto: wrobel
keyword: web client
messages: 23675
nosy: bernhard, martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Turba: Autocompletion sometimes failes

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4152>
______________________________________


From wrobel at pardus.de  Sun Feb 21 14:15:11 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sun, 21 Feb 2010 14:15:11 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <001b01caaf2e$5ffbbbd0$1ff33370$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch>
	<20100215100000.59382tahnkzoqk9c@webmail.pardus.de>
	<001b01caaf2e$5ffbbbd0$1ff33370$@ch>
Message-ID: <20100221141511.16204oxc0nmucpic@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> No problem can give a try...give me a hint as soon as the patch is
> available....

Here it is: http://kolab.org/pipermail/kolab-commits/2010q1/011956.html

Cheers,

Gunnar

>
> Kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Montag, 15. Februar 2010 10:00
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Hi Andrea,
>
> actually the error you see is probably a side effect of the bug I
> introduced with the fix for https://issues.kolab.org/issue3499. I'll
> try to provide a patch for that today. Please add yourself in nosy
> there. Would be great if you could provide feedback if that works.
>
> Cheers,
>
> Gunnar
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi Gunnar
>>
>> Sorry was in holidays for a fiew days :-)
>>
>> I tried to include your suggested stuff "var_dump($base);" in the Code of:
>>
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>>
>> But as a pity without success....I'm not so familar with php :-( can you
>> please advice how you would include it.
>>
>> Regarding your suggstion what the symptomes are if this error occurs
>> following:
>>
>> The error occures "ONLY" if a user is added or modified within the manager
>> interface. It happens also if a Distribution List ist added or modified.
> For
>> the manager itself which add's or modifies the users or distribution list
> on
>> the manager interface nothing occured meanining I added over 20 domains
> with
>> 50 email address's and aliases but I never was kicked out or saw a blank
>> white page or a error from php or whatever. I'm using kolab since years
> and
>> this never occoured but I have to say what I did this time was to add a
>> Domain Maintainer which I never used before...could this be the reason? If
> I
>> looked in as the Domain Maintainer and added a user I had some kick outs
> and
>> blank white pages? I have a strange feeling about this function but that
> we
>> have no misunderstandig at all as Kolab Manager I had never blank pages or
>> uncontrolled kicke outs.
>>
>> If you could advice where to add the code etc. I can follow up on this....
>>
>> PS: One more thing which you are probably interessted....I did in rc.conf
>> template a modification....this means in the past for config the entry in
>> this file was:
>>
>> openldap_url="ldap:// ldaps://"
>>
>> This was working fine without any problems...in the newewst version the
>> entry is:
>>
>> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>>
>> This was given errors and a lot of problems because the real entry in the
>> /kolab/etc/rc.conf was looking:
>>
>> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>>
>> This does not work and I changed to 127.0.0.1 or back to the old style.
> Both
>> is working fine:
>>
>> openldap_url="ldap:// ldaps://"
>>
>> I do not think so that this has something to do with the issue which we
> are
>> discussion here even I do not understand the
> "openldap_url="ldap://0.0.0.0/
>> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
> the
>> bind_addr did not work as expected because I'm using Kolab in a Solaris
> Zone
>> and the localhost as the 127.0.0.1 is handled in some circumstances in
>> another way.....this only for your information. I documented the overall
>> stuff on the Wiki:
>>
>> https://wiki.kolab.org/index.php/Solaris
>>
>>
>> Kind regards
>>
>> Andrea
>>
>> Mail: soliva at comcept.ch
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Donnerstag, 11. Februar 2010 22:10
>> An: kolab-devel at kolab.org
>> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Hi Andrea,
>>
>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>
>>> Hi
>>>
>>> It is from my point of view clear the search function but even I see the
>>> lines I can not identify what is false and why?:
>>>
>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>> 204
>>>
>>>
>>> 201    function search( $base, $filter, $attrs = false ) {
>>>    202      $this->freeSearchResult();
>>>    203      if( $attrs ) {
>>>    204            $this->search_result = ldap_search( $this->connection,
>>> $base, $filter, $attrs );
>>>    205          } else {
>>>    206            $this->search_result = ldap_search( $this->connection,
>>> $base, $filter );
>>>    207          }
>>>    208      return $this->search_result;
>>>    209    }
>>
>> The error sounds as if $base contains an invalid value. You could add
>> a "var_dump($base);" in the code to display the value.
>>
>> Both log entries you mentioned are just warnings though. The code
>> won't stop on a warning. And the code of the web admin is not exactly
>> clean when it comes to notices and warnings. Quite the contrary. So
>> what you see might not be a real problem.
>>
>> But I did not quite understand what kind of problems you saw in the
>> actual frontend. Did you see any specific errors that were displayed?
>> Or did the web admin just show you a blank page (the PHP white screen
>> of death)?
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>>
>>> is not a valid ldap result resource in
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>
>>>    411    // Count the number of occurences of an email address
>>>    412    // in users' mail and alias attributes and in dist. lists.
>>>    413    // This can be used to check for uniqueness etc.
>>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>>    415          // First count users
>>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>>    417                         (alias='.$this->escape($mail).')
>>>    418                       )
>>>    419                       (uid='.$this->escape($mail).')
>>>    420                     )';
>>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>>> array( 'dn' ) );
>>>    422          $count = 0;
>>>    423
>>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>>    425          if( $excludedn ) {
>>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>>    427                  if( is_null( $entries[$i] ) ) continue;
>>>    428                  if(
>> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>>    429                  debug("found ".$entries[$i]['dn'] );
>>>    430                  $count++;
>>>    431            }
>>>    432          } else $count += $entries['count'];
>>>
>>>
>>> Kind regards
>>>
>>> Andrea Soliva
>>>
>>> Mail: soliva at comcept.ch
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>>> kolab-devel-bounces at kolab.org
>>> Gesendet: Montag, 25. Januar 2010 14:37
>>> An: kolab-devel at kolab.org
>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>>
>>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
> DN
>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>> 204
>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
>> argument
>>>> is not a valid ldap result resource in
>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>
>>>> Is this already recognized? Is it not known....I tried to figure out
> what
>>>> is wrong but actually I could not?!
>>>>
>>>> Any suggestion?
>>>
>>> My suggestion is to check the given line 204 and see which argument
>>> is used there (maybe add a statement to print it out).
>>>
>>>> By the way is there a documentation about Master/Slave configuration
>>>> meaning how this works etc. I could not find anything. Any hints would
> be
>>>> appriciated.
>>>
>>> I think the documentation is in the architecture documents.
>>> The idea is pretty simple: Replicate the directory server on the slave
>>> (for which there is a bootstrap) have all read access on the slave
>> accounts
>>> go
>>> to the slave LDAP server and all write access (only by webadmin) to the
>>> master.
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>
>>
>>
>> --
>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>
>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>> --------------------------------------------------------------------
>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>> --------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>> _______________________________________________
>> 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 <<
> --------------------------------------------------------------------
>
> _______________________________________________
> 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/20100221/a1e9d7b9/attachment.bin

From soliva at comcept.ch  Sun Feb 21 15:33:35 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Sun, 21 Feb 2010 15:33:35 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <20100221141511.16204oxc0nmucpic@webmail.pardus.de>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch><20100215100000.59382tahnkzoqk9c@webmail.pardus.de><001b01caaf2e$5ffbbbd0$1ff33370$@ch>
	<20100221141511.16204oxc0nmucpic@webmail.pardus.de>
Message-ID: <000001cab302$da1eab70$8e5c0250$@ch>

Hi Gunnar

Man thanks fort he hint and I modified the file as in your patch shown:

        --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
---------------
        
        
           411    // Count the number of occurences of an email address
           412    // in users' mail and alias attributes and in dist. lists.
           413    // This can be used to check for uniqueness etc.
           412    // in users' mail and alias attributes and in dist. lists.
           413    // This can be used to check for uniqueness etc.
           414    function countMail( $base, $mail , $excludedn=false ) {
           415          // First count users
           416          $filter = '(|(|(mail='.$this->escape($mail).')
           417                         (alias='.$this->escape($mail).')
           418                       )
           419                       (uid='.$this->escape($mail).')
           420                     )';
           421  //      $res = $this->search( $this->dn_escape($base),
$filter, array( 'dn' ) );
           422          $res = $this->search( $base, $filter, array( 'dn' )
);
           423          $count = 0;
           424
           425          $entries = ldap_get_entries( $this->connection, $res
);
           426          if( $excludedn ) {
           427            for ( $i = 0; $i < count( $entries ); $i++ ) {
           428  //              if( is_null( $entries[$i] ) ) continue;
           429                  if( !isset($entries[$i]) || is_null(
$entries[$i] ) ) continue;
           430                  if(
KolabLDAP::unescape_dn_value($entries[$i]['dn']) ==
KolabLDAP::unescape_dn_value($excludedn) ) continue;
           431                  debug("found ".$entries[$i]['dn'] );
           432                  $count++;
        
        --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
---------------

After that I created a new user, modified as deleted the user without any
warnings etc. in the log /kolab/var/apache/log/php/php-errors.log. From this
point it seems the warning are gone. I saw somewhere also in the devel
messages (can not remember anymore) that without this patch it is possible
to configure a mail alias to two different uid's (users)?
Right....?.....after the patch this is not possible meaning a warning is
shown/poping up that this alias is already set to another uid/user etc.

As mentioned I did not find anything else after the patch was applied
meaning warnings, errros etc. even I manipulated the new user I created for
the test in different ways. Hope this helps and if you need more tests or
wathever give me a hint.

Many thnks and kind regards

Andrea Soliva

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Sonntag, 21. Februar 2010 14:15
An: kolab-devel at kolab.org
Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> No problem can give a try...give me a hint as soon as the patch is
> available....

Here it is: http://kolab.org/pipermail/kolab-commits/2010q1/011956.html

Cheers,

Gunnar

>
> Kind regards
>
> Andrea
>
> Mail: soliva at comcept.ch
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Montag, 15. Februar 2010 10:00
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Hi Andrea,
>
> actually the error you see is probably a side effect of the bug I
> introduced with the fix for https://issues.kolab.org/issue3499. I'll
> try to provide a patch for that today. Please add yourself in nosy
> there. Would be great if you could provide feedback if that works.
>
> Cheers,
>
> Gunnar
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi Gunnar
>>
>> Sorry was in holidays for a fiew days :-)
>>
>> I tried to include your suggested stuff "var_dump($base);" in the Code
of:
>>
>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>>
>> But as a pity without success....I'm not so familar with php :-( can you
>> please advice how you would include it.
>>
>> Regarding your suggstion what the symptomes are if this error occurs
>> following:
>>
>> The error occures "ONLY" if a user is added or modified within the
manager
>> interface. It happens also if a Distribution List ist added or modified.
> For
>> the manager itself which add's or modifies the users or distribution list
> on
>> the manager interface nothing occured meanining I added over 20 domains
> with
>> 50 email address's and aliases but I never was kicked out or saw a blank
>> white page or a error from php or whatever. I'm using kolab since years
> and
>> this never occoured but I have to say what I did this time was to add a
>> Domain Maintainer which I never used before...could this be the reason?
If
> I
>> looked in as the Domain Maintainer and added a user I had some kick outs
> and
>> blank white pages? I have a strange feeling about this function but that
> we
>> have no misunderstandig at all as Kolab Manager I had never blank pages
or
>> uncontrolled kicke outs.
>>
>> If you could advice where to add the code etc. I can follow up on
this....
>>
>> PS: One more thing which you are probably interessted....I did in rc.conf
>> template a modification....this means in the past for config the entry in
>> this file was:
>>
>> openldap_url="ldap:// ldaps://"
>>
>> This was working fine without any problems...in the newewst version the
>> entry is:
>>
>> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>>
>> This was given errors and a lot of problems because the real entry in the
>> /kolab/etc/rc.conf was looking:
>>
>> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>>
>> This does not work and I changed to 127.0.0.1 or back to the old style.
> Both
>> is working fine:
>>
>> openldap_url="ldap:// ldaps://"
>>
>> I do not think so that this has something to do with the issue which we
> are
>> discussion here even I do not understand the
> "openldap_url="ldap://0.0.0.0/
>> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
> the
>> bind_addr did not work as expected because I'm using Kolab in a Solaris
> Zone
>> and the localhost as the 127.0.0.1 is handled in some circumstances in
>> another way.....this only for your information. I documented the overall
>> stuff on the Wiki:
>>
>> https://wiki.kolab.org/index.php/Solaris
>>
>>
>> Kind regards
>>
>> Andrea
>>
>> Mail: soliva at comcept.ch
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Donnerstag, 11. Februar 2010 22:10
>> An: kolab-devel at kolab.org
>> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Hi Andrea,
>>
>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>
>>> Hi
>>>
>>> It is from my point of view clear the search function but even I see the
>>> lines I can not identify what is false and why?:
>>>
>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>> 204
>>>
>>>
>>> 201    function search( $base, $filter, $attrs = false ) {
>>>    202      $this->freeSearchResult();
>>>    203      if( $attrs ) {
>>>    204            $this->search_result = ldap_search( $this->connection,
>>> $base, $filter, $attrs );
>>>    205          } else {
>>>    206            $this->search_result = ldap_search( $this->connection,
>>> $base, $filter );
>>>    207          }
>>>    208      return $this->search_result;
>>>    209    }
>>
>> The error sounds as if $base contains an invalid value. You could add
>> a "var_dump($base);" in the code to display the value.
>>
>> Both log entries you mentioned are just warnings though. The code
>> won't stop on a warning. And the code of the web admin is not exactly
>> clean when it comes to notices and warnings. Quite the contrary. So
>> what you see might not be a real problem.
>>
>> But I did not quite understand what kind of problems you saw in the
>> actual frontend. Did you see any specific errors that were displayed?
>> Or did the web admin just show you a blank page (the PHP white screen
>> of death)?
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>>
>>> is not a valid ldap result resource in
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>
>>>    411    // Count the number of occurences of an email address
>>>    412    // in users' mail and alias attributes and in dist. lists.
>>>    413    // This can be used to check for uniqueness etc.
>>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>>    415          // First count users
>>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>>    417                         (alias='.$this->escape($mail).')
>>>    418                       )
>>>    419                       (uid='.$this->escape($mail).')
>>>    420                     )';
>>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>>> array( 'dn' ) );
>>>    422          $count = 0;
>>>    423
>>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>>    425          if( $excludedn ) {
>>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>>    427                  if( is_null( $entries[$i] ) ) continue;
>>>    428                  if(
>> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>>    429                  debug("found ".$entries[$i]['dn'] );
>>>    430                  $count++;
>>>    431            }
>>>    432          } else $count += $entries['count'];
>>>
>>>
>>> Kind regards
>>>
>>> Andrea Soliva
>>>
>>> Mail: soliva at comcept.ch
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>>> kolab-devel-bounces at kolab.org
>>> Gesendet: Montag, 25. Januar 2010 14:37
>>> An: kolab-devel at kolab.org
>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax
function.ldap-search
>>>
>>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
> DN
>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>> 204
>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
>> argument
>>>> is not a valid ldap result resource in
>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>
>>>> Is this already recognized? Is it not known....I tried to figure out
> what
>>>> is wrong but actually I could not?!
>>>>
>>>> Any suggestion?
>>>
>>> My suggestion is to check the given line 204 and see which argument
>>> is used there (maybe add a statement to print it out).
>>>
>>>> By the way is there a documentation about Master/Slave configuration
>>>> meaning how this works etc. I could not find anything. Any hints would
> be
>>>> appriciated.
>>>
>>> I think the documentation is in the architecture documents.
>>> The idea is pretty simple: Replicate the directory server on the slave
>>> (for which there is a bootstrap) have all read access on the slave
>> accounts
>>> go
>>> to the slave LDAP server and all write access (only by webadmin) to the
>>> master.
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>
>>
>>
>> --
>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>
>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>> --------------------------------------------------------------------
>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>> --------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>> _______________________________________________
>> 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 <<
> --------------------------------------------------------------------
>
> _______________________________________________
> 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 <<
--------------------------------------------------------------------


From wrobel at pardus.de  Sun Feb 21 21:31:27 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sun, 21 Feb 2010 21:31:27 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <000001cab302$da1eab70$8e5c0250$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch><20100215100000.59382tahnkzoqk9c@webmail.pardus.de><001b01caaf2e$5ffbbbd0$1ff33370$@ch>
	<20100221141511.16204oxc0nmucpic@webmail.pardus.de>
	<000001cab302$da1eab70$8e5c0250$@ch>
Message-ID: <20100221213127.13847dslqpb1et4w@webmail.pardus.de>

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> Man thanks fort he hint and I modified the file as in your patch shown:
>
>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
> ---------------
>
>
>            411    // Count the number of occurences of an email address
>            412    // in users' mail and alias attributes and in dist. lists.
>            413    // This can be used to check for uniqueness etc.
>            412    // in users' mail and alias attributes and in dist. lists.
>            413    // This can be used to check for uniqueness etc.
>            414    function countMail( $base, $mail , $excludedn=false ) {
>            415          // First count users
>            416          $filter = '(|(|(mail='.$this->escape($mail).')
>            417                         (alias='.$this->escape($mail).')
>            418                       )
>            419                       (uid='.$this->escape($mail).')
>            420                     )';
>            421  //      $res = $this->search( $this->dn_escape($base),
> $filter, array( 'dn' ) );
>            422          $res = $this->search( $base, $filter, array( 'dn' )
> );
>            423          $count = 0;
>            424
>            425          $entries = ldap_get_entries( $this->connection, $res
> );
>            426          if( $excludedn ) {
>            427            for ( $i = 0; $i < count( $entries ); $i++ ) {
>            428  //              if( is_null( $entries[$i] ) ) continue;
>            429                  if( !isset($entries[$i]) || is_null(
> $entries[$i] ) ) continue;
>            430                  if(
> KolabLDAP::unescape_dn_value($entries[$i]['dn']) ==
> KolabLDAP::unescape_dn_value($excludedn) ) continue;
>            431                  debug("found ".$entries[$i]['dn'] );
>            432                  $count++;
>
>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
> ---------------
>
> After that I created a new user, modified as deleted the user without any
> warnings etc. in the log /kolab/var/apache/log/php/php-errors.log. From this
> point it seems the warning are gone. I saw somewhere also in the devel
> messages (can not remember anymore) that without this patch it is possible
> to configure a mail alias to two different uid's (users)?
> Right....?

Correct.

> .....after the patch this is not possible meaning a warning is
> shown/poping up that this alias is already set to another uid/user etc.

Nice. Many thanks for the feedback!

>
> As mentioned I did not find anything else after the patch was applied
> meaning warnings, errros etc. even I manipulated the new user I created for
> the test in different ways. Hope this helps and if you need more tests or
> wathever give me a hint.

If you want, you can check if creating users that contain a "," or a  
"=" in the first or last name works as well.

That was what the original patch was actually about. Breaking the  
countMail() function was an undesired side effect.

Cheers,

Gunnar

>
> Many thnks and kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Sonntag, 21. Februar 2010 14:15
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi Gunnar
>>
>> No problem can give a try...give me a hint as soon as the patch is
>> available....
>
> Here it is: http://kolab.org/pipermail/kolab-commits/2010q1/011956.html
>
> Cheers,
>
> Gunnar
>
>>
>> Kind regards
>>
>> Andrea
>>
>> Mail: soliva at comcept.ch
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Montag, 15. Februar 2010 10:00
>> An: kolab-devel at kolab.org
>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Hi Andrea,
>>
>> actually the error you see is probably a side effect of the bug I
>> introduced with the fix for https://issues.kolab.org/issue3499. I'll
>> try to provide a patch for that today. Please add yourself in nosy
>> there. Would be great if you could provide feedback if that works.
>>
>> Cheers,
>>
>> Gunnar
>>
>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>
>>> Hi Gunnar
>>>
>>> Sorry was in holidays for a fiew days :-)
>>>
>>> I tried to include your suggested stuff "var_dump($base);" in the Code
> of:
>>>
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>>>
>>> But as a pity without success....I'm not so familar with php :-( can you
>>> please advice how you would include it.
>>>
>>> Regarding your suggstion what the symptomes are if this error occurs
>>> following:
>>>
>>> The error occures "ONLY" if a user is added or modified within the
> manager
>>> interface. It happens also if a Distribution List ist added or modified.
>> For
>>> the manager itself which add's or modifies the users or distribution list
>> on
>>> the manager interface nothing occured meanining I added over 20 domains
>> with
>>> 50 email address's and aliases but I never was kicked out or saw a blank
>>> white page or a error from php or whatever. I'm using kolab since years
>> and
>>> this never occoured but I have to say what I did this time was to add a
>>> Domain Maintainer which I never used before...could this be the reason?
> If
>> I
>>> looked in as the Domain Maintainer and added a user I had some kick outs
>> and
>>> blank white pages? I have a strange feeling about this function but that
>> we
>>> have no misunderstandig at all as Kolab Manager I had never blank pages
> or
>>> uncontrolled kicke outs.
>>>
>>> If you could advice where to add the code etc. I can follow up on
> this....
>>>
>>> PS: One more thing which you are probably interessted....I did in rc.conf
>>> template a modification....this means in the past for config the entry in
>>> this file was:
>>>
>>> openldap_url="ldap:// ldaps://"
>>>
>>> This was working fine without any problems...in the newewst version the
>>> entry is:
>>>
>>> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>>>
>>> This was given errors and a lot of problems because the real entry in the
>>> /kolab/etc/rc.conf was looking:
>>>
>>> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>>>
>>> This does not work and I changed to 127.0.0.1 or back to the old style.
>> Both
>>> is working fine:
>>>
>>> openldap_url="ldap:// ldaps://"
>>>
>>> I do not think so that this has something to do with the issue which we
>> are
>>> discussion here even I do not understand the
>> "openldap_url="ldap://0.0.0.0/
>>> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
>> the
>>> bind_addr did not work as expected because I'm using Kolab in a Solaris
>> Zone
>>> and the localhost as the 127.0.0.1 is handled in some circumstances in
>>> another way.....this only for your information. I documented the overall
>>> stuff on the Wiki:
>>>
>>> https://wiki.kolab.org/index.php/Solaris
>>>
>>>
>>> Kind regards
>>>
>>> Andrea
>>>
>>> Mail: soliva at comcept.ch
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>>> kolab-devel-bounces at kolab.org
>>> Gesendet: Donnerstag, 11. Februar 2010 22:10
>>> An: kolab-devel at kolab.org
>>> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>>
>>> Hi Andrea,
>>>
>>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>>
>>>> Hi
>>>>
>>>> It is from my point of view clear the search function but even I see the
>>>> lines I can not identify what is false and why?:
>>>>
>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>> 204
>>>>
>>>>
>>>> 201    function search( $base, $filter, $attrs = false ) {
>>>>    202      $this->freeSearchResult();
>>>>    203      if( $attrs ) {
>>>>    204            $this->search_result = ldap_search( $this->connection,
>>>> $base, $filter, $attrs );
>>>>    205          } else {
>>>>    206            $this->search_result = ldap_search( $this->connection,
>>>> $base, $filter );
>>>>    207          }
>>>>    208      return $this->search_result;
>>>>    209    }
>>>
>>> The error sounds as if $base contains an invalid value. You could add
>>> a "var_dump($base);" in the code to display the value.
>>>
>>> Both log entries you mentioned are just warnings though. The code
>>> won't stop on a warning. And the code of the web admin is not exactly
>>> clean when it comes to notices and warnings. Quite the contrary. So
>>> what you see might not be a real problem.
>>>
>>> But I did not quite understand what kind of problems you saw in the
>>> actual frontend. Did you see any specific errors that were displayed?
>>> Or did the web admin just show you a blank page (the PHP white screen
>>> of death)?
>>>
>>> Cheers,
>>>
>>> Gunnar
>>>
>>>>
>>>>
>>>> is not a valid ldap result resource in
>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>
>>>>    411    // Count the number of occurences of an email address
>>>>    412    // in users' mail and alias attributes and in dist. lists.
>>>>    413    // This can be used to check for uniqueness etc.
>>>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>>>    415          // First count users
>>>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>>>    417                         (alias='.$this->escape($mail).')
>>>>    418                       )
>>>>    419                       (uid='.$this->escape($mail).')
>>>>    420                     )';
>>>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>>>> array( 'dn' ) );
>>>>    422          $count = 0;
>>>>    423
>>>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>>>    425          if( $excludedn ) {
>>>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>>>    427                  if( is_null( $entries[$i] ) ) continue;
>>>>    428                  if(
>>> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>>>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>>>    429                  debug("found ".$entries[$i]['dn'] );
>>>>    430                  $count++;
>>>>    431            }
>>>>    432          } else $count += $entries['count'];
>>>>
>>>>
>>>> Kind regards
>>>>
>>>> Andrea Soliva
>>>>
>>>> Mail: soliva at comcept.ch
>>>> -----Urspr?ngliche Nachricht-----
>>>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>>>> kolab-devel-bounces at kolab.org
>>>> Gesendet: Montag, 25. Januar 2010 14:37
>>>> An: kolab-devel at kolab.org
>>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax
> function.ldap-search
>>>>
>>>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
>> DN
>>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>>> 204
>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
>>> argument
>>>>> is not a valid ldap result resource in
>>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>>
>>>>> Is this already recognized? Is it not known....I tried to figure out
>> what
>>>>> is wrong but actually I could not?!
>>>>>
>>>>> Any suggestion?
>>>>
>>>> My suggestion is to check the given line 204 and see which argument
>>>> is used there (maybe add a statement to print it out).
>>>>
>>>>> By the way is there a documentation about Master/Slave configuration
>>>>> meaning how this works etc. I could not find anything. Any hints would
>> be
>>>>> appriciated.
>>>>
>>>> I think the documentation is in the architecture documents.
>>>> The idea is pretty simple: Replicate the directory server on the slave
>>>> (for which there is a bootstrap) have all read access on the slave
>>> accounts
>>>> go
>>>> to the slave LDAP server and all write access (only by webadmin) to the
>>>> master.
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> Kolab-devel mailing list
>>>> Kolab-devel at kolab.org
>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>>
>>>
>>>
>>>
>>> --
>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>>
>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>>> --------------------------------------------------------------------
>>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>> --------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>> _______________________________________________
>>> 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 <<
>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> 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 <<
> --------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------



From wrobel at pardus.de  Mon Feb 22 06:06:25 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Feb 2010 06:06:25 +0100
Subject: [Kolab-devel] wilde:
	server/patches/horde-webmail/1.2.0/tg	t_Kolab__Server_HK_GW_MappableAttributes.diff,
	NONE, 1.1.4.1 series, 1.5.2.7, 1.5.2.8
In-Reply-To: <20091013132410.98FE9600801@lists.intevation.de>
References: <20091013132410.98FE9600801@lists.intevation.de>
Message-ID: <20100222060625.1556747hwozjsjk0@webmail.pardus.de>

Merged ohne commit, da auch der Webclient mittlerweile das  
installierte Kolab_Server-Paket verwendet.

Quoting cvs at kolab.org:

> Author: wilde
>
> Update of /kolabrepository/server/patches/horde-webmail/1.2.0/tg
> In directory doto:/tmp/cvs-serv14888/patches/horde-webmail/1.2.0/tg
>
> Modified Files:
>       Tag: kolab_2_2_branch
> 	series
> Added Files:
>       Tag: kolab_2_2_branch
> 	t_Kolab__Server_HK_GW_MappableAttributes.diff
> Log Message:
> Added ability to map arbitrary ldap attributes to those expected by kolab.
> (Merged from suc branch)
>
>
> --- NEW FILE: t_Kolab__Server_HK_GW_MappableAttributes.diff ---
> From: Gunnar Wrobel <p at rdus.de>
> Subject: [PATCH] t/Kolab_Server/HK/GW/MappableAttributes
>
> Allow to configure mapped LDAP attributes.
>
> Signed-off-by: Gunnar Wrobel <p at rdus.de>
>
> ---
>  horde-webmail/lib/Horde/Kolab/Server.php           |   15 +-
>  horde-webmail/lib/Horde/Kolab/Server/Object.php    |    2 +
>  .../lib/Horde/Kolab/Server/Object/address.php      |   33 ++-
>  .../lib/Horde/Kolab/Server/Object/adminrole.php    |   35 ++-
>  .../lib/Horde/Kolab/Server/Object/distlist.php     |   30 ++-
>  .../lib/Horde/Kolab/Server/Object/group.php        |   23 +-
>  .../lib/Horde/Kolab/Server/Object/server.php       |   21 ++-
>  .../lib/Horde/Kolab/Server/Object/sharedfolder.php |   23 +-
>  .../lib/Horde/Kolab/Server/Object/user.php         |   32 ++-
>  horde-webmail/lib/Horde/Kolab/Server/ldap.php      |  308  
> ++++++++++++++++++--
>  horde-webmail/lib/Horde/Kolab/Server/test.php      |   20 ++-
>  11 files changed, 467 insertions(+), 75 deletions(-)
>
> diff --git a/horde-webmail/lib/Horde/Kolab/Server.php  
> b/horde-webmail/lib/Horde/Kolab/Server.php
> index bf251f5..fd0bda7 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server.php
> @@ -159,9 +159,12 @@ class Horde_Kolab_Server {
>              $driver = 'ldap';
>
>              $server_params = array('server'  =>  
> $conf['kolab']['ldap']['server'],
> -                                  'base_dn' =>  
> $conf['kolab']['ldap']['basedn'],
> -                                  'uid'     =>  
> $conf['kolab']['ldap']['phpdn'],
> -                                  'pass'    =>  
> $conf['kolab']['ldap']['phppw']);
> +                                   'base_dn' =>  
> $conf['kolab']['ldap']['basedn'],
> +                                   'uid'     =>  
> $conf['kolab']['ldap']['phpdn'],
> +                                   'pass'    =>  
> $conf['kolab']['ldap']['phppw']);
> +            if (isset($conf['kolab']['ldap']['map'])) {
> +                $server_params['map'] = $conf['kolab']['ldap']['map'];
> +            }
>          } else {
>              $driver        = null;
>              $server_params = array();
> @@ -473,7 +476,7 @@ class Horde_Kolab_Server {
>      function uidForId($id,
>                        $restrict = KOLAB_SERVER_RESULT_SINGLE)
>      {
> -        return $this->uidForAttr('uid', $id);
> +        return $this->uidForAttr(KOLAB_ATTR_SID, $id);
>      }
>
>      /**
> @@ -513,7 +516,7 @@ class Horde_Kolab_Server {
>       */
>      function uidForIdOrMail($id)
>      {
> -        $uid = $this->uidForAttr('uid', $id);
> +        $uid = $this->uidForAttr(KOLAB_ATTR_SID, $id);
>          if (!$uid) {
>              $uid = $this->uidForAttr('mail', $id);
>          }
> @@ -562,7 +565,7 @@ class Horde_Kolab_Server {
>       */
>      function uidForMailOrIdOrAlias($id)
>      {
> -        $uid = $this->uidForAttr('uid', $id);
> +        $uid = $this->uidForAttr(KOLAB_ATTR_SID, $id);
>          if (!$uid) {
>              $uid = $this->uidForAttr('mail', $id);
>              if (!$uid) {
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object.php
> index 2e5ada2..be9eca9 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object.php
> @@ -26,6 +26,7 @@ define('KOLAB_OBJECT_USER',              
> 'Horde_Kolab_Server_Object_user');
>  define('KOLAB_OBJECT_SERVER',           'Horde_Kolab_Server_Object_server');
>
>  /** Define the possible Kolab object attributes */
> +define('KOLAB_ATTR_OC',           'objectClass');
>  define('KOLAB_ATTR_UID',          'dn');
>  define('KOLAB_ATTR_ID',           'id');
>  define('KOLAB_ATTR_SN',           'sn');
> @@ -35,6 +36,7 @@ define('KOLAB_ATTR_FN',           'fn');
>  define('KOLAB_ATTR_LNFN',         'lnfn');
>  define('KOLAB_ATTR_FNLN',         'fnln');
>  define('KOLAB_ATTR_MAIL',         'mail');
> +define('KOLAB_ATTR_ALIAS',        'alias');
>  define('KOLAB_ATTR_SID',          'uid');
>  define('KOLAB_ATTR_ACL',          'acl');
>  define('KOLAB_ATTR_MEMBER',       'member');
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/address.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
> index 98ed518..bd6128f 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
> @@ -33,13 +33,6 @@
>  class Horde_Kolab_Server_Object_address extends Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter = '(&(objectclass=inetOrgPerson)(!(uid=*))(sn=*))';
> -
> -    /**
>       * The attributes supported by this class
>       *
>       * @var array
> @@ -86,6 +79,32 @@ class Horde_Kolab_Server_Object_address extends  
> Horde_Kolab_Server_Object {
>      );
>
>      /**
> +     * The LDAP filter to retrieve this object type
> +     *
> +     * @return string
> +     */
> +    function getFilter()
> +    {
> +        $criteria = array('AND' => array(
> +                              array('field' => KOLAB_ATTR_SN,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_OC,
> +                                    'op'    => '=',
> +                                    'test'  => KOLAB_OC_INETORGPERSON),
> +                              array('NOT' => array(
> +                                        array('field' => KOLAB_ATTR_SID,
> +                                              'op'    => '=',
> +                                              'test'  => '*'),
> +                                    ),
> +                              ),
> +                          ),
> +        );
> +        return $criteria;
> +    }
> +
> +
> +    /**
>       * Convert the object attributes to a hash.
>       *
>       * @param string $attrs The attributes to return.
> diff --git  
> a/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
> index aea4410..b2571ff 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
> @@ -32,13 +32,6 @@
>  class Horde_Kolab_Server_Object_adminrole extends  
> Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter =  
> '(&(cn=*)(objectClass=inetOrgPerson)(!(uid=manager))(sn=*))';
> -
> -    /**
>       * The attributes supported by this class
>       *
>       * @var array
> @@ -87,6 +80,34 @@ class Horde_Kolab_Server_Object_adminrole extends  
> Horde_Kolab_Server_Object {
>      );
>
>      /**
> +     * The LDAP filter to retrieve this object type
> +     *
> +     * @return string
> +     */
> +    function getFilter()
> +    {
> +        $criteria = array('AND' => array(
> +                              array('field' => KOLAB_ATTR_CN,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_SN,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_OC,
> +                                    'op'    => '=',
> +                                    'test'  => KOLAB_OC_INETORGPERSON),
> +                              array('NOT' => array(
> +                                        array('field' => KOLAB_ATTR_SID,
> +                                              'op'    => '=',
> +                                              'test'  => 'manager'),
> +                                    ),
> +                              ),
> +                          ),
> +        );
> +        return $criteria;
> +    }
> +
> +    /**
>       * Convert the object attributes to a hash.
>       *
>       * @param string $attrs The attributes to return.
> diff --git  
> a/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
> index 7965e0d..22e096e 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
> @@ -34,14 +34,6 @@ require_once 'Horde/Kolab/Server/Object/group.php';
>  class Horde_Kolab_Server_Object_distlist extends  
> Horde_Kolab_Server_Object_group {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter = '(&(objectClass=kolabGroupOfNames)(mail=*))';
> -
> -
> -    /**
>       * The attributes required when creating an object of this class.
>       *
>       * @var array
> @@ -49,4 +41,26 @@ class Horde_Kolab_Server_Object_distlist extends  
> Horde_Kolab_Server_Object_group
>      var $_required_attributes = array(
>          KOLAB_ATTR_MAIL,
>      );
> +
> +    /**
> +     * Return the filter string to retrieve this object type.
> +     *
> +     * @static
> +     *
> +     * @return string The filter to retrieve this object type from  
> the server
> +     *                database.
> +     */
> +    public static function getFilter()
> +    {
> +        $criteria = array('AND' => array(
> +                              array('field' => KOLAB_ATTR_MAIL,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_OC,
> +                                    'op'    => '=',
> +                                    'test'  => KOLAB_OC_KOLABGROUPOFNAMES),
> +                          ),
> +        );
> +        return $criteria;
> +    }
>  };
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/group.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
> index 91c1bd2..f58c905 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
> @@ -32,13 +32,6 @@
>  class Horde_Kolab_Server_Object_group extends Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter = '(objectClass=kolabGroupOfNames)';
> -
> -    /**
>       * The attributes supported by this class
>       *
>       * @var array
> @@ -104,6 +97,22 @@ class Horde_Kolab_Server_Object_group extends  
> Horde_Kolab_Server_Object {
>      }
>
>      /**
> +     * Return the filter string to retrieve this object type.
> +     *
> +     * @return string The filter to retrieve this object type from  
> the server
> +     *                database.
> +     */
> +    public static function getFilter()
> +    {
> +        $criteria = array('AND' => array(array('field' => KOLAB_ATTR_OC,
> +                                               'op'    => '=',
> +                                               'test'  =>  
> KOLAB_OC_KOLABGROUPOFNAMES),
> +                          ),
> +        );
> +        return $criteria;
> +    }
> +
> +    /**
>       * Convert the object attributes to a hash.
>       *
>       * @param string $attrs The attributes to return.
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/server.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
> index 965eb84..740417c 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
> @@ -32,11 +32,26 @@
>  class Horde_Kolab_Server_Object_server extends Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> +     * Return the filter string to retrieve this object type.
>       *
> -     * @var string
> +     * @static
> +     *
> +     * @return string The filter to retrieve this object type from  
> the server
> +     *                database.
>       */
> -    var $filter = '(&((k=kolab))(objectclass=kolab))';
> +    public static function getFilter()
> +    {
> +        $criteria = array('AND' => array(
> +                              array('field' => 'k',
> +                                    'op'    => '=',
> +                                    'test'  => 'kolab'),
> +                              array('field' => KOLAB_ATTR_OC,
> +                                    'op'    => '=',
> +                                    'test'  => KOLAB_OC_KOLAB),
> +                          ),
> +        );
> +        return $criteria;
> +    }
>
>      /**
>       * The attributes supported by this class
> diff --git  
> a/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
> index 3b68862..b92f07b 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
> @@ -33,13 +33,6 @@
>  class Horde_Kolab_Server_Object_sharedfolder extends  
> Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter = '(objectClass=kolabSharedFolder)';
> -
> -    /**
>       * The attributes supported by this class
>       *
>       * @var array
> @@ -89,6 +82,22 @@ class Horde_Kolab_Server_Object_sharedfolder  
> extends Horde_Kolab_Server_Object {
>      }
>
>      /**
> +     * Return the filter string to retrieve this object type.
> +     *
> +     * @return string The filter to retrieve this object type from  
> the server
> +     *                database.
> +     */
> +    public static function getFilter()
> +    {
> +        $criteria = array('AND' => array(array('field' => KOLAB_ATTR_OC,
> +                                               'op'    => '=',
> +                                               'test'  =>  
> KOLAB_OC_KOLABSHAREDFOLDER),
> +                          ),
> +        );
> +        return $criteria;
> +    }
> +
> +    /**
>       * Convert the object attributes to a hash.
>       *
>       * @param string $attrs The attributes to return.
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/user.php  
> b/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
> index d4e57a0..b702a4f 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
> @@ -33,13 +33,6 @@
>  class Horde_Kolab_Server_Object_user extends Horde_Kolab_Server_Object {
>
>      /**
> -     * The LDAP filter to retrieve this object type
> -     *
> -     * @var string
> -     */
> -    var $filter =  
> '(&(objectClass=kolabInetOrgPerson)(uid=*)(mail=*)(sn=*))';
> -
> -    /**
>       * The attributes supported by this class
>       *
>       * @var array
> @@ -154,6 +147,31 @@ class Horde_Kolab_Server_Object_user extends  
> Horde_Kolab_Server_Object {
>      }
>
>      /**
> +     * The LDAP filter to retrieve this object type
> +     *
> +     * @return string
> +     */
> +    function getFilter()
> +    {
> +        $criteria = array('AND' => array(
> +                              array('field' => KOLAB_ATTR_SN,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_MAIL,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_SID,
> +                                    'op'    => '=',
> +                                    'test'  => '*'),
> +                              array('field' => KOLAB_ATTR_OC,
> +                                    'op'    => '=',
> +                                    'test'  => KOLAB_OC_KOLABINETORGPERSON),
> +                          ),
> +        );
> +        return $criteria;
> +    }
> +
> +    /**
>       * Convert the object attributes to a hash.
>       *
>       * @param string $attrs The attributes to return.
> diff --git a/horde-webmail/lib/Horde/Kolab/Server/ldap.php  
> b/horde-webmail/lib/Horde/Kolab/Server/ldap.php
> index a50ba2c..ea73b4f 100644
> --- a/horde-webmail/lib/Horde/Kolab/Server/ldap.php
> +++ b/horde-webmail/lib/Horde/Kolab/Server/ldap.php
> @@ -2,7 +2,7 @@
>  /**
>   * The driver for accessing the Kolab user database stored in LDAP.
>   *
> - * $Horde: framework/Kolab_Server/lib/Horde/Kolab/Server/ldap.php,v  
> 1.2.2.2 2008/08/01 07:56:19 wrobel Exp $
> + * $Horde: framework/Kolab_Server/lib/Horde/Kolab/Server/ldap.php,v  
> 1.2.2.10 2009/02/24 07:39:47 wrobel Exp $
>   *
>   * PHP version 4
>   *
> @@ -210,6 +210,7 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>          }
>
>          if (isset($attrs)) {
> +            $this->mapKeys($attrs);
>              $result = @ldap_read($this->_connection, $dn,  
> '(objectclass=*)', $attrs);
>          } else {
>              $result = @ldap_read($this->_connection, $dn,  
> '(objectclass=*)');
> @@ -220,7 +221,7 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>          }
>          $entry = $this->_firstEntry($result);
>          if (!$entry) {
> -            ldap_free_result($result);
> +            @ldap_free_result($result);
>              return PEAR::raiseError(sprintf(_("LDAP Error: Empty  
> result for: %s."),
>                                              $dn));
>          }
> @@ -229,7 +230,10 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>              return PEAR::raiseError(sprintf(_("LDAP Error: No such  
> dn: %s: %s"),
>                                              $dn, $this->_error()));
>          }
> -        ldap_free_result($result);
> +        @ldap_free_result($result);
> +
> +        $this->unmapAttributes($object);
> +
>          return $object;
>      }
>
> @@ -250,6 +254,8 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>              }
>          }
>
> +        $this->mapAttributes($data);
> +
>          return @ldap_add($this->_connection, $dn, $data);
>      }
>
> @@ -681,9 +687,25 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>       */
>      function mailForIdOrMail($id)
>      {
> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(uid='.
> -            Horde_LDAP::quote($id) . ')(mail=' .
> -            Horde_LDAP::quote($id) . ')))';
> +        $criteria = array('AND' =>
> +                         array(
> +                             array('field' => KOLAB_ATTR_OC,
> +                                   'op'    => '=',
> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
> +                             array('OR' =>
> +                                   array(
> +                                       array('field' => KOLAB_ATTR_SID,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                       array('field' => KOLAB_ATTR_MAIL,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                   ),
> +                             ),
> +                         ),
> +        );
> +        $filter   = $this->searchQuery($criteria);
> +
>          $result = $this->_attrsForFilter($filter, array('mail'),
>                                           KOLAB_SERVER_RESULT_STRICT);
>          if (is_a($result, 'PEAR_Error')) {
> @@ -702,9 +724,24 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>       */
>      function uidForIdOrMail($id)
>      {
> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(uid='.
> -            Horde_LDAP::quote($id) . ')(mail=' .
> -            Horde_LDAP::quote($id) . ')))';
> +        $criteria = array('AND' =>
> +                         array(
> +                             array('field' => KOLAB_ATTR_OC,
> +                                   'op'    => '=',
> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
> +                             array('OR' =>
> +                                   array(
> +                                       array('field' => KOLAB_ATTR_SID,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                       array('field' => KOLAB_ATTR_MAIL,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                   ),
> +                             ),
> +                         ),
> +        );
> +        $filter   = $this->searchQuery($criteria);
>          return $this->_dnForFilter($filter, KOLAB_SERVER_RESULT_STRICT);
>      }
>
> @@ -717,9 +754,25 @@ class Horde_Kolab_Server_ldap extends  
> Horde_Kolab_Server {
>       */
>      function addrsForIdOrMail($id)
>      {
> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(mail='
> -            . Horde_LDAP::quote($id) . ')(uid='
> -            . Horde_LDAP::quote($id) . ')))';
> +        $criteria = array('AND' =>
> +                         array(
> +                             array('field' => KOLAB_ATTR_OC,
> +                                   'op'    => '=',
> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
> +                             array('OR' =>
> +                                   array(
> +                                       array('field' => KOLAB_ATTR_SID,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                       array('field' => KOLAB_ATTR_MAIL,
> +                                             'op'    => '=',
> +                                             'test'  => $id),
> +                                   ),
> +                             ),
> +                         ),
> +        );
> +        $filter   = $this->searchQuery($criteria);
> +
>          $result = $this->_attrsForFilter($filter, array('mail', 'alias'),
>


From wrobel at pardus.de  Mon Feb 22 09:16:20 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Feb 2010 09:16:20 +0100
Subject: [Kolab-devel]
	wilde:	server/patches/horde-webmail/1.2.0/tg	t_Kolab__Server_HK_GW_MappableAttributes.diff,
	NONE, 1.1.4.1 series, 1.5.2.7, 1.5.2.8
In-Reply-To: <20100222060625.1556747hwozjsjk0@webmail.pardus.de>
References: <20091013132410.98FE9600801@lists.intevation.de>
	<20100222060625.1556747hwozjsjk0@webmail.pardus.de>
Message-ID: <20100222091620.69464bmbdxkecmyo@webmail.pardus.de>

Quoting Gunnar Wrobel <wrobel at pardus.de>:

> Merged ohne commit, da auch der Webclient mittlerweile das
> installierte Kolab_Server-Paket verwendet.

Sorry, wasn't meant for the list but as direct message to Sascha. It  
was still early in the morning...

>
> Quoting cvs at kolab.org:
>
>> Author: wilde
>>
>> Update of /kolabrepository/server/patches/horde-webmail/1.2.0/tg
>> In directory doto:/tmp/cvs-serv14888/patches/horde-webmail/1.2.0/tg
>>
>> Modified Files:
>>       Tag: kolab_2_2_branch
>> 	series
>> Added Files:
>>       Tag: kolab_2_2_branch
>> 	t_Kolab__Server_HK_GW_MappableAttributes.diff
>> Log Message:
>> Added ability to map arbitrary ldap attributes to those expected by kolab.
>> (Merged from suc branch)
>>
>>
>> --- NEW FILE: t_Kolab__Server_HK_GW_MappableAttributes.diff ---
>> From: Gunnar Wrobel <p at rdus.de>
>> Subject: [PATCH] t/Kolab_Server/HK/GW/MappableAttributes
>>
>> Allow to configure mapped LDAP attributes.
>>
>> Signed-off-by: Gunnar Wrobel <p at rdus.de>
>>
>> ---
>>  horde-webmail/lib/Horde/Kolab/Server.php           |   15 +-
>>  horde-webmail/lib/Horde/Kolab/Server/Object.php    |    2 +
>>  .../lib/Horde/Kolab/Server/Object/address.php      |   33 ++-
>>  .../lib/Horde/Kolab/Server/Object/adminrole.php    |   35 ++-
>>  .../lib/Horde/Kolab/Server/Object/distlist.php     |   30 ++-
>>  .../lib/Horde/Kolab/Server/Object/group.php        |   23 +-
>>  .../lib/Horde/Kolab/Server/Object/server.php       |   21 ++-
>>  .../lib/Horde/Kolab/Server/Object/sharedfolder.php |   23 +-
>>  .../lib/Horde/Kolab/Server/Object/user.php         |   32 ++-
>>  horde-webmail/lib/Horde/Kolab/Server/ldap.php      |  308
>> ++++++++++++++++++--
>>  horde-webmail/lib/Horde/Kolab/Server/test.php      |   20 ++-
>>  11 files changed, 467 insertions(+), 75 deletions(-)
>>
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server.php
>> b/horde-webmail/lib/Horde/Kolab/Server.php
>> index bf251f5..fd0bda7 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server.php
>> @@ -159,9 +159,12 @@ class Horde_Kolab_Server {
>>              $driver = 'ldap';
>>
>>              $server_params = array('server'  =>
>> $conf['kolab']['ldap']['server'],
>> -                                  'base_dn' =>
>> $conf['kolab']['ldap']['basedn'],
>> -                                  'uid'     =>
>> $conf['kolab']['ldap']['phpdn'],
>> -                                  'pass'    =>
>> $conf['kolab']['ldap']['phppw']);
>> +                                   'base_dn' =>
>> $conf['kolab']['ldap']['basedn'],
>> +                                   'uid'     =>
>> $conf['kolab']['ldap']['phpdn'],
>> +                                   'pass'    =>
>> $conf['kolab']['ldap']['phppw']);
>> +            if (isset($conf['kolab']['ldap']['map'])) {
>> +                $server_params['map'] = $conf['kolab']['ldap']['map'];
>> +            }
>>          } else {
>>              $driver        = null;
>>              $server_params = array();
>> @@ -473,7 +476,7 @@ class Horde_Kolab_Server {
>>      function uidForId($id,
>>                        $restrict = KOLAB_SERVER_RESULT_SINGLE)
>>      {
>> -        return $this->uidForAttr('uid', $id);
>> +        return $this->uidForAttr(KOLAB_ATTR_SID, $id);
>>      }
>>
>>      /**
>> @@ -513,7 +516,7 @@ class Horde_Kolab_Server {
>>       */
>>      function uidForIdOrMail($id)
>>      {
>> -        $uid = $this->uidForAttr('uid', $id);
>> +        $uid = $this->uidForAttr(KOLAB_ATTR_SID, $id);
>>          if (!$uid) {
>>              $uid = $this->uidForAttr('mail', $id);
>>          }
>> @@ -562,7 +565,7 @@ class Horde_Kolab_Server {
>>       */
>>      function uidForMailOrIdOrAlias($id)
>>      {
>> -        $uid = $this->uidForAttr('uid', $id);
>> +        $uid = $this->uidForAttr(KOLAB_ATTR_SID, $id);
>>          if (!$uid) {
>>              $uid = $this->uidForAttr('mail', $id);
>>              if (!$uid) {
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object.php
>> index 2e5ada2..be9eca9 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object.php
>> @@ -26,6 +26,7 @@ define('KOLAB_OBJECT_USER',
>> 'Horde_Kolab_Server_Object_user');
>>  define('KOLAB_OBJECT_SERVER',            
>> 'Horde_Kolab_Server_Object_server');
>>
>>  /** Define the possible Kolab object attributes */
>> +define('KOLAB_ATTR_OC',           'objectClass');
>>  define('KOLAB_ATTR_UID',          'dn');
>>  define('KOLAB_ATTR_ID',           'id');
>>  define('KOLAB_ATTR_SN',           'sn');
>> @@ -35,6 +36,7 @@ define('KOLAB_ATTR_FN',           'fn');
>>  define('KOLAB_ATTR_LNFN',         'lnfn');
>>  define('KOLAB_ATTR_FNLN',         'fnln');
>>  define('KOLAB_ATTR_MAIL',         'mail');
>> +define('KOLAB_ATTR_ALIAS',        'alias');
>>  define('KOLAB_ATTR_SID',          'uid');
>>  define('KOLAB_ATTR_ACL',          'acl');
>>  define('KOLAB_ATTR_MEMBER',       'member');
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
>> index 98ed518..bd6128f 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/address.php
>> @@ -33,13 +33,6 @@
>>  class Horde_Kolab_Server_Object_address extends Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter = '(&(objectclass=inetOrgPerson)(!(uid=*))(sn=*))';
>> -
>> -    /**
>>       * The attributes supported by this class
>>       *
>>       * @var array
>> @@ -86,6 +79,32 @@ class Horde_Kolab_Server_Object_address extends
>> Horde_Kolab_Server_Object {
>>      );
>>
>>      /**
>> +     * The LDAP filter to retrieve this object type
>> +     *
>> +     * @return string
>> +     */
>> +    function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(
>> +                              array('field' => KOLAB_ATTR_SN,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_OC,
>> +                                    'op'    => '=',
>> +                                    'test'  => KOLAB_OC_INETORGPERSON),
>> +                              array('NOT' => array(
>> +                                        array('field' => KOLAB_ATTR_SID,
>> +                                              'op'    => '=',
>> +                                              'test'  => '*'),
>> +                                    ),
>> +                              ),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>> +
>> +
>> +    /**
>>       * Convert the object attributes to a hash.
>>       *
>>       * @param string $attrs The attributes to return.
>> diff --git
>> a/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
>> index aea4410..b2571ff 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/adminrole.php
>> @@ -32,13 +32,6 @@
>>  class Horde_Kolab_Server_Object_adminrole extends
>> Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter =
>> '(&(cn=*)(objectClass=inetOrgPerson)(!(uid=manager))(sn=*))';
>> -
>> -    /**
>>       * The attributes supported by this class
>>       *
>>       * @var array
>> @@ -87,6 +80,34 @@ class Horde_Kolab_Server_Object_adminrole extends
>> Horde_Kolab_Server_Object {
>>      );
>>
>>      /**
>> +     * The LDAP filter to retrieve this object type
>> +     *
>> +     * @return string
>> +     */
>> +    function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(
>> +                              array('field' => KOLAB_ATTR_CN,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_SN,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_OC,
>> +                                    'op'    => '=',
>> +                                    'test'  => KOLAB_OC_INETORGPERSON),
>> +                              array('NOT' => array(
>> +                                        array('field' => KOLAB_ATTR_SID,
>> +                                              'op'    => '=',
>> +                                              'test'  => 'manager'),
>> +                                    ),
>> +                              ),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>> +
>> +    /**
>>       * Convert the object attributes to a hash.
>>       *
>>       * @param string $attrs The attributes to return.
>> diff --git
>> a/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
>> index 7965e0d..22e096e 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/distlist.php
>> @@ -34,14 +34,6 @@ require_once 'Horde/Kolab/Server/Object/group.php';
>>  class Horde_Kolab_Server_Object_distlist extends
>> Horde_Kolab_Server_Object_group {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter = '(&(objectClass=kolabGroupOfNames)(mail=*))';
>> -
>> -
>> -    /**
>>       * The attributes required when creating an object of this class.
>>       *
>>       * @var array
>> @@ -49,4 +41,26 @@ class Horde_Kolab_Server_Object_distlist extends
>> Horde_Kolab_Server_Object_group
>>      var $_required_attributes = array(
>>          KOLAB_ATTR_MAIL,
>>      );
>> +
>> +    /**
>> +     * Return the filter string to retrieve this object type.
>> +     *
>> +     * @static
>> +     *
>> +     * @return string The filter to retrieve this object type from
>> the server
>> +     *                database.
>> +     */
>> +    public static function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(
>> +                              array('field' => KOLAB_ATTR_MAIL,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_OC,
>> +                                    'op'    => '=',
>> +                                    'test'  => KOLAB_OC_KOLABGROUPOFNAMES),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>>  };
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
>> index 91c1bd2..f58c905 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/group.php
>> @@ -32,13 +32,6 @@
>>  class Horde_Kolab_Server_Object_group extends Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter = '(objectClass=kolabGroupOfNames)';
>> -
>> -    /**
>>       * The attributes supported by this class
>>       *
>>       * @var array
>> @@ -104,6 +97,22 @@ class Horde_Kolab_Server_Object_group extends
>> Horde_Kolab_Server_Object {
>>      }
>>
>>      /**
>> +     * Return the filter string to retrieve this object type.
>> +     *
>> +     * @return string The filter to retrieve this object type from
>> the server
>> +     *                database.
>> +     */
>> +    public static function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(array('field' => KOLAB_ATTR_OC,
>> +                                               'op'    => '=',
>> +                                               'test'  =>
>> KOLAB_OC_KOLABGROUPOFNAMES),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>> +
>> +    /**
>>       * Convert the object attributes to a hash.
>>       *
>>       * @param string $attrs The attributes to return.
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
>> index 965eb84..740417c 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/server.php
>> @@ -32,11 +32,26 @@
>>  class Horde_Kolab_Server_Object_server extends Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> +     * Return the filter string to retrieve this object type.
>>       *
>> -     * @var string
>> +     * @static
>> +     *
>> +     * @return string The filter to retrieve this object type from
>> the server
>> +     *                database.
>>       */
>> -    var $filter = '(&((k=kolab))(objectclass=kolab))';
>> +    public static function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(
>> +                              array('field' => 'k',
>> +                                    'op'    => '=',
>> +                                    'test'  => 'kolab'),
>> +                              array('field' => KOLAB_ATTR_OC,
>> +                                    'op'    => '=',
>> +                                    'test'  => KOLAB_OC_KOLAB),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>>
>>      /**
>>       * The attributes supported by this class
>> diff --git
>> a/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
>> index 3b68862..b92f07b 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/sharedfolder.php
>> @@ -33,13 +33,6 @@
>>  class Horde_Kolab_Server_Object_sharedfolder extends
>> Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter = '(objectClass=kolabSharedFolder)';
>> -
>> -    /**
>>       * The attributes supported by this class
>>       *
>>       * @var array
>> @@ -89,6 +82,22 @@ class Horde_Kolab_Server_Object_sharedfolder
>> extends Horde_Kolab_Server_Object {
>>      }
>>
>>      /**
>> +     * Return the filter string to retrieve this object type.
>> +     *
>> +     * @return string The filter to retrieve this object type from
>> the server
>> +     *                database.
>> +     */
>> +    public static function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(array('field' => KOLAB_ATTR_OC,
>> +                                               'op'    => '=',
>> +                                               'test'  =>
>> KOLAB_OC_KOLABSHAREDFOLDER),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>> +
>> +    /**
>>       * Convert the object attributes to a hash.
>>       *
>>       * @param string $attrs The attributes to return.
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
>> b/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
>> index d4e57a0..b702a4f 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/Object/user.php
>> @@ -33,13 +33,6 @@
>>  class Horde_Kolab_Server_Object_user extends Horde_Kolab_Server_Object {
>>
>>      /**
>> -     * The LDAP filter to retrieve this object type
>> -     *
>> -     * @var string
>> -     */
>> -    var $filter =
>> '(&(objectClass=kolabInetOrgPerson)(uid=*)(mail=*)(sn=*))';
>> -
>> -    /**
>>       * The attributes supported by this class
>>       *
>>       * @var array
>> @@ -154,6 +147,31 @@ class Horde_Kolab_Server_Object_user extends
>> Horde_Kolab_Server_Object {
>>      }
>>
>>      /**
>> +     * The LDAP filter to retrieve this object type
>> +     *
>> +     * @return string
>> +     */
>> +    function getFilter()
>> +    {
>> +        $criteria = array('AND' => array(
>> +                              array('field' => KOLAB_ATTR_SN,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_MAIL,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_SID,
>> +                                    'op'    => '=',
>> +                                    'test'  => '*'),
>> +                              array('field' => KOLAB_ATTR_OC,
>> +                                    'op'    => '=',
>> +                                    'test'  =>  
>> KOLAB_OC_KOLABINETORGPERSON),
>> +                          ),
>> +        );
>> +        return $criteria;
>> +    }
>> +
>> +    /**
>>       * Convert the object attributes to a hash.
>>       *
>>       * @param string $attrs The attributes to return.
>> diff --git a/horde-webmail/lib/Horde/Kolab/Server/ldap.php
>> b/horde-webmail/lib/Horde/Kolab/Server/ldap.php
>> index a50ba2c..ea73b4f 100644
>> --- a/horde-webmail/lib/Horde/Kolab/Server/ldap.php
>> +++ b/horde-webmail/lib/Horde/Kolab/Server/ldap.php
>> @@ -2,7 +2,7 @@
>>  /**
>>   * The driver for accessing the Kolab user database stored in LDAP.
>>   *
>> - * $Horde: framework/Kolab_Server/lib/Horde/Kolab/Server/ldap.php,v
>> 1.2.2.2 2008/08/01 07:56:19 wrobel Exp $
>> + * $Horde: framework/Kolab_Server/lib/Horde/Kolab/Server/ldap.php,v
>> 1.2.2.10 2009/02/24 07:39:47 wrobel Exp $
>>   *
>>   * PHP version 4
>>   *
>> @@ -210,6 +210,7 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>          }
>>
>>          if (isset($attrs)) {
>> +            $this->mapKeys($attrs);
>>              $result = @ldap_read($this->_connection, $dn,
>> '(objectclass=*)', $attrs);
>>          } else {
>>              $result = @ldap_read($this->_connection, $dn,
>> '(objectclass=*)');
>> @@ -220,7 +221,7 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>          }
>>          $entry = $this->_firstEntry($result);
>>          if (!$entry) {
>> -            ldap_free_result($result);
>> +            @ldap_free_result($result);
>>              return PEAR::raiseError(sprintf(_("LDAP Error: Empty
>> result for: %s."),
>>                                              $dn));
>>          }
>> @@ -229,7 +230,10 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>              return PEAR::raiseError(sprintf(_("LDAP Error: No such
>> dn: %s: %s"),
>>                                              $dn, $this->_error()));
>>          }
>> -        ldap_free_result($result);
>> +        @ldap_free_result($result);
>> +
>> +        $this->unmapAttributes($object);
>> +
>>          return $object;
>>      }
>>
>> @@ -250,6 +254,8 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>              }
>>          }
>>
>> +        $this->mapAttributes($data);
>> +
>>          return @ldap_add($this->_connection, $dn, $data);
>>      }
>>
>> @@ -681,9 +687,25 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>       */
>>      function mailForIdOrMail($id)
>>      {
>> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(uid='.
>> -            Horde_LDAP::quote($id) . ')(mail=' .
>> -            Horde_LDAP::quote($id) . ')))';
>> +        $criteria = array('AND' =>
>> +                         array(
>> +                             array('field' => KOLAB_ATTR_OC,
>> +                                   'op'    => '=',
>> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
>> +                             array('OR' =>
>> +                                   array(
>> +                                       array('field' => KOLAB_ATTR_SID,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                       array('field' => KOLAB_ATTR_MAIL,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                   ),
>> +                             ),
>> +                         ),
>> +        );
>> +        $filter   = $this->searchQuery($criteria);
>> +
>>          $result = $this->_attrsForFilter($filter, array('mail'),
>>                                           KOLAB_SERVER_RESULT_STRICT);
>>          if (is_a($result, 'PEAR_Error')) {
>> @@ -702,9 +724,24 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>       */
>>      function uidForIdOrMail($id)
>>      {
>> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(uid='.
>> -            Horde_LDAP::quote($id) . ')(mail=' .
>> -            Horde_LDAP::quote($id) . ')))';
>> +        $criteria = array('AND' =>
>> +                         array(
>> +                             array('field' => KOLAB_ATTR_OC,
>> +                                   'op'    => '=',
>> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
>> +                             array('OR' =>
>> +                                   array(
>> +                                       array('field' => KOLAB_ATTR_SID,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                       array('field' => KOLAB_ATTR_MAIL,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                   ),
>> +                             ),
>> +                         ),
>> +        );
>> +        $filter   = $this->searchQuery($criteria);
>>          return $this->_dnForFilter($filter, KOLAB_SERVER_RESULT_STRICT);
>>      }
>>
>> @@ -717,9 +754,25 @@ class Horde_Kolab_Server_ldap extends
>> Horde_Kolab_Server {
>>       */
>>      function addrsForIdOrMail($id)
>>      {
>> -        $filter = '(&(objectClass=kolabInetOrgPerson)(|(mail='
>> -            . Horde_LDAP::quote($id) . ')(uid='
>> -            . Horde_LDAP::quote($id) . ')))';
>> +        $criteria = array('AND' =>
>> +                         array(
>> +                             array('field' => KOLAB_ATTR_OC,
>> +                                   'op'    => '=',
>> +                                   'test'  => KOLAB_OC_KOLABINETORGPERSON),
>> +                             array('OR' =>
>> +                                   array(
>> +                                       array('field' => KOLAB_ATTR_SID,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                       array('field' => KOLAB_ATTR_MAIL,
>> +                                             'op'    => '=',
>> +                                             'test'  => $id),
>> +                                   ),
>> +                             ),
>> +                         ),
>> +        );
>> +        $filter   = $this->searchQuery($criteria);
>> +
>>          $result = $this->_attrsForFilter($filter, array('mail', 'alias'),
>>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------



From issues at kolab.org  Mon Feb 22 15:14:13 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 22 Feb 2010 14:14:13 +0000
Subject: [Kolab-devel] [issue4153] EmailValidator: doesn't allow to type a
	'.' in front of	'@'
In-Reply-To: <1266848053.95.0.192695475301.issue4153@kolab.org>
Message-ID: <1266848053.95.0.192695475301.issue4153@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

(Testable in both New Certificate... and Add User-ID...)

Type [marc at kdab.com]
Position the cursor: [marc|@kdab.com]
Type '.', intending to type ".mutz": Doesn't work. Expected: should become 
incomplete, not invalid (ie. should accept the character).

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23687
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: EmailValidator: doesn't allow to type a '.' in front of '@'

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4153>
______________________________________


From issues at kolab.org  Mon Feb 22 16:10:32 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 22 Feb 2010 15:10:32 +0000
Subject: [Kolab-devel] [issue4154] Add User-ID doesn't take admin
	restrictions from	[CertificateCreationWizard] into account
In-Reply-To: <1266851432.38.0.207406935087.issue4154@kolab.org>
Message-ID: <1266851432.38.0.207406935087.issue4154@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

1. Add this:
    [CertificateCreationWizard]
    EMAIL_regex=.*@kdab.com
   to your kleopatrarc.
2. Start kleopatra]
3. Right-click a secret key -> Add User-ID...
4. Type something into the 'Real Name' field, so it becomes valid.
5. Type 'foo at kdab.net' into the 'Email address' field
=> OK
Expected: since foo at kdab.net doesn't match .*@kdab.com, the OK button should 
not be enabled, and an error message shown.

See also issue 4133

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23689
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: Add User-ID doesn't take admin restrictions from [CertificateCreationWizard] into account

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4154>
______________________________________


From issues at kolab.org  Tue Feb 23 00:07:57 2010
From: issues at kolab.org (kman)
Date: Mon, 22 Feb 2010 23:07:57 +0000
Subject: [Kolab-devel] [issue4155] webadmin shows blank page
In-Reply-To: <1266880077.43.0.0191586745261.issue4155@kolab.org>
Message-ID: <1266880077.43.0.0191586745261.issue4155@kolab.org>


New submission from kman <s.kuhlmann at congos.nl>:

Even though I did this: 
http://wiki.kolab.org/index.php/Kolab2_Server_Troubleshooting_-
_Web_admin#The_webadmin_returns_an_empty_page_without_any_error_message

I still have a absolute blank page and I don't see anything in my logs.. 

I'm running Debian Lenny on my box.

----------
files: info.php.htm
messages: 23695
nosy: staaf
priority: urgent
status: unread
title: webadmin shows blank page

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4155>
______________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20100222/788a03bd/info.php-0001.htm

From issues at kolab.org  Tue Feb 23 10:38:15 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 09:38:15 +0000
Subject: [Kolab-devel] [issue4156] 'No data' trying to decrypt/verify a .p7s
	file (S/MIME	signed-opaque)
In-Reply-To: <1266917895.24.0.081054869501.issue4156@kolab.org>
Message-ID: <1266917895.24.0.081054869501.issue4156@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

.p7s files are created by Kleopatra through sign-only of an archive.
1. Call Decrypt/Verify... from GpgEX or
   Decrypt/Verify Files... from Kleopatra's UI on such a file
2. Hit button 'Decrypt/Verify'
=> Error: No Data

This comes from gpgsm. Apparently, due to the lack of support for combined 
sign/encrypt operations, gpgme_op_decrypt_verify in fact just tries to do 
decryption, which fails with GPG_ERR_NO_DATA (naturally, as there's no 
ciphertext). This works fine with gpg (GPGME_PROTOCOL_OpenPGP): it will report 
a null decrypt result, and Kleopatra ignores this, and a verify result that 
Kleopatra uses.

This algorithm fails for CMS, though.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23698
nosy: bernhard, emanuel, marc, till, werner
priority: urgent
status: unread
title: 'No data' trying to decrypt/verify a .p7s file (S/MIME signed-opaque)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4156>
______________________________________


From issues at kolab.org  Tue Feb 23 11:00:47 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 10:00:47 +0000
Subject: [Kolab-devel] [issue4157] No working link in verify result html for
	emails with IDN	domains.
In-Reply-To: <1266919247.45.0.242256434072.issue4157@kolab.org>
Message-ID: <1266919247.45.0.242256434072.issue4157@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

When verifying files signed with my sign-only s/mime certificate 0xB70DC229, 
which has a primary email with an IDNA domain part, I get the following in the 
debug output:
  kleopatra(25533) KMime::Types::Mailbox::setAddress: Invalid address
and the link around the email address in the result HTML do nothing.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23701
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: No working link in verify result html for emails with IDN domains.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4157>
______________________________________


From issues at kolab.org  Tue Feb 23 11:29:26 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 10:29:26 +0000
Subject: [Kolab-devel] [issue4158] key:// link not workin in verify result
	html
In-Reply-To: <1266920966.14.0.610689795005.issue4158@kolab.org>
Message-ID: <1266920966.14.0.610689795005.issue4158@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

Copy of issue 4157
Separate issues.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23706
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: key:// link not workin in verify result html

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4158>
______________________________________


From issues at kolab.org  Tue Feb 23 12:07:44 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 11:07:44 +0000
Subject: [Kolab-devel] [issue4159] SignEncryptEMailConflictDialog comes up
	when OpenPGP is	clear choice
In-Reply-To: <1266923264.75.0.318814355953.issue4159@kolab.org>
Message-ID: <1266923264.75.0.318814355953.issue4159@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

>From Emanuel's mail:
  - import own OpenPGP and SMIME-Certificate; open another public certificate
    A -> mail sig/enc to A -> kleo shows (collapsed) conflict dialog (not
    really a conflict as OpenPGP in unambiguous, after all). One example where
    the power-user-mode doesn't work yet.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23711
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: SignEncryptEMailConflictDialog comes up when OpenPGP is clear choice

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4159>
______________________________________


From issues at kolab.org  Tue Feb 23 12:23:19 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 11:23:19 +0000
Subject: [Kolab-devel] [issue4160] SignEncryptEMailConflictDialog should
	exclude expired	certificates from matching
In-Reply-To: <1266924199.5.0.620319761599.issue4160@kolab.org>
Message-ID: <1266924199.5.0.620319761599.issue4160@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

When I send as marc at kdab.com, I get a conflict between my work/2009 and 
work/2010 certificates, even though the former is already expired.
Expected: choose work/2010, don't present work/2009.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23715
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: SignEncryptEMailConflictDialog should exclude expired certificates from matching

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4160>
______________________________________


From issues at kolab.org  Tue Feb 23 14:20:47 2010
From: issues at kolab.org (Arvid Requate)
Date: Tue, 23 Feb 2010 13:20:47 +0000
Subject: [Kolab-devel] [issue4161] DIMP not selectable in kolab-webclient
	login with auth	driver kolab
In-Reply-To: <1266931247.5.0.278793023087.issue4161@kolab.org>
Message-ID: <1266931247.5.0.278793023087.issue4161@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

With auth driver kolab there is no dropdown to select DIMP on user login.
I am currently not aware of any other way to preselect DIMP on a per user or
even a site-wide setting. Tested with horde-1.2-0 with kolab 2.2 branch patches from
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

The kolab auth driver is needed to call uid-to-email mapping hooks.

----------
keyword: web client
messages: 23717
nosy: requate, wrobel
status: unread
title: DIMP not selectable in kolab-webclient login with auth driver kolab

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4161>
______________________________________


From issues at kolab.org  Tue Feb 23 15:49:05 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 14:49:05 +0000
Subject: [Kolab-devel] [issue4162] Crash when PREP_ENCRYPT, (SIGN,
	) ENCRYPT cycle wasn't completed.
In-Reply-To: <1266936545.93.0.376806550888.issue4162@kolab.org>
Message-ID: <1266936545.93.0.376806550888.issue4162@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

To reproduce:
1. Start Kleopatra
2. call gpg-connect-agent -S ~/.gnupg/S.uiserver and type in:
   /serverpid
   session 123 Re: Letter received
   sender --info -- sender at example.org
   recipient recipient at example.org
   prep_encrypt --expect-sign
   bye
3. Resolve the certificates in the dialog, click OK.
4. Quit Kleopatra
=> Crash, caused by deleting after the death of QApplication the dialog held
   in flight waiting for the following SIGN and/or ENCRYPT commands.
Expected: no crash.

Only minor bug since this should never happen in practice.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23721
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: Crash when PREP_ENCRYPT, (SIGN,) ENCRYPT cycle wasn't completed.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4162>
______________________________________


From issues at kolab.org  Tue Feb 23 16:59:14 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 15:59:14 +0000
Subject: [Kolab-devel] [issue4163] Implement checksum uiserver commands in
	Kleopatra and	gpgex.
In-Reply-To: <1266940754.87.0.260301106529.issue4163@kolab.org>
Message-ID: <1266940754.87.0.260301106529.issue4163@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

First implement in Kleopatra, so we know whether we can support the spec easily 
(turned out we can't easily support --allow-delete=false), then in gpgex.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23726
nosy: emanuel, marc
priority: feature
status: unread
title: Implement checksum uiserver commands in Kleopatra and gpgex.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4163>
______________________________________


From issues at kolab.org  Tue Feb 23 17:01:26 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Feb 2010 16:01:26 +0000
Subject: [Kolab-devel] [issue4164] Recursive sign/encrypt doesn't work on
	Windows.
In-Reply-To: <1266940886.92.0.864967732619.issue4164@kolab.org>
Message-ID: <1266940886.92.0.864967732619.issue4164@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

It should work with the latest fixes (Marcus got it to work), but Marc should 
test this himself and provide a working libkleopatrarc for - eg - 7zip.

----------
assignedto: marc
keyword: gpg4win2, kleo, windows
messages: 23727
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: Recursive sign/encrypt doesn't work on Windows.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4164>
______________________________________


From paul at kdab.com  Tue Feb 23 18:43:19 2010
From: paul at kdab.com (Paul James Adams)
Date: Tue, 23 Feb 2010 17:43:19 +0000
Subject: [Kolab-devel] Introductions
In-Reply-To: <201002161237.35200.greve@intevation.de>
References: <201002161237.35200.greve@intevation.de>
Message-ID: <201002231743.20294.paul@kdab.com>

Hello all,

On Tuesday 16 Feb 2010 11:37:34 Georg C. F. Greve wrote:
> ultimately Bernhard and Till managed to
> convince myself and Dr. Paul Adams (who I will let introduce himself) to
> drive the process of re-launching the Kolab business into a new company
> that should bring more energy, developers, customers and partners into
> Kolab.

I am the aforementioned Dr. Paul Adams (just "Paul" will do, "padams" on 
Freenode). My background is in researching the productivity of Free Software 
projects and, in particular, the impact of the SCM choice on productivity.

You may also know me as:
- Co-founder and former chairman of the British Computer Society's Open Source 
Special Interest Group
- A Zope/Plone contributor (you would really need to stretch your brain to 
remember this)
- A KDE community member (I conduct research into KDE community/productivity 
issues)

I do not have much more to add with regards to what the new business will be 
up to. Certainly nothing to add to what Georg has already stated.

I look forward to working with you all in growing Kolab and its ecosystem.


Paul

-- 
Paul J. Adams | paul at kdab.com | Software Engineer
Klar?lvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


From soliva at comcept.ch  Wed Feb 24 05:43:04 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 24 Feb 2010 05:43:04 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <20100221213127.13847dslqpb1et4w@webmail.pardus.de>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch><20100215100000.59382tahnkzoqk9c@webmail.pardus.de><001b01caaf2e$5ffbbbd0$1ff33370$@ch><20100221141511.16204oxc0nmucpic@webmail.pardus.de><000001cab302$da1eab70$8e5c0250$@ch>
	<20100221213127.13847dslqpb1et4w@webmail.pardus.de>
Message-ID: <001601cab50b$da800090$8f8001b0$@ch>

Hi Gunnar

This works meaning created a new user using a "," or "=" in the First Name
for test:

Type    Name                        E-mail               uid
U       Test User, Andrea,Soliva    test1 at comcept-net.ch
test1 at comcept-net.ch
U       Test User, Andrea=Soliva    test2 at comcept-net.ch
test2 at comcept-net.ch

This works also meaning created a new user using a "," or "=" in the Last
Name for test:

Type    Name                        E-mail               uid
U       Test,User, Andrea Soliva    test3 at comcept-net.ch
test3 at comcept-net.ch
U       Test=User, Andrea Soliva    test4 at comcept-net.ch
test4 at comcept-net.ch

I don't think that this should work correct? I thinks this works "probably
only on my system" because the "," or "=" is not really used in the
background because I deleted afterward the test3 at comcept-net.ch as
test4 at comcept-net.ch and it appears on the Webpage a confirmation:

"The user with DN cn=Andrea Soliva Test\2CUser,dc=comcept-net,dc=ch has been
deleted"
"The user with DN cn=Andrea Soliva Test\3DUser,dc=comcept-net,dc=ch has been
deleted"

This means "=" is used as "/3D" and for ";" is used "/2C".

In the log for creating the user nothing specially appears except the normal
entry:

==> /kolab/var/apache/log/apache-access.log <==
192.168.101.11 - - [24/Feb/2010:05:29:43 +0100] "GET /admin/user/ HTTP/1.1"
200 14475
192.168.101.11 - - [24/Feb/2010:05:29:58 +0100] "GET
/admin/user/user.php?action=create HTTP/1.1" 200 10501

If you need mor tell me

Kind regards

Andrea Soliva

Mail: soliva at comcept.ch 

-----Urspr?ngliche Nachricht-----
Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Sonntag, 21. Februar 2010 21:31
An: kolab-devel at kolab.org
Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> Man thanks fort he hint and I modified the file as in your patch shown:
>
>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
> ---------------
>
>
>            411    // Count the number of occurences of an email address
>            412    // in users' mail and alias attributes and in dist.
lists.
>            413    // This can be used to check for uniqueness etc.
>            412    // in users' mail and alias attributes and in dist.
lists.
>            413    // This can be used to check for uniqueness etc.
>            414    function countMail( $base, $mail , $excludedn=false ) {
>            415          // First count users
>            416          $filter = '(|(|(mail='.$this->escape($mail).')
>            417                         (alias='.$this->escape($mail).')
>            418                       )
>            419                       (uid='.$this->escape($mail).')
>            420                     )';
>            421  //      $res = $this->search( $this->dn_escape($base),
> $filter, array( 'dn' ) );
>            422          $res = $this->search( $base, $filter, array( 'dn'
)
> );
>            423          $count = 0;
>            424
>            425          $entries = ldap_get_entries( $this->connection,
$res
> );
>            426          if( $excludedn ) {
>            427            for ( $i = 0; $i < count( $entries ); $i++ ) {
>            428  //              if( is_null( $entries[$i] ) ) continue;
>            429                  if( !isset($entries[$i]) || is_null(
> $entries[$i] ) ) continue;
>            430                  if(
> KolabLDAP::unescape_dn_value($entries[$i]['dn']) ==
> KolabLDAP::unescape_dn_value($excludedn) ) continue;
>            431                  debug("found ".$entries[$i]['dn'] );
>            432                  $count++;
>
>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
> ---------------
>
> After that I created a new user, modified as deleted the user without any
> warnings etc. in the log /kolab/var/apache/log/php/php-errors.log. From
this
> point it seems the warning are gone. I saw somewhere also in the devel
> messages (can not remember anymore) that without this patch it is possible
> to configure a mail alias to two different uid's (users)?
> Right....?

Correct.

> .....after the patch this is not possible meaning a warning is
> shown/poping up that this alias is already set to another uid/user etc.

Nice. Many thanks for the feedback!

>
> As mentioned I did not find anything else after the patch was applied
> meaning warnings, errros etc. even I manipulated the new user I created
for
> the test in different ways. Hope this helps and if you need more tests or
> wathever give me a hint.

If you want, you can check if creating users that contain a "," or a  
"=" in the first or last name works as well.

That was what the original patch was actually about. Breaking the  
countMail() function was an undesired side effect.

Cheers,

Gunnar

>
> Many thnks and kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Sonntag, 21. Februar 2010 14:15
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi Gunnar
>>
>> No problem can give a try...give me a hint as soon as the patch is
>> available....
>
> Here it is: http://kolab.org/pipermail/kolab-commits/2010q1/011956.html
>
> Cheers,
>
> Gunnar
>
>>
>> Kind regards
>>
>> Andrea
>>
>> Mail: soliva at comcept.ch
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Montag, 15. Februar 2010 10:00
>> An: kolab-devel at kolab.org
>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Hi Andrea,
>>
>> actually the error you see is probably a side effect of the bug I
>> introduced with the fix for https://issues.kolab.org/issue3499. I'll
>> try to provide a patch for that today. Please add yourself in nosy
>> there. Would be great if you could provide feedback if that works.
>>
>> Cheers,
>>
>> Gunnar
>>
>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>
>>> Hi Gunnar
>>>
>>> Sorry was in holidays for a fiew days :-)
>>>
>>> I tried to include your suggested stuff "var_dump($base);" in the Code
> of:
>>>
>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>>>
>>> But as a pity without success....I'm not so familar with php :-( can you
>>> please advice how you would include it.
>>>
>>> Regarding your suggstion what the symptomes are if this error occurs
>>> following:
>>>
>>> The error occures "ONLY" if a user is added or modified within the
> manager
>>> interface. It happens also if a Distribution List ist added or modified.
>> For
>>> the manager itself which add's or modifies the users or distribution
list
>> on
>>> the manager interface nothing occured meanining I added over 20 domains
>> with
>>> 50 email address's and aliases but I never was kicked out or saw a blank
>>> white page or a error from php or whatever. I'm using kolab since years
>> and
>>> this never occoured but I have to say what I did this time was to add a
>>> Domain Maintainer which I never used before...could this be the reason?
> If
>> I
>>> looked in as the Domain Maintainer and added a user I had some kick outs
>> and
>>> blank white pages? I have a strange feeling about this function but that
>> we
>>> have no misunderstandig at all as Kolab Manager I had never blank pages
> or
>>> uncontrolled kicke outs.
>>>
>>> If you could advice where to add the code etc. I can follow up on
> this....
>>>
>>> PS: One more thing which you are probably interessted....I did in
rc.conf
>>> template a modification....this means in the past for config the entry
in
>>> this file was:
>>>
>>> openldap_url="ldap:// ldaps://"
>>>
>>> This was working fine without any problems...in the newewst version the
>>> entry is:
>>>
>>> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>>>
>>> This was given errors and a lot of problems because the real entry in
the
>>> /kolab/etc/rc.conf was looking:
>>>
>>> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>>>
>>> This does not work and I changed to 127.0.0.1 or back to the old style.
>> Both
>>> is working fine:
>>>
>>> openldap_url="ldap:// ldaps://"
>>>
>>> I do not think so that this has something to do with the issue which we
>> are
>>> discussion here even I do not understand the
>> "openldap_url="ldap://0.0.0.0/
>>> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
>> the
>>> bind_addr did not work as expected because I'm using Kolab in a Solaris
>> Zone
>>> and the localhost as the 127.0.0.1 is handled in some circumstances in
>>> another way.....this only for your information. I documented the overall
>>> stuff on the Wiki:
>>>
>>> https://wiki.kolab.org/index.php/Solaris
>>>
>>>
>>> Kind regards
>>>
>>> Andrea
>>>
>>> Mail: soliva at comcept.ch
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>>> kolab-devel-bounces at kolab.org
>>> Gesendet: Donnerstag, 11. Februar 2010 22:10
>>> An: kolab-devel at kolab.org
>>> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>>
>>> Hi Andrea,
>>>
>>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>>
>>>> Hi
>>>>
>>>> It is from my point of view clear the search function but even I see
the
>>>> lines I can not identify what is false and why?:
>>>>
>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>> 204
>>>>
>>>>
>>>> 201    function search( $base, $filter, $attrs = false ) {
>>>>    202      $this->freeSearchResult();
>>>>    203      if( $attrs ) {
>>>>    204            $this->search_result = ldap_search(
$this->connection,
>>>> $base, $filter, $attrs );
>>>>    205          } else {
>>>>    206            $this->search_result = ldap_search(
$this->connection,
>>>> $base, $filter );
>>>>    207          }
>>>>    208      return $this->search_result;
>>>>    209    }
>>>
>>> The error sounds as if $base contains an invalid value. You could add
>>> a "var_dump($base);" in the code to display the value.
>>>
>>> Both log entries you mentioned are just warnings though. The code
>>> won't stop on a warning. And the code of the web admin is not exactly
>>> clean when it comes to notices and warnings. Quite the contrary. So
>>> what you see might not be a real problem.
>>>
>>> But I did not quite understand what kind of problems you saw in the
>>> actual frontend. Did you see any specific errors that were displayed?
>>> Or did the web admin just show you a blank page (the PHP white screen
>>> of death)?
>>>
>>> Cheers,
>>>
>>> Gunnar
>>>
>>>>
>>>>
>>>> is not a valid ldap result resource in
>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>
>>>>    411    // Count the number of occurences of an email address
>>>>    412    // in users' mail and alias attributes and in dist. lists.
>>>>    413    // This can be used to check for uniqueness etc.
>>>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>>>    415          // First count users
>>>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>>>    417                         (alias='.$this->escape($mail).')
>>>>    418                       )
>>>>    419                       (uid='.$this->escape($mail).')
>>>>    420                     )';
>>>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>>>> array( 'dn' ) );
>>>>    422          $count = 0;
>>>>    423
>>>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>>>    425          if( $excludedn ) {
>>>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>>>    427                  if( is_null( $entries[$i] ) ) continue;
>>>>    428                  if(
>>> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>>>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>>>    429                  debug("found ".$entries[$i]['dn'] );
>>>>    430                  $count++;
>>>>    431            }
>>>>    432          } else $count += $entries['count'];
>>>>
>>>>
>>>> Kind regards
>>>>
>>>> Andrea Soliva
>>>>
>>>> Mail: soliva at comcept.ch
>>>> -----Urspr?ngliche Nachricht-----
>>>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>>>> kolab-devel-bounces at kolab.org
>>>> Gesendet: Montag, 25. Januar 2010 14:37
>>>> An: kolab-devel at kolab.org
>>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax
> function.ldap-search
>>>>
>>>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
>> DN
>>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on
line
>>>> 204
>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
>>> argument
>>>>> is not a valid ldap result resource in
>>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>>
>>>>> Is this already recognized? Is it not known....I tried to figure out
>> what
>>>>> is wrong but actually I could not?!
>>>>>
>>>>> Any suggestion?
>>>>
>>>> My suggestion is to check the given line 204 and see which argument
>>>> is used there (maybe add a statement to print it out).
>>>>
>>>>> By the way is there a documentation about Master/Slave configuration
>>>>> meaning how this works etc. I could not find anything. Any hints would
>> be
>>>>> appriciated.
>>>>
>>>> I think the documentation is in the architecture documents.
>>>> The idea is pretty simple: Replicate the directory server on the slave
>>>> (for which there is a bootstrap) have all read access on the slave
>>> accounts
>>>> go
>>>> to the slave LDAP server and all write access (only by webadmin) to the
>>>> master.
>>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> Kolab-devel mailing list
>>>> Kolab-devel at kolab.org
>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>>
>>>
>>>
>>>
>>> --
>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>>
>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>>> --------------------------------------------------------------------
>>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>> --------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Kolab-devel mailing list
>>> Kolab-devel at kolab.org
>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>
>>> _______________________________________________
>>> 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 <<
>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> 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 <<
> --------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


_______________________________________________
Kolab-devel mailing list
Kolab-devel at kolab.org
https://kolab.org/mailman/listinfo/kolab-devel


From issues at kolab.org  Wed Feb 24 10:05:30 2010
From: issues at kolab.org (Arvid Requate)
Date: Wed, 24 Feb 2010 09:05:30 +0000
Subject: [Kolab-devel] [issue4165] kolab-webclient does not show shared/
	calendar and	contact folders
In-Reply-To: <1267002330.51.0.00887977796555.issue4165@kolab.org>
Message-ID: <1267002330.51.0.00887977796555.issue4165@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

kolab-webclient does not show shared calendar and contact folders stored on a
kolab server configured with unixhierarchysep. The attached patch shows the
lines that need fixing. The current code seems to expect unixhierarchysep for
'user'-Subfolders but not for 'shared'.
Tested with horde-1.2-0 with kolab 2.2 branch patches from
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

----------
keyword: web client
messages: 23735
nosy: requate, wrobel
status: unread
title: kolab-webclient does not show shared/ calendar and contact folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4165>
______________________________________


From issues at kolab.org  Wed Feb 24 10:25:27 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Feb 2010 09:25:27 +0000
Subject: [Kolab-devel] [issue4166] Crash while navigation between components
	(rt#6037)
In-Reply-To: <1267003527.53.0.0653553374422.issue4166@kolab.org>
Message-ID: <1267003527.53.0.0653553374422.issue4166@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact e35 kdepim 20100212.1089100-kk1
The customer reported crashes.

The users click many times of different component buttons in the navigation pane
at the left side. Then it crashs.

I cannot reproduce this problem. Added a backtrace.

----------
assignedto: allen
files: kontact.crash
keyword: enterprise35, kde client, kkc
messages: 23736
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Crash while navigation between components (rt#6037)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4166>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact.crash
Type: application/octet-stream
Size: 4450 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100224/ec3a202d/kontact.exe

From issues at kolab.org  Wed Feb 24 19:49:08 2010
From: issues at kolab.org (Arvid Requate)
Date: Wed, 24 Feb 2010 18:49:08 +0000
Subject: [Kolab-devel] [issue4167] kolab-webclient patch for resolution of
	group ACLs on	shared folders
In-Reply-To: <1267037348.36.0.363198680807.issue4167@kolab.org>
Message-ID: <1267037348.36.0.363198680807.issue4167@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

The attached patch fixes a problem with the resolution of group ACLs for shared
folders. Without the patch group ACLs have not been evaluated and shared folders
did not show up unless there was an explicit ACL for the user.

Tested with horde-1.2-0 with kolab 2.2 branch patches from
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

----------
files: t_framework_UV_fixed_group_permissions.diff
keyword: web client
messages: 23740
nosy: requate, wrobel
status: unread
title: kolab-webclient patch for resolution of group ACLs on shared folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4167>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t_framework_UV_fixed_group_permissions.diff
Type: text/x-diff
Size: 2304 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100224/7e348af0/t_framework_UV_fixed_group_permissions.bin

From issues at kolab.org  Thu Feb 25 14:43:19 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Feb 2010 13:43:19 +0000
Subject: [Kolab-devel] [issue4168] task with recurrence are not displayed in
	the calendar	agenda view.
In-Reply-To: <1267105399.68.0.48293266528.issue4168@kolab.org>
Message-ID: <1267105399.68.0.48293266528.issue4168@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100219.1095506-kk3

Test:
0. Switch to the too component.
1. Create a task with daily recurrence, start time/date and end time/date.
2. Switch to the calendar component.
3. Activate agenda view.
4. Look at the time of the to-do.
=> The to-dos are not displayed. (wrong)
5. Switch to month view.
=> The to-dos are displayed. (right)

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23749
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: task with recurrence are not displayed in the calendar agenda view.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4168>
______________________________________


From thomas at intevation.de  Thu Feb 25 16:29:39 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Thu, 25 Feb 2010 16:29:39 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
Message-ID: <20100225150155.723599004.thomas@intevation.de>

Hi!

I think everyone agrees that we want to get away from CVS, primary
reasons for this is to be able to move files around without breaking
their history and to get a single revision number to identify
builds, which is important e.g. for automated builds.

Although we will continue to use a central public repository, some
of the developers (including Sascha and me) want the ability to do
refactoring or bigger changes without interrupting the work of
others or just do some local modifications for testing or for
customers and still be able to commit often to save their progress
and to split their work in smaller parts which can be reviewed more
easily. Therefore (and for some other reasons) the next SCM will not
be Subversion, but a distributed SCM.

Main contenders for this are Mercurial (hg) and git, but for the
following reasons we see Mercurial as the better choice for the
development of Kolab Server:

- Intevation has expert knowledge and operating experience in
  Mercurial while only user experience in git.
- The web interface offers simple and short URLs for downloading
  single files or patches, this is already used with the viewcvs
  interface for user documentation and for patches which have to be
  applied to e.g. Cyrus imapd to add features required by the
  server.
- Usage of Mercurial is easier to learn for people already knowing
  CVS or Subversion, because the UI is quite similar, see e.g.
  http://mercurial.selenic.com/quickstart/ or
  http://mercurial.selenic.com/wiki/CvsCommands

So I would like to ask for short feedback (as I do not want to spend
too much time on discussion if everyone already is happy enough with
this) about what you think about switching to Mercurial.

Please choose one of:
+1 (I want it)
 0 (I can live with it)
-1 (I do not agree, please add a short rationale)

Deadline for this poll is next Thursday, March 4th, 12:00 UTC.

If we get a negative result, we will start a more in-depth
discussion.

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/20100225/d6310277/attachment.bin

From david at dasz.at  Thu Feb 25 16:19:45 2010
From: david at dasz.at (David Schmitt)
Date: Thu, 25 Feb 2010 16:19:45 +0100
Subject: [Kolab-devel] Simple connectors for Android and Outlook
Message-ID: <4B869511.3090500@dasz.at>

Hi, everyone!


We are proud to announce the first developer preview of our Kolab sync 
clients for both Android and Outlook. Both are licensed under the GPLv3.


Please join us on the respective project pages:

   http://code.google.com/p/kolab-outlook/
   http://code.google.com/p/kolab-android/


We appreciate feedback both here and on the issue tracker.


Regards, David Schmitt

-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg


From issues at kolab.org  Thu Feb 25 17:22:19 2010
From: issues at kolab.org (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 16:22:19 +0000
Subject: [Kolab-devel] [issue4169] kolab-webclient sometimes shows a blank
	page on login
In-Reply-To: <1267114939.91.0.316828676949.issue4169@kolab.org>
Message-ID: <1267114939.91.0.316828676949.issue4169@kolab.org>


New submission from Gunnar Wrobel <p at rdus.de>:

There have been several reports on the mailing lists about this issue. Only
removing the cookie helps.

My current guess: It is probably Kolab specific and likely linked to the loading
of incorrect session data. A "var_dump($_SESSION);" right after the session has
been reloaded might give some valuable information.

----------
assignedto: wrobel
keyword: web client
messages: 23755
nosy: bernhard, gavinmc, martin, thomas, wilde, wrobel
priority: urgent
status: unread
title: kolab-webclient sometimes shows a blank page on login

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4169>
______________________________________


From wrobel at pardus.de  Thu Feb 25 17:31:14 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 17:31:14 +0100
Subject: [Kolab-devel] Introductions
In-Reply-To: <201002231743.20294.paul@kdab.com>
References: <201002161237.35200.greve@intevation.de>
	<201002231743.20294.paul@kdab.com>
Message-ID: <20100225173114.117592nrkvasj26q@webmail.pardus.de>

Quoting Paul James Adams <paul at kdab.com>:

> Hello all,
>
> On Tuesday 16 Feb 2010 11:37:34 Georg C. F. Greve wrote:
>> ultimately Bernhard and Till managed to
>> convince myself and Dr. Paul Adams (who I will let introduce himself) to
>> drive the process of re-launching the Kolab business into a new company
>> that should bring more energy, developers, customers and partners into
>> Kolab.
>
> I am the aforementioned Dr. Paul Adams (just "Paul" will do, "padams" on
> Freenode). My background is in researching the productivity of Free Software
> projects and, in particular, the impact of the SCM choice on productivity.
>
> You may also know me as:
> - Co-founder and former chairman of the British Computer Society's  
> Open Source
> Special Interest Group
> - A Zope/Plone contributor (you would really need to stretch your brain to
> remember this)
> - A KDE community member (I conduct research into KDE community/productivity
> issues)
>
> I do not have much more to add with regards to what the new business will be
> up to. Certainly nothing to add to what Georg has already stated.
>
> I look forward to working with you all in growing Kolab and its ecosystem.

Though I already mentioned this in person: It is very nice to have you  
two on board :)

Cheers,

Gunnar

>
>
> Paul
>
> --
> Paul J. Adams | paul at kdab.com | Software Engineer
> Klar?lvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
>
> _______________________________________________
> 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/20100225/c3b99021/attachment.bin

From wrobel at pardus.de  Thu Feb 25 17:46:05 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 17:46:05 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <001601cab50b$da800090$8f8001b0$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch><201001251436.49129.bernhard@intevation.de><000301caa013$021da340$0658e9c0$@ch><20100211221010.29291rrgipu49fe8@webmail.pardus.de><001101caad63$684e4d10$38eae730$@ch><20100215100000.59382tahnkzoqk9c@webmail.pardus.de><001b01caaf2e$5ffbbbd0$1ff33370$@ch><20100221141511.16204oxc0nmucpic@webmail.pardus.de><000001cab302$da1eab70$8e5c0250$@ch>
	<20100221213127.13847dslqpb1et4w@webmail.pardus.de>
	<001601cab50b$da800090$8f8001b0$@ch>
Message-ID: <20100225174605.12855uu6cszyni4g@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> This works meaning created a new user using a "," or "=" in the First Name
> for test:
>
> Type    Name                        E-mail               uid
> U       Test User, Andrea,Soliva    test1 at comcept-net.ch
> test1 at comcept-net.ch
> U       Test User, Andrea=Soliva    test2 at comcept-net.ch
> test2 at comcept-net.ch
>
> This works also meaning created a new user using a "," or "=" in the Last
> Name for test:
>
> Type    Name                        E-mail               uid
> U       Test,User, Andrea Soliva    test3 at comcept-net.ch
> test3 at comcept-net.ch
> U       Test=User, Andrea Soliva    test4 at comcept-net.ch
> test4 at comcept-net.ch

Thanks for the feedback!

>
> I don't think that this should work correct? I thinks this works "probably
> only on my system"

No it should actually work. Not only on your system :) It is okay if  
people use these characters in the LDAP attributes. There is no reason  
why they should not. Especially since we can't exect the users to know  
that we put the first and last name in the DN of the object (probably  
about to change with 2.3 anyhow) and that these character have special  
meaning in the DN of an LDAP object.

> because the "," or "=" is not really used in the
> background because I deleted afterward the test3 at comcept-net.ch as
> test4 at comcept-net.ch and it appears on the Webpage a confirmation:
>
> "The user with DN cn=Andrea Soliva Test\2CUser,dc=comcept-net,dc=ch has been
> deleted"
> "The user with DN cn=Andrea Soliva Test\3DUser,dc=comcept-net,dc=ch has been
> deleted"
>
> This means "=" is used as "/3D" and for ";" is used "/2C".

Correct. Escaping these characters in the right way was what I tried  
to patch for 2.2.3.

Cheers,

Gunnar

>
> In the log for creating the user nothing specially appears except the normal
> entry:
>
> ==> /kolab/var/apache/log/apache-access.log <==
> 192.168.101.11 - - [24/Feb/2010:05:29:43 +0100] "GET /admin/user/ HTTP/1.1"
> 200 14475
> 192.168.101.11 - - [24/Feb/2010:05:29:58 +0100] "GET
> /admin/user/user.php?action=create HTTP/1.1" 200 10501
>
> If you need mor tell me
>
> Kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Sonntag, 21. Februar 2010 21:31
> An: kolab-devel at kolab.org
> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>
> Hi Andrea,
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi Gunnar
>>
>> Man thanks fort he hint and I modified the file as in your patch shown:
>>
>>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
>> ---------------
>>
>>
>>            411    // Count the number of occurences of an email address
>>            412    // in users' mail and alias attributes and in dist.
> lists.
>>            413    // This can be used to check for uniqueness etc.
>>            412    // in users' mail and alias attributes and in dist.
> lists.
>>            413    // This can be used to check for uniqueness etc.
>>            414    function countMail( $base, $mail , $excludedn=false ) {
>>            415          // First count users
>>            416          $filter = '(|(|(mail='.$this->escape($mail).')
>>            417                         (alias='.$this->escape($mail).')
>>            418                       )
>>            419                       (uid='.$this->escape($mail).')
>>            420                     )';
>>            421  //      $res = $this->search( $this->dn_escape($base),
>> $filter, array( 'dn' ) );
>>            422          $res = $this->search( $base, $filter, array( 'dn'
> )
>> );
>>            423          $count = 0;
>>            424
>>            425          $entries = ldap_get_entries( $this->connection,
> $res
>> );
>>            426          if( $excludedn ) {
>>            427            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>            428  //              if( is_null( $entries[$i] ) ) continue;
>>            429                  if( !isset($entries[$i]) || is_null(
>> $entries[$i] ) ) continue;
>>            430                  if(
>> KolabLDAP::unescape_dn_value($entries[$i]['dn']) ==
>> KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>            431                  debug("found ".$entries[$i]['dn'] );
>>            432                  $count++;
>>
>>         --------------- /kolab/var/kolab/php/admin/include/ldap.class.php
>> ---------------
>>
>> After that I created a new user, modified as deleted the user without any
>> warnings etc. in the log /kolab/var/apache/log/php/php-errors.log. From
> this
>> point it seems the warning are gone. I saw somewhere also in the devel
>> messages (can not remember anymore) that without this patch it is possible
>> to configure a mail alias to two different uid's (users)?
>> Right....?
>
> Correct.
>
>> .....after the patch this is not possible meaning a warning is
>> shown/poping up that this alias is already set to another uid/user etc.
>
> Nice. Many thanks for the feedback!
>
>>
>> As mentioned I did not find anything else after the patch was applied
>> meaning warnings, errros etc. even I manipulated the new user I created
> for
>> the test in different ways. Hope this helps and if you need more tests or
>> wathever give me a hint.
>
> If you want, you can check if creating users that contain a "," or a
> "=" in the first or last name works as well.
>
> That was what the original patch was actually about. Breaking the
> countMail() function was an undesired side effect.
>
> Cheers,
>
> Gunnar
>
>>
>> Many thnks and kind regards
>>
>> Andrea Soliva
>>
>> Mail: soliva at comcept.ch
>> -----Urspr?ngliche Nachricht-----
>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>> kolab-devel-bounces at kolab.org
>> Gesendet: Sonntag, 21. Februar 2010 14:15
>> An: kolab-devel at kolab.org
>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>
>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>
>>> Hi Gunnar
>>>
>>> No problem can give a try...give me a hint as soon as the patch is
>>> available....
>>
>> Here it is: http://kolab.org/pipermail/kolab-commits/2010q1/011956.html
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>> Kind regards
>>>
>>> Andrea
>>>
>>> Mail: soliva at comcept.ch
>>>
>>> -----Urspr?ngliche Nachricht-----
>>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>>> kolab-devel-bounces at kolab.org
>>> Gesendet: Montag, 15. Februar 2010 10:00
>>> An: kolab-devel at kolab.org
>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>>
>>> Hi Andrea,
>>>
>>> actually the error you see is probably a side effect of the bug I
>>> introduced with the fix for https://issues.kolab.org/issue3499. I'll
>>> try to provide a patch for that today. Please add yourself in nosy
>>> there. Would be great if you could provide feedback if that works.
>>>
>>> Cheers,
>>>
>>> Gunnar
>>>
>>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>>
>>>> Hi Gunnar
>>>>
>>>> Sorry was in holidays for a fiew days :-)
>>>>
>>>> I tried to include your suggested stuff "var_dump($base);" in the Code
>> of:
>>>>
>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
>>>>
>>>> But as a pity without success....I'm not so familar with php :-( can you
>>>> please advice how you would include it.
>>>>
>>>> Regarding your suggstion what the symptomes are if this error occurs
>>>> following:
>>>>
>>>> The error occures "ONLY" if a user is added or modified within the
>> manager
>>>> interface. It happens also if a Distribution List ist added or modified.
>>> For
>>>> the manager itself which add's or modifies the users or distribution
> list
>>> on
>>>> the manager interface nothing occured meanining I added over 20 domains
>>> with
>>>> 50 email address's and aliases but I never was kicked out or saw a blank
>>>> white page or a error from php or whatever. I'm using kolab since years
>>> and
>>>> this never occoured but I have to say what I did this time was to add a
>>>> Domain Maintainer which I never used before...could this be the reason?
>> If
>>> I
>>>> looked in as the Domain Maintainer and added a user I had some kick outs
>>> and
>>>> blank white pages? I have a strange feeling about this function but that
>>> we
>>>> have no misunderstandig at all as Kolab Manager I had never blank pages
>> or
>>>> uncontrolled kicke outs.
>>>>
>>>> If you could advice where to add the code etc. I can follow up on
>> this....
>>>>
>>>> PS: One more thing which you are probably interessted....I did in
> rc.conf
>>>> template a modification....this means in the past for config the entry
> in
>>>> this file was:
>>>>
>>>> openldap_url="ldap:// ldaps://"
>>>>
>>>> This was working fine without any problems...in the newewst version the
>>>> entry is:
>>>>
>>>> openldap_url="ldap://@@@bind_addr@@@/ ldaps://@@@bind_addr@@@/"
>>>>
>>>> This was given errors and a lot of problems because the real entry in
> the
>>>> /kolab/etc/rc.conf was looking:
>>>>
>>>> openldap_url="ldap://0.0.0.0/ ldaps://0.0.0.0/"
>>>>
>>>> This does not work and I changed to 127.0.0.1 or back to the old style.
>>> Both
>>>> is working fine:
>>>>
>>>> openldap_url="ldap:// ldaps://"
>>>>
>>>> I do not think so that this has something to do with the issue which we
>>> are
>>>> discussion here even I do not understand the
>>> "openldap_url="ldap://0.0.0.0/
>>>> ldaps://0.0.0.0/". Looks for me funny and not usable. My opinion is that
>>> the
>>>> bind_addr did not work as expected because I'm using Kolab in a Solaris
>>> Zone
>>>> and the localhost as the 127.0.0.1 is handled in some circumstances in
>>>> another way.....this only for your information. I documented the overall
>>>> stuff on the Wiki:
>>>>
>>>> https://wiki.kolab.org/index.php/Solaris
>>>>
>>>>
>>>> Kind regards
>>>>
>>>> Andrea
>>>>
>>>> Mail: soliva at comcept.ch
>>>>
>>>> -----Urspr?ngliche Nachricht-----
>>>> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
>>>> kolab-devel-bounces at kolab.org
>>>> Gesendet: Donnerstag, 11. Februar 2010 22:10
>>>> An: kolab-devel at kolab.org
>>>> Betreff: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
>>>>
>>>> Hi Andrea,
>>>>
>>>> Quoting ComCept Soliva <soliva at comcept.ch>:
>>>>
>>>>> Hi
>>>>>
>>>>> It is from my point of view clear the search function but even I see
> the
>>>>> lines I can not identify what is false and why?:
>>>>>
>>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
>>>> 204
>>>>>
>>>>>
>>>>> 201    function search( $base, $filter, $attrs = false ) {
>>>>>    202      $this->freeSearchResult();
>>>>>    203      if( $attrs ) {
>>>>>    204            $this->search_result = ldap_search(
> $this->connection,
>>>>> $base, $filter, $attrs );
>>>>>    205          } else {
>>>>>    206            $this->search_result = ldap_search(
> $this->connection,
>>>>> $base, $filter );
>>>>>    207          }
>>>>>    208      return $this->search_result;
>>>>>    209    }
>>>>
>>>> The error sounds as if $base contains an invalid value. You could add
>>>> a "var_dump($base);" in the code to display the value.
>>>>
>>>> Both log entries you mentioned are just warnings though. The code
>>>> won't stop on a warning. And the code of the web admin is not exactly
>>>> clean when it comes to notices and warnings. Quite the contrary. So
>>>> what you see might not be a real problem.
>>>>
>>>> But I did not quite understand what kind of problems you saw in the
>>>> actual frontend. Did you see any specific errors that were displayed?
>>>> Or did the web admin just show you a blank page (the PHP white screen
>>>> of death)?
>>>>
>>>> Cheers,
>>>>
>>>> Gunnar
>>>>
>>>>>
>>>>>
>>>>> is not a valid ldap result resource in
>>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>>
>>>>>    411    // Count the number of occurences of an email address
>>>>>    412    // in users' mail and alias attributes and in dist. lists.
>>>>>    413    // This can be used to check for uniqueness etc.
>>>>>    414    function countMail( $base, $mail , $excludedn=false ) {
>>>>>    415          // First count users
>>>>>    416          $filter = '(|(|(mail='.$this->escape($mail).')
>>>>>    417                         (alias='.$this->escape($mail).')
>>>>>    418                       )
>>>>>    419                       (uid='.$this->escape($mail).')
>>>>>    420                     )';
>>>>>    421          $res = $this->search( $this->dn_escape($base), $filter,
>>>>> array( 'dn' ) );
>>>>>    422          $count = 0;
>>>>>    423
>>>>>    424          $entries = ldap_get_entries( $this->connection, $res );
>>>>>    425          if( $excludedn ) {
>>>>>    426            for ( $i = 0; $i < count( $entries ); $i++ ) {
>>>>>    427                  if( is_null( $entries[$i] ) ) continue;
>>>>>    428                  if(
>>>> KolabLDAP::unescape_dn_value($entries[$i]['dn'])
>>>>> == KolabLDAP::unescape_dn_value($excludedn) ) continue;
>>>>>    429                  debug("found ".$entries[$i]['dn'] );
>>>>>    430                  $count++;
>>>>>    431            }
>>>>>    432          } else $count += $entries['count'];
>>>>>
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Andrea Soliva
>>>>>
>>>>> Mail: soliva at comcept.ch
>>>>> -----Urspr?ngliche Nachricht-----
>>>>> Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
>>>>> kolab-devel-bounces at kolab.org
>>>>> Gesendet: Montag, 25. Januar 2010 14:37
>>>>> An: kolab-devel at kolab.org
>>>>> Betreff: Re: [Kolab-devel] Search: Invalid DN syntax
>> function.ldap-search
>>>>>
>>>>> Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
>>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
>>>>>> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid
>>> DN
>>>>>> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on
> line
>>>>> 204
>>>>>> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied
>>>> argument
>>>>>> is not a valid ldap result resource in
>>>>>> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>>>>>>
>>>>>> Is this already recognized? Is it not known....I tried to figure out
>>> what
>>>>>> is wrong but actually I could not?!
>>>>>>
>>>>>> Any suggestion?
>>>>>
>>>>> My suggestion is to check the given line 204 and see which argument
>>>>> is used there (maybe add a statement to print it out).
>>>>>
>>>>>> By the way is there a documentation about Master/Slave configuration
>>>>>> meaning how this works etc. I could not find anything. Any hints would
>>> be
>>>>>> appriciated.
>>>>>
>>>>> I think the documentation is in the architecture documents.
>>>>> The idea is pretty simple: Replicate the directory server on the slave
>>>>> (for which there is a bootstrap) have all read access on the slave
>>>> accounts
>>>>> go
>>>>> to the slave LDAP server and all write access (only by webadmin) to the
>>>>> master.
>>>>>
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> Kolab-devel mailing list
>>>>> Kolab-devel at kolab.org
>>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>>>
>>>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>>>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>>>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>>>> --------------------------------------------------------------------
>>>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>>> --------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Kolab-devel mailing list
>>>> Kolab-devel at kolab.org
>>>> https://kolab.org/mailman/listinfo/kolab-devel
>>>>
>>>> _______________________________________________
>>>> 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 <<
>>> --------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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 <<
>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> --
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
> Fax    : +49 721 1513 52322                        D-20146 Hamburg
> --------------------------------------------------------------------
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
> _______________________________________________
> 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/20100225/7730bd3c/attachment-0001.bin

From wrobel at pardus.de  Thu Feb 25 18:00:10 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 18:00:10 +0100
Subject: [Kolab-devel] Simple connectors for Android and Outlook
In-Reply-To: <4B869511.3090500@dasz.at>
References: <4B869511.3090500@dasz.at>
Message-ID: <20100225180010.21343747zn463mw4@webmail.pardus.de>

Hi David,

Quoting David Schmitt <david at dasz.at>:

> Hi, everyone!
>
>
> We are proud to announce the first developer preview of our Kolab sync
> clients for both Android and Outlook. Both are licensed under the GPLv3.

Wow, interesting.

>
>
> Please join us on the respective project pages:
>
>    http://code.google.com/p/kolab-outlook/
>    http://code.google.com/p/kolab-android/
>
>
> We appreciate feedback both here and on the issue tracker.

I'm not on windows very often so I probably can't offer much feedback  
in that area. But if you need to know something specific about the  
Kolab format or the interoperability with other clients I'm certain  
the Kolab Konsortium will be eager to help on this list.

What I'd like to know is whether you can already compare your Outlook  
connector with the other available solutions? Do you already know what  
you aim at with your connector? Will you include tasks and notes  
later, too?

Cheers,

Gunnar

>
>
> Regards, David Schmitt
>
> --
> dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
> Klosterneuburg                                         UID: ATU64260999
>
>         FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg
>
> _______________________________________________
> 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/20100225/499d9fc9/attachment.bin

From wrobel at pardus.de  Thu Feb 25 18:25:02 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 18:25:02 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100225150155.723599004.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
Message-ID: <20100225182502.19865rleiqqjsxas@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> Hi!
>
> I think everyone agrees that we want to get away from CVS, primary
> reasons for this is to be able to move files around without breaking
> their history and to get a single revision number to identify
> builds, which is important e.g. for automated builds.
>
> Although we will continue to use a central public repository, some
> of the developers (including Sascha and me) want the ability to do
> refactoring or bigger changes without interrupting the work of
> others or just do some local modifications for testing or for
> customers and still be able to commit often to save their progress
> and to split their work in smaller parts which can be reviewed more
> easily. Therefore (and for some other reasons) the next SCM will not
> be Subversion, but a distributed SCM.

Yes, yes, yes, YES!

>
> Main contenders for this are Mercurial (hg) and git, but for the
> following reasons we see Mercurial as the better choice for the
> development of Kolab Server:
>
> - Intevation has expert knowledge and operating experience in
>   Mercurial while only user experience in git.
> - The web interface offers simple and short URLs for downloading
>   single files or patches, this is already used with the viewcvs
>   interface for user documentation and for patches which have to be
>   applied to e.g. Cyrus imapd to add features required by the
>   server.
> - Usage of Mercurial is easier to learn for people already knowing
>   CVS or Subversion, because the UI is quite similar, see e.g.
>   http://mercurial.selenic.com/quickstart/ or
>   http://mercurial.selenic.com/wiki/CvsCommands
>
> So I would like to ask for short feedback (as I do not want to spend
> too much time on discussion if everyone already is happy enough with
> this) about what you think about switching to Mercurial.
>
> Please choose one of:
> +1 (I want it)

+1 because of all of the three reasons you mentioned are sound.

If I had to make the decision I would still go for git as I have the  
impression that this is currently developing into the mainstream  
successor following cvs / svn. The whole PHP world seems to have move  
into github during the last two month :)

But as long as it is distributed I don't really care which tool we  
actually use. It is just a tool after all and they are all pretty much  
alike.

Cheers,

Gunnar

>  0 (I can live with it)
> -1 (I do not agree, please add a short rationale)
>
> Deadline for this poll is next Thursday, March 4th, 12:00 UTC.
>
> If we get a negative result, we will start a more in-depth
> discussion.
>
> Regards,
> Thomas Arendsen Hein
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- 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/20100225/8e53fb91/attachment.bin

From math.parent at gmail.com  Thu Feb 25 19:57:01 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Thu, 25 Feb 2010 19:57:01 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100225182502.19865rleiqqjsxas@webmail.pardus.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100225182502.19865rleiqqjsxas@webmail.pardus.de>
Message-ID: <960738411002251057j596ffb77uced4bb1bce514277@mail.gmail.com>

+1

I have no experience in Hg, but I understand the reasons (compared to
git). And YES YES YES, move away from CVS!


Mathieu Parent


From wrobel at pardus.de  Thu Feb 25 20:34:36 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 25 Feb 2010 20:34:36 +0100
Subject: [Kolab-devel] [issue4161] DIMP not selectable
	in	kolab-webclient login with auth	driver kolab
In-Reply-To: <1266931247.5.0.278793023087.issue4161@kolab.org>
References: <1266931247.5.0.278793023087.issue4161@kolab.org>
Message-ID: <20100225203436.86865rdkvxnf990c@webmail.pardus.de>

Hi Arvid,

Quoting Arvid Requate <issues at kolab.org>:

>
> New submission from Arvid Requate <requate at univention.de>:
>
> With auth driver kolab there is no dropdown to select DIMP on user login

Correct.

> I am currently not aware of any other way to preselect DIMP on a per user or
> even a site-wide setting. Tested with horde-1.2-0 with kolab 2.2  
> branch patches from
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

You should configure client/imp/config/servers.php the same way as  
provided in t_GLOBAL_HK_GW_Config.diff in the patch directory you  
mention.

On a standard OpenPKG server (it is helpful to have one installed for  
reference purposes when working with the configuration on a native  
port - which I assume is what you do) the mechanism works fine. We use  
the imp login and correctly map uids to mail addresses. This happens  
within the mentioned client/imp/config/servers.php.

There is no question whatsoever that the Horde 3 login process is  
completely broken and the Kolab patches we use even aggravate the  
situation. Nevertheless I assume we still need to stick to it at the  
moment.

>
> The kolab auth driver is needed to call uid-to-email mapping hooks.

For the imp login this is also possible via other means as mentioned above.

Cheers,

Gunnar
-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------



From ml at radoeka.nl  Thu Feb 25 21:25:41 2010
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 25 Feb 2010 21:25:41 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100225182502.19865rleiqqjsxas@webmail.pardus.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100225182502.19865rleiqqjsxas@webmail.pardus.de>
Message-ID: <201002252125.41870.ml@radoeka.nl>


Op donderdag 25 februari 2010 18:25:02 schreef Gunnar Wrobel:

-1 (I do not agree, please add a short rationale)

> If I had to make the decision I would still go for git as I have the  
> impression that this is currently developing into the mainstream  
> successor following cvs / svn. The whole PHP world seems to have move  
> into github during the last two month :)

Not only PHP, but many other projects are moving to git.  I hardly hear 
anything from Mercurial.  It might that at this moment it is easier to move 
from cvs/svn to mercurial compared to git, but in the coming years when git is 
the code repository on the internet, Mercurial will be a stranger.  This may 
make it harder to attrack developers in the future.

I've no experience with either git or mercurial, so can't really determine 
which one is nicer.  The one thing I know is that files via urls offered by 
Git look stange to me.  On the other hand I would like to learn git, as this 
experience may be needed for other projects like KDE.  I don't believe I'll 
use mercurial for another project....  As I already mentioned KDE, the KDE 
developers will be using Git in the future and openSUSE already does.  If 
Kolab would move to Mercurial you force those people to learn yet another 
(perhaps similar, but still another) code version system.

> - Intevation has expert knowledge and operating experience in
>   Mercurial while only user experience in git.

Good point.  But Git will be more used in the future than Mercurial, so it 
might be good oppertunity to get more Git operating experience.

> - The web interface offers simple and short URLs for downloading
>   single files or patches, this is already used with the viewcvs
>   interface for user documentation and for patches which have to be
>   applied to e.g. Cyrus imapd to add features required by the
>   server.

Scratch this itch, isn't that the mantra of open source software.  Lots of 
other OSS project will benefit of short / simple url's.


> - Usage of Mercurial is easier to learn for people already knowing
>   CVS or Subversion, because the UI is quite similar, see e.g.
>   http://mercurial.selenic.com/quickstart/ or
>   http://mercurial.selenic.com/wiki/CvsCommands

In the future mercurial is stranger and not the mainstream.  It would mean 
more difficult to learn...


-- 
Richard


From wrobel at pardus.de  Thu Feb 25 22:42:46 2010
From: wrobel at pardus.de (wrobel@pardus.de)
Date: Thu, 25 Feb 2010 22:42:46 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <201002252125.41870.ml@radoeka.nl>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100225182502.19865rleiqqjsxas@webmail.pardus.de>
	<201002252125.41870.ml@radoeka.nl>
Message-ID: <20100225224246.94606wnfjatn9f0o@webmail.pardus.de>

Hi Richard,

as I am also in favor of git but do nevertheless support the choice of  
mercurial for Kolab I would like to try to convince you ;)

Quoting Richard Bos <ml at radoeka.nl>:

>
> Op donderdag 25 februari 2010 18:25:02 schreef Gunnar Wrobel:
>
> -1 (I do not agree, please add a short rationale)
>
>> If I had to make the decision I would still go for git as I have the
>> impression that this is currently developing into the mainstream
>> successor following cvs / svn. The whole PHP world seems to have move
>> into github during the last two month :)
>
> Not only PHP, but many other projects are moving to git.  I hardly hear
> anything from Mercurial.  It might that at this moment it is easier to move
> from cvs/svn to mercurial compared to git, but in the coming years  
> when git is
> the code repository on the internet, Mercurial will be a stranger.

While I agree that git is probably acquiring new users at a faster  
pace Mercurial is certainly no "stranger". It is supported by Google  
code as well as SourceForge (http://mercurial.selenic.com/wiki/) and  
projects like Mozilla and OpenOffice are running on Mercurial  
(http://mercurial.selenic.com/wiki/ProjectsUsingMercurial).

> This may make it harder to attrack developers in the future.

I disagree. I do believe that the choice of the revision control  
system has nearly no influence on the decision to join a project or not.

We accepted that the Kolab Server used CVS for the past years. Did we  
consider the project to be bad or broken because of that? Did it keep  
people away? I don't think so. Of course it was annoying once Gunnar  
moved just another directory to a new location. But as far as I know  
nobody dropped out because of that. At least I hope so :)

> I've no experience with either git or mercurial, so can't really determine
> which one is nicer.

As far as I can tell Mercurial is. Git is very techy and appears more  
powerful to me. And there are features that I love (patch queue  
management) that you don't get with Mercurial. But Git is complicated  
and if you come from cvs/svn then Mercurial is definitely easier.

> The one thing I know is that files via urls offered by
> Git look stange to me.  On the other hand I would like to learn git, as this
> experience may be needed for other projects like KDE.  I don't believe I'll
> use mercurial for another project....  As I already mentioned KDE, the KDE
> developers will be using Git in the future and openSUSE already does.  If
> Kolab would move to Mercurial you force those people to learn yet another
> (perhaps similar, but still another) code version system.

As OpenSUSE already uses git I'm assume you will learn git soon anyway.
And as there is not that much new in mercurial when you come from  
cvs/svn all that will happen is that you know four revision control  
systems rather than three. And to be honest: As cvs/svn/hg are pretty  
similar it will be more like knowing two: cvs/svn/hg and the "strange"  
git kid.

>
>> - Intevation has expert knowledge and operating experience in
>>   Mercurial while only user experience in git.
>
> Good point.  But Git will be more used in the future than Mercurial, so it
> might be good oppertunity to get more Git operating experience.

Thomas did not clarify what "expert knowledge" means in that case.  
Look at http://mercurial.selenic.com/wiki/DeveloperRepos under  
"Special Repositories" as well as  
http://mercurial.selenic.com/wiki/ThomasArendsenHein.

I doubt Thomas will suddenly start coding on git :) so that kind of  
experience in git will be hard to reach. We would simply have users  
experience, not more.

And if you find anything within git which you cannot find in  
mercurial, go nag Thomas. He'll probably tell you how to do it in a  
nicer way in hg.

Though... I still don't know how to get something like topgit  
(http://repo.or.cz/w/topgit.git) in hg. Thomas? ;)

>
>> - The web interface offers simple and short URLs for downloading
>>   single files or patches, this is already used with the viewcvs
>>   interface for user documentation and for patches which have to be
>>   applied to e.g. Cyrus imapd to add features required by the
>>   server.
>
> Scratch this itch, isn't that the mantra of open source software.  Lots of
> other OSS project will benefit of short / simple url's.

As mentioned above I don't see us coding on git. We barely have enough  
time for the Kolab server.

>
>
>> - Usage of Mercurial is easier to learn for people already knowing
>>   CVS or Subversion, because the UI is quite similar, see e.g.
>>   http://mercurial.selenic.com/quickstart/ or
>>   http://mercurial.selenic.com/wiki/CvsCommands
>
> In the future mercurial is stranger and not the mainstream.  It would mean
> more difficult to learn...

I already disagreed above.

And from my experience as a developer I would say that the revision  
control system does not really count that much. In most cases you  
can't decide that anyhow and you are forced to know many of them.

If you ask me then both CVS and SVN can simply go away and cease to  
exist now that I know what the advantages of distributed revision  
control systems are.

However I will need to use both of them throughout the years to come.  
There will always be the one or the other project still using them.

My 2cents. I hope I was able to move you from -1 to 0 ? Maybe? ;)

Cheers,

Gunnar

>
>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- 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/20100225/136517db/attachment-0001.bin

From corey_m at schuhen.net  Thu Feb 25 23:37:57 2010
From: corey_m at schuhen.net (Corey Schuhen)
Date: Fri, 26 Feb 2010 08:37:57 +1000
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100225150155.723599004.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
Message-ID: <201002260837.57617.corey_m@schuhen.net>


Hi all,

I have been subscribed to this list for many years so I thought I'd offer my 
AU$0.02. Of course, as I am not actually a Kolab developer(just a happy user 
for lots of years) there is no point including me on the poll.

Where I work, we develop embedded vehicle control systems. We develop under 
Linux with an RTEMS PPC target. For RCS, first we were using CVS, then switched 
TLA(it was horrible, though I have heard bazar is better now) before finally 
moving  to mercurial (2 years and 10 months ago) with 9k change sets. Our 
source totals 30M and the .hg directory in a repository is 70M. b.t.w. We have 
5 developers on our team plus some on other teams that use our code. I'm just 
providing this information to given an idea about the size of our project.

Anyhow, to the point of my email, I just wanted to say that since the switch, 
we all have nothing but praise for mercurial. We are especially happy that it 
scales so well, all operations happen at a a good speed. The distributed 
nature means that you spend very little time waiting on network bandwidth, 
only when doing push/pull. Merges seem to work pretty well, sometimes needing 
some help if multiple users change the same lines but we expect this :)


Regards,

Corey



On Fri, 26 Feb 2010 01:29 amLOG you wrote:
> Hi!
> 
> I think everyone agrees that we want to get away from CVS, primary
> reasons for this is to be able to move files around without breaking
> their history and to get a single revision number to identify
> builds, which is important e.g. for automated builds.
> 
> Although we will continue to use a central public repository, some
> of the developers (including Sascha and me) want the ability to do
> refactoring or bigger changes without interrupting the work of
> others or just do some local modifications for testing or for
> customers and still be able to commit often to save their progress
> and to split their work in smaller parts which can be reviewed more
> easily. Therefore (and for some other reasons) the next SCM will not
> be Subversion, but a distributed SCM.
> 
> Main contenders for this are Mercurial (hg) and git, but for the
> following reasons we see Mercurial as the better choice for the
> development of Kolab Server:
> 
> - Intevation has expert knowledge and operating experience in
>   Mercurial while only user experience in git.
> - The web interface offers simple and short URLs for downloading
>   single files or patches, this is already used with the viewcvs
>   interface for user documentation and for patches which have to be
>   applied to e.g. Cyrus imapd to add features required by the
>   server.
> - Usage of Mercurial is easier to learn for people already knowing
>   CVS or Subversion, because the UI is quite similar, see e.g.
>   http://mercurial.selenic.com/quickstart/ or
>   http://mercurial.selenic.com/wiki/CvsCommands
> 
> So I would like to ask for short feedback (as I do not want to spend
> too much time on discussion if everyone already is happy enough with
> this) about what you think about switching to Mercurial.
> 
> Please choose one of:
> +1 (I want it)
>  0 (I can live with it)
> -1 (I do not agree, please add a short rationale)
> 
> Deadline for this poll is next Thursday, March 4th, 12:00 UTC.
> 
> If we get a negative result, we will start a more in-depth
> discussion.
> 
> 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 ml at radoeka.nl  Fri Feb 26 00:09:12 2010
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 26 Feb 2010 00:09:12 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100225224246.94606wnfjatn9f0o@webmail.pardus.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<201002252125.41870.ml@radoeka.nl>
	<20100225224246.94606wnfjatn9f0o@webmail.pardus.de>
Message-ID: <201002260009.12402.ml@radoeka.nl>

Hi Gunnar,

Op donderdag 25 februari 2010 22:42:46 schreef wrobel at pardus.de:
> My 2cents. I hope I was able to move you from -1 to 0 ? Maybe?

I started my (previous) email with a "0".  But as the email got longer and 
longer I thought that "-1" fitted better with it.  Now with your explanation 
including references to Thomas' mercurial pages, I've no problem to change my 
"-1" back into a 0 :)

-- 
Richard


From thomas at intevation.de  Fri Feb 26 11:11:12 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 26 Feb 2010 11:11:12 +0100
Subject: [Kolab-devel] topgit-equivalent for hg (was: Re: Poll: Kolab server
	switching to	Mercurial SCM?)
In-Reply-To: <20100225224246.94606wnfjatn9f0o@webmail.pardus.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100225182502.19865rleiqqjsxas@webmail.pardus.de>
	<201002252125.41870.ml@radoeka.nl>
	<20100225224246.94606wnfjatn9f0o@webmail.pardus.de>
Message-ID: <20100226104555.251606871.thomas@intevation.de>

New subject to keep the poll thread cleaner ...

* wrobel at pardus.de <wrobel at pardus.de> [20100225 22:43]:
> And if you find anything within git which you cannot find in mercurial, 
> go nag Thomas. He'll probably tell you how to do it in a nicer way in hg.
>
> Though... I still don't know how to get something like topgit  
> (http://repo.or.cz/w/topgit.git) in hg. Thomas? ;)

I don't know exactly how to use topgit, but on a first glance it
seemed more complicated to me than using Mercurial Queues (mq). Of
course this might be due to the added feature of dependency tracking
of patches.

mq patch queues can be easily tracked as a separate hg repository,
no need to learn new commands here. And you can use guards to
enable/disable certain sets of patches as a simple way of dependency
tracking.

Alternatives are the rebase extension (distributed with Mercurial
like the mq extension) or the tasks extension (currently not
distributed with Mercurial).

The choice of which extension to use should get easier in the
future, see
http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC

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
-------------- 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/20100226/48a1533b/attachment.bin

From issues at kolab.org  Fri Feb 26 12:47:40 2010
From: issues at kolab.org (Arvid Requate)
Date: Fri, 26 Feb 2010 11:47:40 +0000
Subject: [Kolab-devel] [issue4170] kolab-webclient patch for group ACL
	dropdown in kronolith
In-Reply-To: <1267184860.0.0.317361485911.issue4170@kolab.org>
Message-ID: <1267184860.0.0.317361485911.issue4170@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

The attached patch fixes a problem in the group ACLs dropdown of kronolith.
Without the patch, the values in the dropdown are LDAP-DNs instead of Groupnames
and the setting of group ACLs failes.

Tested with horde-1.2-0 with kolab 2.2 branch patches from
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

----------
files: t_kronolith_HK_UV_fix_group_permissions.diff
keyword: web client
messages: 23782
nosy: requate, wrobel
status: unread
title: kolab-webclient patch for group ACL dropdown in kronolith

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4170>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t_kronolith_HK_UV_fix_group_permissions.diff
Type: text/x-diff
Size: 2167 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100226/a7227663/t_kronolith_HK_UV_fix_group_permissions.bin

From issues at kolab.org  Fri Feb 26 13:56:54 2010
From: issues at kolab.org (Arvid Requate)
Date: Fri, 26 Feb 2010 12:56:54 +0000
Subject: [Kolab-devel] [issue4171] kronolith: personal calendar not selected
	by default
In-Reply-To: <1267189014.08.0.922084364947.issue4171@kolab.org>
Message-ID: <1267189014.08.0.922084364947.issue4171@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

By default kronolith does not show the personal calendar for a new user, the
checkbox is unselected. Maybe it would be good to change the default for that
checkbox.

Tested with horde-1.2-0 with kolab 2.2 branch patches from
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/patches/horde-webmail/1.2.0/tg/?only_with_tag=kolab_2_2_branch

----------
keyword: web client
messages: 23784
nosy: requate, wrobel
priority: feature
status: unread
title: kronolith: personal calendar not selected by default

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4171>
______________________________________


From david at dasz.at  Fri Feb 26 16:05:29 2010
From: david at dasz.at (David Schmitt)
Date: Fri, 26 Feb 2010 16:05:29 +0100
Subject: [Kolab-devel] Simple connectors for Android and Outlook
In-Reply-To: <20100225180010.21343747zn463mw4@webmail.pardus.de>
References: <4B869511.3090500@dasz.at>
	<20100225180010.21343747zn463mw4@webmail.pardus.de>
Message-ID: <4B87E339.70900@dasz.at>

Hi,

On 2/25/2010 6:00 PM, Gunnar Wrobel wrote:
> Quoting David Schmitt <david at dasz.at>:
>> Please join us on the respective project pages:
>>
>> http://code.google.com/p/kolab-outlook/
>> http://code.google.com/p/kolab-android/
>>
>>
>> We appreciate feedback both here and on the issue tracker.
>
> I'm not on windows very often so I probably can't offer much feedback in
> that area. But if you need to know something specific about the Kolab
> format or the interoperability with other clients I'm certain the Kolab
> Konsortium will be eager to help on this list.
>
> What I'd like to know is whether you can already compare your Outlook
> connector with the other available solutions? Do you already know what
> you aim at with your connector?

Our aim was to get a free/open[1], simple[2], safe[3], 
multi-platform[4], multi-device[5] synchronisation between our android 
phones and our PCs (desktop+laptop). Other options would not fulfill 
everything:

   google's cloud/gdata: not 1,3 (5, only via Web)
   ActiveSync: not 1,4
   sync-ml: not 2 (needs server support)
   proprietary Kolab/Outlook connectors: not 1,4

Our implementations only speak IMAP and only support a single source 
folder for each of the object types.

Of course, there are no technical reasons barring shared folders, 
multiple source folders (e.g. for multiple calendars), or notes and tasks.

 > Will you include tasks and notes later,
 > too?

There don't seem to be a default application for that on the Android, 
which is one of the reasons we don't use it and in turn didn't implement 
it. If someone could recommend tasks/notes apps for Android (FOSS 
preferred, of course) which expose their data, it should be no problem 
to support them.


Regards, David
-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg


From issues at kolab.org  Fri Feb 26 16:47:34 2010
From: issues at kolab.org (Marc Mutz)
Date: Fri, 26 Feb 2010 15:47:34 +0000
Subject: [Kolab-devel] [issue4172] Kleo crash on startup if Notepad++ is
	running
In-Reply-To: <1267199254.82.0.29225410462.issue4172@kolab.org>
Message-ID: <1267199254.82.0.29225410462.issue4172@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

This is really weird:
- Kleo crashes at startup (but after self-test dialog comes up) iff Notepad++
  is open. It doesn't matter which files it has open (or any at all); once
  closed Kleo starts without problems.
My guess is that this is related to some of the KWindowSystem code that already 
gave us headache so many times, but I have absolutely no idea how to debug 
this.

With Firefox open, Kleo still works, so it's hopefully an isolated problem with 
just Notepad++ and Kleo, therefore -> minor bug.

----------
assignedto: marc
keyword: gpg4win2, kleo, windows
messages: 23788
nosy: bernhard, emanuel, marc, till, werner
priority: minor bug
status: unread
title: Kleo crash on startup if Notepad++ is running

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4172>
______________________________________


From issues at kolab.org  Fri Feb 26 18:00:45 2010
From: issues at kolab.org (Marc Mutz)
Date: Fri, 26 Feb 2010 17:00:45 +0000
Subject: [Kolab-devel] [issue4173] ArchiveDefinition: warn if none are
	present/valid
In-Reply-To: <1267203645.33.0.794097274848.issue4173@kolab.org>
Message-ID: <1267203645.33.0.794097274848.issue4173@kolab.org>


New submission from Marc Mutz <marc at kdab.net>:

There should be a warning about missing ArchiveDefinitions if none are 
given/valid. Currently, it just shows an empty combobox. Maybe make that 
read-write, to allow ad-hoc archivers?

This bug was extracted from kolab/issue4164 ("sub-bug 2").

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23797
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: unread
title: ArchiveDefinition: warn if none are present/valid

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4173>
______________________________________


From wrobel at pardus.de  Fri Feb 26 18:03:18 2010
From: wrobel at pardus.de (wrobel@pardus.de)
Date: Fri, 26 Feb 2010 18:03:18 +0100
Subject: [Kolab-devel] [issue4161] DIMP not selectable in
	kolab-webclient login with	auth	driver kolab
In-Reply-To: <1267187406.2.0.132350292432.issue4161@kolab.org>
References: <1267187406.2.0.132350292432.issue4161@kolab.org>
Message-ID: <20100226180318.12840zr2ydzbcrtc@webmail.pardus.de>

Hi Arvid,

hope it is okay if I'm moving this to the mailing list...

Quoting Arvid Requate <issues at kolab.org>:

>
> Arvid Requate <requate at univention.de> added the comment:
>
> No success yet, following your recomendation to use the standard  
> servers.php for
> imp without auth-driver 'kolab'. The active settings are given below.
>
> We apply t_GLOBAL_HK_GW_Config.diff but historically override a couple of
> settings (by including e.g. kolab.ucs.php from kolab.php), which is necessary
> e.g. to adjust config-paths to /etc/horde and webroot.
>
> Currently we followed solution 2) of  
> https://issues.kolab.org/msg18077 to enable
> dimp, but if there is a better way, we would be happy to know how.

As visible from the discussion in https://issues.kolab.org/issue3309  
(to which https://issues.kolab.org/msg18077 belongs) there is a  
different solution available. Sascha insisted that I should fix it in  
a decent way and not only in a half-hearted attempt (which he  
considered the solution 2) you mentioned to be).

The commit I used to fix this can be found here:  
http://kolab.org/pipermail/kolab-commits/2009q1/009145.html

The essential part really is the servers.php we have been discussing.  
So if that one does not work for you then I'd like to know what you  
get when you debug through the line

$_SESSION['imp']['uniquser'] = $session->user_mail;

in that servers.php when logging in via UID. That is the part that  
should do the uid to mail conversion.

Cheers,

Gunnar

>
> Maybe somebody could provide a hint, which additional setting must  
> be adjusted?
> These settings are active and seem relevant for login to me:
>
> $conf['auth']['params']['app'] = 'imp';
> $conf['auth']['driver'] = 'application';
> $conf['auth']['admins'] = array('Administrator');
> $conf['auth']['checkip'] = false;
> $conf['auth']['checkbrowser'] = false;
> $conf['auth']['alternate_login'] = false;
> $conf['auth']['redirect_on_logout'] = false;
> $conf['auth']['params']['login_block'] = false;
> $conf['auth']['params']['login_block_count'] = 3;
> $conf['auth']['params']['login_block_time'] = 5;
> $conf['auth']['params']['port'] = 143;
> $conf['auth']['params']['protocol'] = 'imap/notls';
> $conf['auth']['params']['imapconfig'] = 'separate';
> $conf['hooks']['username'] = true; // no success changing this
> $conf['hooks']['preauthenticate'] = false;
> $conf['hooks']['postauthenticate'] = false;
> $conf['hooks']['authldap'] = false;
> $conf['accounts']['driver'] = 'null';
> $conf['kolab']['imap']['server'] = 'qamaster.univention.qa';
> $conf['kolab']['imap']['port'] = 143;
> $conf['kolab']['imap']['sieveport'] = 2000;
> $conf['kolab']['imap']['maildomain'] = 'univention.qa';
>
> ----------
> status: resolved -> chatting
>
> ______________________________________
> Kolab issue tracker <issues at kolab.org>
> <https://issues.kolab.org/issue4161>
> ______________________________________
>


-------------- 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/20100226/b516e0ab/attachment.bin

From issues at kolab.org  Fri Feb 26 20:58:02 2010
From: issues at kolab.org (Arvid Requate)
Date: Fri, 26 Feb 2010 19:58:02 +0000
Subject: [Kolab-devel] [issue4174] Patch for imp/dimp login by uid
In-Reply-To: <1267214282.09.0.0470677753384.issue4174@kolab.org>
Message-ID: <1267214282.09.0.0470677753384.issue4174@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

The attached patch fixes two problems with the imp/dimp login by uid using auth
driver 'application' (https://issues.kolab.org/issue3309). The patch proposes
using 'uniquser'instead of 'user' in the following to calls:

A) /usr/share/horde3/imp/lib/Auth/imp.php line 168:
 $imp_imap = &IMP_IMAP::singleton($_SESSION['imp']['user'],
$credentials['password']);

B) /usr/share/horde3/imp/lib/Session.php line 278:
 $res = $imapclient->login($_SESSION['imp']['user'], $password);

----------
files: t_imp_HK_UV_fix_login_by_uid.diff
keyword: web client
messages: 23806
nosy: requate, wrobel
status: unread
title: Patch for imp/dimp login by uid

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4174>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t_imp_HK_UV_fix_login_by_uid.diff
Type: text/x-diff
Size: 1323 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100226/9587860c/t_imp_HK_UV_fix_login_by_uid-0001.bin

From issues at kolab.org  Fri Feb 26 21:03:32 2010
From: issues at kolab.org (Diego Woitasen)
Date: Fri, 26 Feb 2010 20:03:32 +0000
Subject: [Kolab-devel] [issue4175] Check kolabHomeServerOnly values in
	uppecase
In-Reply-To: <1267214612.43.0.699564028911.issue4175@kolab.org>
Message-ID: <1267214612.43.0.699564028911.issue4175@kolab.org>


New submission from Diego Woitasen <diegows at xtech.com.ar>:

kolabHomeServerOnly value is TRUE or FALSE in uppercase. Read rfc 2252 section 2.4.

----------
files: ldap-true.diff
messages: 23807
nosy: diegows
priority: minor bug
status: unread
title: Check kolabHomeServerOnly values in uppecase

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4175>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap-true.diff
Type: text/x-patch
Size: 686 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100226/3b36a196/ldap-true.bin

From requate at univention.de  Fri Feb 26 21:45:31 2010
From: requate at univention.de (Arvid Requate)
Date: Fri, 26 Feb 2010 21:45:31 +0100
Subject: [Kolab-devel] [issue4161] DIMP not selectable in kolab-webclient
	login with auth driver kolab
Message-ID: <201002262145.31194.requate@univention.de>

Dear Gunnar,

> hope it is okay if I'm moving this to the mailing list...

sure, thanks for the hint, after a bit of debugging I think I found the 
problem. There still were two imap login made with 'user' instead 
of 'uniquser'. A patch is attached to https://issues.kolab.org/issue4174

> So if that one does not work for you then I'd like to know what you  
> get when you debug through the line
> 
> $_SESSION['imp']['uniquser'] = $session->user_mail;

See details below. 

Thanks and best regards,
Arvid

IMP/DIMP login:
=========

Problem A) 
The call to
$imp_imap = &IMP_IMAP::singleton($_SESSION['imp']['user'], 
$credentials['password']);
fails in /usr/share/horde3/imp/lib/Auth/imp.php line 168, called by
/usr/share/horde3/lib/Horde/Auth.php(158): 
Auth_imp->_authenticate('user1 at univentio...', Array)
with
userID: 'user1 at univention.qa' , user: 'uid1', uniquser: 'user1 at univention.qa'

With the patch: 
$imp_imap = &IMP_IMAP::singleton($_SESSION['imp']['uniquser'], 
$credentials['password']);
the login succeeds. The full Call Stack at this point is as follows:
Dec 17 23:29:04 HORDE [error] [imp] DEBUG: Callstack:
#0 /usr/share/horde3/lib/Horde/Auth.php(158): 
Auth_imp->_authenticate('user1 at univentio...', Array)
#1 /usr/share/horde3/imp/lib/Auth/imp.php(97): 
Auth->authenticate('user1 at univentio...', Array, true)
#2 /usr/share/horde3/imp/lib/Session.php(212): 
Auth_imp->authenticate('user1 at univentio...', Array, true)
#3 /usr/share/horde3/imp/redirect.php(203): 
IMP_Session::createSession('uid1', 'univention', 'qamaster.univen...', Array)
#4 {main} [pid 23800 on line 139 of "/usr/share/horde3/imp/lib/Auth/imp.php"]

After that, six additional calls to this &IMP_IMAP::singleton are made with
 userID: '' , user: 'uid1', uniquser: 'user1 at univention.qa'
and with the patch the succeed as well. Call Stacks of the six attempts are 
given below.


Problem B)
In servers.php $_SESSION['imp']['uniquser'] is set to user1 at univention.qa all 
right, but this is irrelevant, I can comment it out without a change of 
behaviour. This is because in Line 114 
of /usr/share/horde3/imp/lib/Session.php ("Determine the unique user name.") 
the user is not Auth::isAuthenticated and the else branch is followed, 
setting
$_SESSION['imp']['uniquser'] back to $_SESSION['imp']['user']
as realm ist empty.

Now, the IMP::getAutoLoginServer call in line 161 somehow sets 
$_SESSION['imp']['uniquser'] back to the mailadress user1 at univention.qa, the 
show can go on :-)

The $auth_imp->authenticate($_SESSION['imp']['uniquser'] on line 212 succeeds, 

BUT

the $res = $imapclient->login($_SESSION['imp']['user'], $password); on line 
278 fails (calling Auth_imp::IMPsetAuthErrorMsg).

After replacing this call by
$res = $imapclient->login($_SESSION['imp']['uniquser'], $password);
the login by uid finally succeeds.

-- 
**** Besuchen Sie uns auf der CeBIT in Hannover 
vom 02.-06.03.2010 in Halle 2, Stand B 36 ****

Arvid Requate
Open Source Software Engineer

Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

requate at univention.de
http://www.univention.de

Gesch?ftsf?hrer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876 


From issues at kolab.org  Sat Feb 27 11:46:31 2010
From: issues at kolab.org (Gavin McCullagh)
Date: Sat, 27 Feb 2010 10:46:31 +0000
Subject: [Kolab-devel] [issue4176] Adding RSS feed to Horde breaks portal
	screen
In-Reply-To: <1267267591.78.0.902482271524.issue4176@kolab.org>
Message-ID: <1267267591.78.0.902482271524.issue4176@kolab.org>


New submission from Gavin McCullagh <gavin.mccullagh at gcd.ie>:

If I login to the horde interface and attempt to add an RSS feed to the horde
portal page, eg

http://www.theregister.co.uk/headlines.atom

The portal page becomes completely blank after that.  I've generally ended up
deleting the prefs file to fix this.  One could probably hand edit the prefs
file, but I'm not that used to editing serialised PHP.

----------
messages: 23817
nosy: gavinmc
priority: bug
status: unread
title: Adding RSS feed to Horde breaks portal screen

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4176>
______________________________________


From wrobel at pardus.de  Sat Feb 27 20:58:29 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 27 Feb 2010 20:58:29 +0100
Subject: [Kolab-devel] topgit-equivalent for hg (was: Re: Poll:
	Kolab	server switching to	Mercurial SCM?)
In-Reply-To: <20100226104555.251606871.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100225182502.19865rleiqqjsxas@webmail.pardus.de>
	<201002252125.41870.ml@radoeka.nl>
	<20100225224246.94606wnfjatn9f0o@webmail.pardus.de>
	<20100226104555.251606871.thomas@intevation.de>
Message-ID: <20100227205829.46202268typ07o1w@webmail.pardus.de>

Hi Thomas!

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> New subject to keep the poll thread cleaner ...
>
> * wrobel at pardus.de <wrobel at pardus.de> [20100225 22:43]:
>> And if you find anything within git which you cannot find in mercurial,
>> go nag Thomas. He'll probably tell you how to do it in a nicer way in hg.
>>
>> Though... I still don't know how to get something like topgit
>> (http://repo.or.cz/w/topgit.git) in hg. Thomas? ;)
>
> I don't know exactly how to use topgit, but on a first glance it
> seemed more complicated to me than using Mercurial Queues (mq).

In a way yes. The work flow is more complex as the situation it  
handles is more difficult. But it actually does not have that many  
commands. So after a few rounds of initial patch queue management with  
topgit I would say it is not difficult to use.

> Of course this might be due to the added feature of dependency tracking
> of patches.
>
> mq patch queues can be easily tracked as a separate hg repository,

"as a separate hg repository" is the crucial point that topgit avoids.

> no need to learn new commands here. And you can use guards to
> enable/disable certain sets of patches as a simple way of dependency
> tracking.

Been there, done that... guards don't do it. Actually they turn out to  
be quite horrible once your patch queue is a little bit more complex.

>
> Alternatives are the rebase extension (distributed with Mercurial
> like the mq extension) or the tasks extension (currently not
> distributed with Mercurial).
>
> The choice of which extension to use should get easier in the
> future, see
> http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC

This is a good page! It even lists the hg alternative for topgit:  
pbranch. They have an introduction for it that explains what the  
differences to mq are:  
http://arrenbrecht.ch/mercurial/pbranch/intro.htm.

The wiki page is really nice as it lists pros and cons for the  
different approaches. If hg really gets a joined extension that is  
able to combine most of the pros while avoiding most of the cons: Nice!

Cheers,

Gunnar

>
> 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
>



-- 
______ 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/20100227/8ba4e97c/attachment.bin

From wrobel at pardus.de  Sat Feb 27 21:43:52 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 27 Feb 2010 21:43:52 +0100
Subject: [Kolab-devel] [issue4161] DIMP not selectable
	in	kolab-webclient login with auth driver kolab
In-Reply-To: <201002262145.31194.requate@univention.de>
References: <201002262145.31194.requate@univention.de>
Message-ID: <20100227214352.213869hcs3x1a9l4@webmail.pardus.de>

Quoting Arvid Requate <requate at univention.de>:

> Dear Gunnar,
>
>> hope it is okay if I'm moving this to the mailing list...
>
> sure, thanks for the hint, after a bit of debugging I think I found the
> problem. There still were two imap login made with 'user' instead
> of 'uniquser'.

I did not look at the code now nor did I debug the code yet. I'm  
certainly willing to do that but I do not understand the problem yet.  
 From your report I assume that the login on your server works via  
mail address but it fails if you try via UID. Is that correct?

If that is the case then this is something that I can currently not  
reproduce on a standard Kolab OpenPKG server.  
https://issues.kolab.org/issue3309 has been closed as resolved and UID  
login was explicitly tested. And I'm absolutely certain it works on  
the current release. My standard test user is usually named  
"1 at example.com" with UID "1". And I always login with this UID "1" as  
it is conveniently short.

If my assumption is correct and you fail to login via UID then  
something must be different on your server.

> A patch is attached to https://issues.kolab.org/issue4174
>
>> So if that one does not work for you then I'd like to know what you
>> get when you debug through the line
>>
>> $_SESSION['imp']['uniquser'] = $session->user_mail;
>
> See details below.
>
> Thanks and best regards,
> Arvid
>
> IMP/DIMP login:
> =========
>
> Problem A)
> The call to
> $imp_imap = &IMP_IMAP::singleton($_SESSION['imp']['user'],
> $credentials['password']);
> fails in /usr/share/horde3/imp/lib/Auth/imp.php line 168, called by
> /usr/share/horde3/lib/Horde/Auth.php(158):
> Auth_imp->_authenticate('user1 at univentio...', Array)
> with
> userID: 'user1 at univention.qa' , user: 'uid1', uniquser: 'user1 at univention.qa'
>
> With the patch:
> $imp_imap = &IMP_IMAP::singleton($_SESSION['imp']['uniquser'],
> $credentials['password']);
> the login succeeds. The full Call Stack at this point is as follows:
> Dec 17 23:29:04 HORDE [error] [imp] DEBUG: Callstack:
> #0 /usr/share/horde3/lib/Horde/Auth.php(158):
> Auth_imp->_authenticate('user1 at univentio...', Array)
> #1 /usr/share/horde3/imp/lib/Auth/imp.php(97):
> Auth->authenticate('user1 at univentio...', Array, true)
> #2 /usr/share/horde3/imp/lib/Session.php(212):
> Auth_imp->authenticate('user1 at univentio...', Array, true)
> #3 /usr/share/horde3/imp/redirect.php(203):
> IMP_Session::createSession('uid1', 'univention', 'qamaster.univen...', Array)
> #4 {main} [pid 23800 on line 139 of "/usr/share/horde3/imp/lib/Auth/imp.php"]
>
> After that, six additional calls to this &IMP_IMAP::singleton are made with
>  userID: '' , user: 'uid1', uniquser: 'user1 at univention.qa'
> and with the patch the succeed as well. Call Stacks of the six attempts are
> given below.
>
>
> Problem B)
> In servers.php $_SESSION['imp']['uniquser'] is set to user1 at univention.qa all
> right, but this is irrelevant, I can comment it out without a change of
> behaviour. This is because in Line 114
> of /usr/share/horde3/imp/lib/Session.php ("Determine the unique user name.")
> the user is not Auth::isAuthenticated and the else branch is followed,
> setting
> $_SESSION['imp']['uniquser'] back to $_SESSION['imp']['user']
> as realm ist empty.
>
> Now, the IMP::getAutoLoginServer call in line 161 somehow sets
> $_SESSION['imp']['uniquser'] back to the mailadress user1 at univention.qa, the
> show can go on :-)
>
> The $auth_imp->authenticate($_SESSION['imp']['uniquser'] on line 212  
> succeeds,
>
> BUT
>
> the $res = $imapclient->login($_SESSION['imp']['user'], $password); on line
> 278 fails (calling Auth_imp::IMPsetAuthErrorMsg).
>
> After replacing this call by
> $res = $imapclient->login($_SESSION['imp']['uniquser'], $password);
> the login by uid finally succeeds.
>

I'm not certain I follow your steps here. But am I correct if I assume  
that your patch is about always using the "uniquser" value as that  
contains the mail address rather than the UID? And that login fails if  
the code tries to use the UID?

It may well be that this also happens on the OpenPKG server. The  
difference would be: A login via UID on the Imapd server succeeds. It  
has to succeed as you won't be able to use UID login with an external  
client on your IMAP server.

Can you give me some additional hints?

Cheers,

Gunnar

> --
> **** Besuchen Sie uns auf der CeBIT in Hannover
> vom 02.-06.03.2010 in Halle 2, Stand B 36 ****
>
> Arvid Requate
> Open Source Software Engineer
>
> Univention GmbH
> Linux for your business
> Mary-Somerville-Str.1
> 28359 Bremen
> Tel. : +49 421 22232-0
> Fax : +49 421 22232-99
>
> requate at univention.de
> http://www.univention.de
>
> Gesch?ftsf?hrer: Peter H. Ganten
> HRB 20755 Amtsgericht Bremen
> Steuer-Nr.: 71-597-02876
>
> _______________________________________________
> 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/20100227/ade9ff2a/attachment.bin

From wrobel at pardus.de  Sat Feb 27 23:08:02 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 27 Feb 2010 23:08:02 +0100
Subject: [Kolab-devel] Link commits into issues (was: Re: Poll: Kolab	server
	switching to Mercurial SCM?)
In-Reply-To: <20100225150155.723599004.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
Message-ID: <20100227230802.99701c7fessydjvo@webmail.pardus.de>

Hi Thomas,

would it be possible to automatically update issues with corresponding  
commits? We have that in Horde and I'm really missing that feature in  
our issue tracker. Basically I want commit links to the web view of  
the repository posted into an issue once the commit message contains  
"kolab/issueXYZ". Would that be easy/possible once we switched to hg?

Cheers,

Gunnar

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> Hi!
>
> I think everyone agrees that we want to get away from CVS, primary
> reasons for this is to be able to move files around without breaking
> their history and to get a single revision number to identify
> builds, which is important e.g. for automated builds.
>
> Although we will continue to use a central public repository, some
> of the developers (including Sascha and me) want the ability to do
> refactoring or bigger changes without interrupting the work of
> others or just do some local modifications for testing or for
> customers and still be able to commit often to save their progress
> and to split their work in smaller parts which can be reviewed more
> easily. Therefore (and for some other reasons) the next SCM will not
> be Subversion, but a distributed SCM.
>
> Main contenders for this are Mercurial (hg) and git, but for the
> following reasons we see Mercurial as the better choice for the
> development of Kolab Server:
>
> - Intevation has expert knowledge and operating experience in
>   Mercurial while only user experience in git.
> - The web interface offers simple and short URLs for downloading
>   single files or patches, this is already used with the viewcvs
>   interface for user documentation and for patches which have to be
>   applied to e.g. Cyrus imapd to add features required by the
>   server.
> - Usage of Mercurial is easier to learn for people already knowing
>   CVS or Subversion, because the UI is quite similar, see e.g.
>   http://mercurial.selenic.com/quickstart/ or
>   http://mercurial.selenic.com/wiki/CvsCommands
>
> So I would like to ask for short feedback (as I do not want to spend
> too much time on discussion if everyone already is happy enough with
> this) about what you think about switching to Mercurial.
>
> Please choose one of:
> +1 (I want it)
>  0 (I can live with it)
> -1 (I do not agree, please add a short rationale)
>
> Deadline for this poll is next Thursday, March 4th, 12:00 UTC.
>
> If we get a negative result, we will start a more in-depth
> discussion.
>
> Regards,
> Thomas Arendsen Hein
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
____ http://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 soenke.ebert at freenet.de  Tue Feb  9 23:18:35 2010
From: soenke.ebert at freenet.de (=?ISO-8859-1?Q?S=F6nke_Ebert?=)
Date: Tue, 09 Feb 2010 22:18:35 -0000
Subject: [Kolab-devel] Postfix installation error FreeBSD 8.0
Message-ID: <696D6326-0EFE-4B20-9D0B-7F64509FC0F9@freenet.de>

Hi,

I tried to install the kolab-server release 2.2.3 on a fresh freebsd  
8.0 system. The install quits with an error:

unistd.h:342: error: conflicting types for 'closefrom'
./sys_defs.h:1353: error: previous declaration of 'closefrom' was here
make: *** [attr_clnt.o] Error 1
make: *** [update] Error 1

I found the problem and a possible fix at the following link but I  
don't know how to integrate the fixed files into a new rpm.
http://www.mail-archive.com/freebsd-ports at freebsd.org/msg22267.html

Can anyone help me with it?
Thanks a lot
Soenke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20100209/2f06f240/attachment-0001.html

From issues at kolab.org  Mon Feb 15 11:18:53 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Feb 2010 10:18:53 -0000
Subject: [Kolab-devel] [issue4126] SmartCard: Learn card command shows gpgsm
	error dialogs
In-Reply-To: <1266229127.04.0.42587265067.issue4126@kolab.org>
Message-ID: <1266229127.04.0.42587265067.issue4126@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with Kleo 2.0.13-svn1084205 (gpg4win-2.0.2rc1):
- Insert SmartCard (NetKey v3 card)
- Run learn card command (from Kleopatra's system tray menu)
=> Kleopatra shows _4_ gpgsm error dialogs (see attachment).

Kleoaptra shows all card certificates in mainwindow correctly. And crypto
operations works correctly too. So the error dialog doesn't seems to be a
critical error..? Please check!

----------
assignedto: marc
files: learn-card-gpgsm-error.jpg
keyword: crypto, enterprise4, gpg4win2, kleo, windows
messages: 23545
nosy: emanuel, marc
priority: bug
status: unread
title: SmartCard: Learn card command shows gpgsm error dialogs

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4126>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: learn-card-gpgsm-error.jpg
Type: image/jpeg
Size: 120150 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/651a26c4/learn-card-gpgsm-error-0001.jpg

From issues at kolab.org  Mon Feb 15 12:26:55 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 15 Feb 2010 11:26:55 +0000
Subject: [Kolab-devel] [issue4128] side-by-side view: scrollbar slider too
	small.
In-Reply-To: <1266233215.18.0.0610035000483.issue4128@kolab.org>
Message-ID: <1266233215.18.0.0610035000483.issue4128@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 kdepim 20100212.1089100-kk1

Test:
1. Switch to the calendar part.
2. Change to side-by-side view.
3. Scroll the vertical scroll down until you reach 23:00 o'clock.
=> The slider is not at the button.
It seems like the slider is too small and moving it doesn't have an effect at
the bottom.
See screenshot: scrollbar-20100212.png

----------
assignedto: allen
files: scrollbar-20100212.png
keyword: enterprise35, kde client
messages: 23551
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: side-by-side view: scrollbar slider too small.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4128>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scrollbar-20100212.png
Type: image/png
Size: 113613 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100215/228902e8/scrollbar-20100212-0001.png