From issues at kolab.org  Mon Mar  1 11:57:05 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 01 Mar 2010 10:57:05 +0000
Subject: [Kolab-devel] [issue4177] A hidden reminder dialog should reappear,
	if a new alarm is triggered.
In-Reply-To: <1267441025.5.0.937902073913.issue4177@kolab.org>
Message-ID: <1267441025.5.0.937902073913.issue4177@kolab.org>


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

tested with Kontact e35 kdepim 20100226.1096270-kk1

Test:
1. Create two events with alarm (with different alarm times (2 mins))
2. First alarm is triggered. Press edit for it.
=> The edit dialog opens and the reminder is hidden.
3. The second alarm is triggered.
=> The reminder stays hidden and adds the alarm to the list.
I expect the reminder to pop up in this case.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23845
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: A hidden reminder dialog should reappear, if a new alarm is triggered.

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


From issues at kolab.org  Mon Mar  1 14:32:39 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 01 Mar 2010 13:32:39 +0000
Subject: [Kolab-devel] [issue4178] Use gpgme_op_passwd in Kleopatra.
In-Reply-To: <1267450359.33.0.520315680812.issue4178@kolab.org>
Message-ID: <1267450359.33.0.520315680812.issue4178@kolab.org>


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

Currently, Kleopatra runs gpgsm --passwd %k and gpg --batch --edit %k passwd 
save. The latter command however, returns 0 even if the passwd-pinentry was 
cancelled. Use new gpgme_op_passwd() instead.

(and make sure the action is greyed out / explains what's up if gpgme is too 
old at runtime)

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23854
nosy: bernhard, emanuel, marc, till
priority: feature
status: unread
title: Use gpgme_op_passwd in Kleopatra.

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


From bernhard.reiter at intevation.de  Mon Mar  1 16:07:25 2010
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 1 Mar 2010 16:07:25 +0100
Subject: [Kolab-devel] Kolab Systems AG re-launches Free Software Groupware
	business
Message-ID: <201003011607.25390.bernhard.reiter@intevation.de>

Dear friends of Kolab,

attached the press release "our" new company 
Kolab Systems AG for professional Kolab services:

http://kolabsys.com/index.php/resources/81-news2010-03-01

Spread the word.

Best Regards,
Bernhard
ps: I am a member of the board ("Verwaltungsrat").

1 March 2010: Kolab Systems AG re-launches Free Software Groupware business 
  (Zurich/Hanover) CeBIT 2010 in Hanover sees the re-launch of the Kolab Free 
Software business into the Kolab Systems AG. Professional service, certified 
packaging, quality assurance, and a strong partnership model characterise the 
new business built on a proven solution with 5 years of productive use. 
Customers and partners have the opportunity to meet Georg Greve, CEO of Kolab 
Systems AG, and Dr. Paul Adams, COO of Kolab Systems AG during CeBIT 2010 to 
discuss business opportunities.
"The award-winning design of the Kolab Groupware Solution has proven its value 
in many deployments with thousands of users who have used it productively 
throughout the past five years," states Georg Greve, CEO. "We feel that 
nurturing the surrounding business ecosystem is essential if Kolab is to 
fully realize its technical potential for all its users. Kolab Systems AG is 
the consequence of this and the answer to feedback that we received from 
partners, customers and the community alike."

Dr. Paul Adams, COO: "The new business will be focused on a strong partnership 
model to provide users with a service chain that combines fast 1st level 
support out of a single hand with Kolab Systems AG as a strong 2nd and 3rd 
level partner that focuses on testing, QA, packaging and continuous 
development and maintenance of the technical basis."

Managed by the founding president of FSFE and a senior Free Software expert 
and researcher with strong ties to the KDE community, the new business will 
continue to work closely with the Free Software community and ensure the 
future of the Kolab Groupware Solution as an independent and secure choice 
for all users.

Potential customers and companies interested in providing Kolab Groupware 
Solutions in the future are invited to contact

 Georg C. F. Greve, CEO
 Email:          <greve -- AT -- kolabsys.com>
 Mobile:         +49 - 1578 - 711 43 33
 http://www.linkedin.com/in/GeorgGreve

 Dr. Paul J. Adams, COO
 Email:          <adams --AT -- kolabsys.com>
 Mobile:         +44 - 7745 - 13 32 85
 http://uk.linkedin.com/in/pauljadams

for a meeting during CeBIT 2010.

Journalists are invited to join the Kolab Introduction on CeBIT on

 
Tuesday, 2.3.2010, 10:00
at the  Univention Stage, Hall 2, Stand B36

The managing directors of Kolab Systems AG will be available after the event 
to provide further information.


About Kolab Systems AG:

 Kolab Systems AG is a Swiss corporation based in Z?rich founded as a new, 
independent business in February 2010 by two of Europe's leading companies in 
the Free Software area that were deeply involved in the development of the 
Kolab Groupware Solution and continued to provide development and services 
throughout the past years. Intevation GmbH, Germany, with 10 years of 
strategic Free Software expertise in GIS, security and public administration 
software and KDAB, Sweden, the world?s largest independent source of Qt 
knowledge, providing consulting, training and mentoring for developing Qt 
applications from scratch as well as expertise in porting from all popular 
and legacy frameworks.

 For more information about Kolab Systems AG, see http://kolabsys.com


About Kolab:

 The Kolab Groupware Solution has initially been developed by a consortium of 
some of Germany's premier Free Software companies in 2002-2004 on principles 
of security, privacy and scalability. It follows best design and engineering 
principles inherent in Free Software to achieve a highly modular, scalable 
and distributed setup. Unlike other groupware solutions, Kolab is built upon 
the understanding of different information spheres: The primary Kolab Client, 
KDE Kontact, is a smart client that assembles each user's personal 
information view. Alternatively, deployments can involve Microsoft Outlook 
through one of three connectors, web clients, or mobile clients through one 
of several synchronisation paths.

 The Kolab community web site is available at http://kolab.org
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From thomas at intevation.de  Mon Mar  1 17:15:41 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Mon, 1 Mar 2010 17:15:41 +0100
Subject: [Kolab-devel] Link commits into issues (was: Re: Poll: Kolab
	server	switching to Mercurial SCM?)
In-Reply-To: <20100227230802.99701c7fessydjvo@webmail.pardus.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100227230802.99701c7fessydjvo@webmail.pardus.de>
Message-ID: <20100301154614.893610099.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20100227 23:08]:
> would it be possible to automatically update issues with corresponding  
> commits?

Yes, an example for bugzilla is in
http://hg.intevation.org/mercurial/file/bae9bb09166b/hgext/bugzilla.py

For connecting roundup, a similar hook can be used that either uses
the roundup-admin client or sends appropriate mails or http
requests.

But all this is not very specific to Mercurial, this will even work
with CVS.

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

Yes, for an example in Mercurial development with roundup see:
http://hg.intevation.org/mercurial/rev/bae9bb09166b
or in a different project with Google code's bug tracker:
http://hg.intevation.org/mirrors/vimperator.org/vimperator-labs/rev/97735160e9b4

Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From issues at kolab.org  Tue Mar  2 11:06:24 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 02 Mar 2010 10:06:24 +0000
Subject: [Kolab-devel] [issue4179] exception thrown (and not caught early
	enough) in some	std::string ctor
In-Reply-To: <1267524384.43.0.904836063717.issue4179@kolab.org>
Message-ID: <1267524384.43.0.904836063717.issue4179@kolab.org>


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

I found a s+e s/mime mail that causes Kleo to bring up a messagebox with 
something like
 "_S_construct [...] NULL"
in it (after successfully decrypting it, it seems, but I'm note sure if 
verification is also running through).

Looking at the source code of the mingw STL, this comes from one of the 
std::basic_string::_S_construct overloads. It's probably due to a NULL pointer 
being passed to a std::string(), but with the release version of the installer 
I had, it turned out to be impossible to get a backtrace of the throw site. 
Neither 'catch?throw' nor 'break?std::exception::exception()' 
nor 'break?std::logic_error::logic_error(std::string const&)' triggered at a 
believable location.

Need a debug build to track this further.

----------
assignedto: marc
keyword: gpg4win2, kleo, windows
messages: 23894
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: exception thrown (and not caught early enough) in some std::string ctor

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


From bernhard at intevation.de  Tue Mar  2 12:18:09 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 2 Mar 2010 12:18:09 +0100
Subject: [Kolab-devel] tine has another php Active Sync implementation
Message-ID: <201003021218.09523.bernhard@intevation.de>

I've just heard that tine also has an php implementation of activee sync which
is Free Software. (The code seems to be a bit hard to find.)

http://www.tine20.org/home/features/activesync/

Might be an alternative to z-push.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100302/4e67b996/attachment.bin

From issues at kolab.org  Tue Mar  2 12:22:07 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 02 Mar 2010 11:22:07 +0000
Subject: [Kolab-devel] [issue4180] Start date/time of a recurring todo is
	displayed wrongly.
In-Reply-To: <1267528927.3.0.972640593465.issue4180@kolab.org>
Message-ID: <1267528927.3.0.972640593465.issue4180@kolab.org>


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

tested with Kontact e35 kdepim 20100226.1097480-kk3

Test:
1. Switch to the todo component.
2. Create a new todo with different start date/time and end date/time and daily
recurrence.
3. Switch to the calendar component in agenda view.
4. Select the test todo.
=> The start date/time equals the end datet/time. But I have entered different
times. This is wrong.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23902
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Start date/time of a recurring todo is displayed wrongly.

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


From requate at univention.de  Tue Mar  2 14:05:54 2010
From: requate at univention.de (Arvid Requate)
Date: Tue, 2 Mar 2010 14:05:54 +0100
Subject: [Kolab-devel]
	=?utf-8?q?=5Bissue4161=5D_DIMP_not_selectable_in=09?=
	=?utf-8?q?kolab-webclient_login_with_auth_driver_kolab?=
In-Reply-To: <20100227214352.213869hcs3x1a9l4@webmail.pardus.de>
References: <201002262145.31194.requate@univention.de>
	<20100227214352.213869hcs3x1a9l4@webmail.pardus.de>
Message-ID: <201003021405.54719.requate@univention.de>

Hello,

Quoting Gunnar Wrobel <wrobel at pardus.de>:
> 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?

yes.

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

The issue is reproducable if uid != local part of emailaddress, maybe the 
debug logs did not show this.

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

Cyrus IMAPD in Standard UCS only supports login via mailbox-name 
(mailPrimaryAddress).

Best regards,
Arvid

-- 
**** 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  Tue Mar  2 15:13:45 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 02 Mar 2010 14:13:45 +0000
Subject: [Kolab-devel] [issue4181] Wish: an additional column "folder" in
	the todos list in	the todo component.
In-Reply-To: <1267539225.09.0.661310395113.issue4181@kolab.org>
Message-ID: <1267539225.09.0.661310395113.issue4181@kolab.org>


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

One customer wishes for a new column in the to-dos/task list. This new column
"folder" should contain the folder the todo is from.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23924
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: an additional column "folder" in the todos list in the todo component.

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


From wrobel at pardus.de  Tue Mar  2 18:01:19 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 02 Mar 2010 18:01:19 +0100
Subject: [Kolab-devel] tine has another php Active Sync implementation
In-Reply-To: <201003021218.09523.bernhard@intevation.de>
References: <201003021218.09523.bernhard@intevation.de>
Message-ID: <20100302180119.10276cmsa2uvug68@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> I've just heard that tine also has an php implementation of activee  
> sync which
> is Free Software. (The code seems to be a bit hard to find.)
>
> http://www.tine20.org/home/features/activesync/
>
> Might be an alternative to z-push.

Same thing:

$ head tine20/ActiveSync/LICENSE
NOTE: According to sec. 8 of the AFFERO GENERAL PUBLIC LICENSE (AGPL),
Version 1, the distribution of the Tine 2.0 ActiveSync module in or to the
United States of America is excluded from the scope of this license.
The Tine 2.0 ActiveSync module is licensed under AGPL Version 1 only.

AFFERO GENERAL PUBLIC LICENSE

Version 1, March 2002

Copyright ? 2002 Affero Inc.

Cheers,

Gunnar
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100302/2d09aad9/attachment.bin

From issues at kolab.org  Wed Mar  3 15:24:41 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 03 Mar 2010 14:24:41 +0000
Subject: [Kolab-devel] [issue4182] folder property: incidences-for needs
	restart to work
In-Reply-To: <1267626281.62.0.459673269938.issue4182@kolab.org>
Message-ID: <1267626281.62.0.459673269938.issue4182@kolab.org>


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

tested with Kontact e35 kdepim 20100226.1097480-kk3

The folder property incidences-for (Generate freebusy and activate alarms for)
needs restart to work.

Test:
1. Switch to the mail component.
2. RMB->Properties on the Calendar folder.
3. Change incidence-for option from for all admins to nobody.
4. Press okay.
5. Sync.
6. Switch to the calendar component.
7. Create an event with alarm in a few minutes in the calendar folder.
8. Sync.
9. Wait for the alarm.
=> The alarm appears, but I expect that the alarm does't appear, because I have
changed the incidence-ofr option to nobody.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23950
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: folder property: incidences-for  needs restart to work

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


From issues at kolab.org  Wed Mar  3 16:43:12 2010
From: issues at kolab.org (Marc Mutz)
Date: Wed, 03 Mar 2010 15:43:12 +0000
Subject: [Kolab-devel] [issue4183] Add a unit to the key strength fields
	in	NewCertificateWizard's overview page
In-Reply-To: <1267630992.39.0.788456138841.issue4183@kolab.org>
Message-ID: <1267630992.39.0.788456138841.issue4183@kolab.org>


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

Current:
  Key strength:    2048
  Subkey strength: 2048
Wanted:
  Key strength:    2048 bits
  Subkey strength: 2024 bits

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23955
nosy: emanuel, marc
status: unread
title: Add a unit to the key strength fields in NewCertificateWizard's overview page

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


From issues at kolab.org  Wed Mar  3 23:11:42 2010
From: issues at kolab.org (Gavin McCullagh)
Date: Wed, 03 Mar 2010 22:11:42 +0000
Subject: [Kolab-devel] [issue4184] date_format,
	when set to %x detects US format despite EN_IE locale
In-Reply-To: <1267654302.26.0.333054915735.issue4184@kolab.org>
Message-ID: <1267654302.26.0.333054915735.issue4184@kolab.org>


New submission from Gavin McCullagh <gavin.mccullagh at gcd.ie>:

By default the date_format variable is set to %x.  This, if I read the PHP
manual page correctly, should check my locale settings and set the date format
to what would be normal in my part of the world.  

  http://php.net/manual/en/function.strftime.php

That would be dd/mm/yyyy.  However, what I'm getting is mm/dd/yyyy (which is the
favoured format in the USA, but not in Ireland).

According to phpinfo(); my language setting is:

   LANG 	en_IE.UTF-8 

The output of locale -a is:

  C
  en_IE.utf8
  POSIX

and of locale is:

  LANG=en_IE.UTF-8
  LC_CTYPE="en_IE.UTF-8"
  LC_NUMERIC="en_IE.UTF-8"
  LC_TIME="en_IE.UTF-8"
  LC_COLLATE="en_IE.UTF-8"
  LC_MONETARY="en_IE.UTF-8"
  LC_MESSAGES="en_IE.UTF-8"
  LC_PAPER="en_IE.UTF-8"
  LC_NAME="en_IE.UTF-8"
  LC_ADDRESS="en_IE.UTF-8"
  LC_TELEPHONE="en_IE.UTF-8"
  LC_MEASUREMENT="en_IE.UTF-8"
  LC_IDENTIFICATION="en_IE.UTF-8"
  LC_ALL=

Of course, I can set the date_format explicitly to %d/%m/%Y but it would be
preferable for %x to work correctly based on my locale.  I set the language
explicitly (though again, it would be nice if that were done based on the locale
of the server).  

  $nls['defaults']['language'] = 'en_GB';

----------
messages: 23961
nosy: gavinmc
status: unread
title: date_format, when set to %x detects US format despite EN_IE locale

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


From issues at kolab.org  Wed Mar  3 23:40:01 2010
From: issues at kolab.org (valex)
Date: Wed, 03 Mar 2010 22:40:01 +0000
Subject: [Kolab-devel] [issue4185] Postfix: trivial-rewrite killed by signal
	11
In-Reply-To: <1267656001.41.0.590823764487.issue4185@kolab.org>
Message-ID: <1267656001.41.0.590823764487.issue4185@kolab.org>


New submission from valex <kolab2 at nivadis.eu>:

Hello all,
i've an problem with my Kolab 2.2.3 on Ubuntu 8.04 x64.

I'm not abel to send messages to an account on my kolab.
when i use netcat following happen:

netcat localhost 25
220 awz.dnsalias.net ESMTP Postfix
EHLO test
250-awz.dnsalias.net
250-PIPELINING
250-SIZE 20971520
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from:test at test.de
(an then nothing)


postfix.log says:

Mar 03 23:33:43 server <warning> postfix/master[19069]: warning: process
/kolab/libexec/postfix/trivial-rewrite pid 19942 killed by signal 11
Mar 03 23:33:43 server <warning> postfix/master[19069]: warning:
/kolab/libexec/postfix/trivial-rewrite: bad command startup -- throttling


if i use google i can't find something that shows me where the problem is

in main.cf.template weren't make changes


thanks

greetings Vale

----------
messages: 23962
nosy: valex
status: unread
title: Postfix: trivial-rewrite killed by signal 11

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


From wrobel at pardus.de  Thu Mar  4 11:09:36 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 04 Mar 2010 11:09:36 +0100
Subject: [Kolab-devel] Link commits into issues (was: Re: Poll:
	Kolab	server	switching to Mercurial SCM?)
In-Reply-To: <20100301154614.893610099.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100227230802.99701c7fessydjvo@webmail.pardus.de>
	<20100301154614.893610099.thomas@intevation.de>
Message-ID: <20100304110936.67745594hffxv808@webmail.pardus.de>

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

> * Gunnar Wrobel <wrobel at pardus.de> [20100227 23:08]:
>> would it be possible to automatically update issues with corresponding
>> commits?
>
> Yes, an example for bugzilla is in
> http://hg.intevation.org/mercurial/file/bae9bb09166b/hgext/bugzilla.py
>
> For connecting roundup, a similar hook can be used that either uses
> the roundup-admin client or sends appropriate mails or http
> requests.
>
> But all this is not very specific to Mercurial, this will even work
> with CVS.

Yes, but I assume we won't do that for our current CVS repo anymore.  
But I'd really like to have it in the new repo.

Cheers,

Gunnar

>
>> 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?
>
> Yes, for an example in Mercurial development with roundup see:
> http://hg.intevation.org/mercurial/rev/bae9bb09166b
> or in a different project with Google code's bug tracker:
> http://hg.intevation.org/mirrors/vimperator.org/vimperator-labs/rev/97735160e9b4
>
> 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
>
> _______________________________________________
> 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/20100304/30f5a842/attachment.bin

From wrobel at pardus.de  Thu Mar  4 11:15:37 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 04 Mar 2010 11:15:37 +0100
Subject: [Kolab-devel] Postfix installation error FreeBSD 8.0
In-Reply-To: <696D6326-0EFE-4B20-9D0B-7F64509FC0F9@freenet.de>
References: <696D6326-0EFE-4B20-9D0B-7F64509FC0F9@freenet.de>
Message-ID: <20100304111537.17822ya4tmzstum8@webmail.pardus.de>

Hi S?nke,

> 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. Can anyone help me with it?

Can you open an issue in the Kolab issue tracker for it? It is  
something we'll definitely have to fix in CVS, too and so there should  
be an issue for it. This should help to provide a fixed package.

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

Links:
------
[1] http://www.mail-archive.com/freebsd-ports at freebsd.org/msg22267.html

-------------- 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/20100304/1954b134/attachment.bin

From issues at kolab.org  Thu Mar  4 13:05:04 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Mar 2010 12:05:04 +0000
Subject: [Kolab-devel] [issue4187] Crash while switching between signed and
	unsigned	mail(rt#5980)
In-Reply-To: <1267704304.19.0.867051342804.issue4187@kolab.org>
Message-ID: <1267704304.19.0.867051342804.issue4187@kolab.org>


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

tested with Kontact e35 kdepim 20100226.1097480-kk3
                        libgpgme11 1.1.8-0kk1
Test:
Req: SMIME key pair.
1. Send a S/MIME signed mail to the test account and sync.
2. Forward this mail as attachment signed to the test account and sync.
3. Again: Forward this mail as attachment signed to the test account and sync.
4. Send a simple mail to the test account and sync.
=> A three times signed embedded mail and a simple mail are at least in the
inbox of the test account.
5. Fast switch between these two mails.
=> Crash!
It should not crash. This is important for the customer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23969
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: Crash while switching between signed and unsigned mail(rt#5980)

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


From issues at kolab.org  Thu Mar  4 14:00:01 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 04 Mar 2010 13:00:01 +0000
Subject: [Kolab-devel] [issue4188] Mail attachments should have the options
	to open the	attachment konqueror has.(rt#6040)
In-Reply-To: <1267707601.34.0.39460203367.issue4188@kolab.org>
Message-ID: <1267707601.34.0.39460203367.issue4188@kolab.org>


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

At the moment a mail attachment can be opened via the context with "open" and
"open with...". 
In the context menu of the konqueror are additional options like "open with Ark"
for a zip file. (And the customer has added new open ways to the konqueror)

Is it possible that kontact provides the same options to open an attachment as
the konqueror?

Please comment and estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23971
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Mail attachments should have the options to open the attachment konqueror has.(rt#6040)

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


From issues at kolab.org  Thu Mar  4 17:26:14 2010
From: issues at kolab.org (Marc Mutz)
Date: Thu, 04 Mar 2010 16:26:14 +0000
Subject: [Kolab-devel] [issue4189] EmailValidator: doesn't allow to delete
	'@' character
In-Reply-To: <1267719974.87.0.388071340411.issue4189@kolab.org>
Message-ID: <1267719974.87.0.388071340411.issue4189@kolab.org>


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

Copy of issue 4153:

> Can't press DEL key to delete "@" char. 
> Same problem if to try delete "@" char with BACKSPACE key.

----------
assignedto: marc
keyword: enterprise4, gpg4win2, kleo
messages: 23976
nosy: bernhard, emanuel, marc, till
priority: minor bug
status: chatting
title: EmailValidator: doesn't allow to delete '@' character

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


From issues at kolab.org  Thu Mar  4 17:50:33 2010
From: issues at kolab.org (Marc Mutz)
Date: Thu, 04 Mar 2010 16:50:33 +0000
Subject: [Kolab-devel] [issue4190] Implement set/unset trusted for root CAs
In-Reply-To: <1267721433.08.0.513339336626.issue4190@kolab.org>
Message-ID: <1267721433.08.0.513339336626.issue4190@kolab.org>


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

Kleo would need to write directly to $GNUPGHOME/trustlist.txt.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 23979
nosy: bernhard, emanuel, marc, till, werner
priority: minor bug
status: unread
title: Implement set/unset trusted for root CAs

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


From issues at kolab.org  Fri Mar  5 10:44:32 2010
From: issues at kolab.org (Marc Mutz)
Date: Fri, 05 Mar 2010 09:44:32 +0000
Subject: [Kolab-devel] [issue4191] Kleopatra doesn't detect smartcard after
	fresh install
In-Reply-To: <1267782272.06.0.571496988384.issue4191@kolab.org>
Message-ID: <1267782272.06.0.571496988384.issue4191@kolab.org>


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

To reproduce:
1. On a fresh XP, install gpg4win2
2. Make sure that you have installed the driver for the smartcard reader.
3. Start Kleopatra
4. Insert a smartcard
-> Nothing happens
Expected: Kleopatra systray icon starts blinking; clicking on it will learn 
card.

----------
assignedto: marc
keyword: gnupg, gpg4win2, kleo
messages: 23995
nosy: bernhard, emanuel, marc, till, werner
priority: urgent
status: unread
title: Kleopatra doesn't detect smartcard after fresh install

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


From issues at kolab.org  Fri Mar  5 14:12:36 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Mar 2010 13:12:36 +0000
Subject: [Kolab-devel] [issue4192] Wish: Rename German "Start" into "Beginn"
	in a event	advanced alarm dialog (rt#6043)
In-Reply-To: <1267794756.2.0.751998522151.issue4192@kolab.org>
Message-ID: <1267794756.2.0.751998522151.issue4192@kolab.org>


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

Test:
Req: Use German as language. 
1. Switch to the calendar component.
2. Start to create a new event.
3. Set alarm.
4. Click on the advanced button.
5. Look at the advanced alarm dialog.
=> All "Start" (e.g. in "vor dem Start") should be translated to "Beginn"

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24005
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Rename German "Start" into "Beginn" in a event advanced alarm dialog (rt#6043)

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


From issues at kolab.org  Fri Mar  5 14:29:50 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Mar 2010 13:29:50 +0000
Subject: [Kolab-devel] [issue4193] Wish: export just of some selected events.
In-Reply-To: <1267795790.0.0.569264073801.issue4193@kolab.org>
Message-ID: <1267795790.0.0.569264073801.issue4193@kolab.org>


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

The customer wishes for following feature:
Select some events in the calendar and use e.g. File->Export->ics. Then it
should be possible to export only the selected events.

In the moment the whole calendar is always exported.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24006
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: export just of some selected events.

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


From issues at kolab.org  Fri Mar  5 15:02:18 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Mar 2010 14:02:18 +0000
Subject: [Kolab-devel] [issue4194] Task without starttime should have
	default alarm type	"before the end".(rt#6045)
In-Reply-To: <1267797738.19.0.492061703297.issue4194@kolab.org>
Message-ID: <1267797738.19.0.492061703297.issue4194@kolab.org>


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

The user wants that an alarm of a task/todo without a starttime should appears
before the end of the task as default, and not at the start.

Test:
1. Switch to the todos.
2. Start to create a new todo.
3. Just set an endtime (not a starttime)
4. Set alarm on.
=> Wait for the alarm, but the alarm doesn't appear, because the default in the
alarm dialog is "before the start". In this case (no starttime/date) it should
be "before the end".
If a starttime/date is in place, it should be "before the start".

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24009
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Task without starttime should have default alarm type "before the end".(rt#6045)

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


From issues at kolab.org  Fri Mar  5 15:46:07 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 05 Mar 2010 14:46:07 +0000
Subject: [Kolab-devel] [issue4195] Copy+Paste of a todo with recurrence
	should not change	the enddate (rt#6046)
In-Reply-To: <1267800367.57.0.978554248236.issue4195@kolab.org>
Message-ID: <1267800367.57.0.978554248236.issue4195@kolab.org>


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

tested with Kontact e35 kdepim 20100226.1099026-kk4

Test:
1. Switch to the todo component.
2. Create a new todo with daily recurrence and enddate.
3. Select this todo.
4. Copy (Press Ctrl+C)
5. Paste (Press Ctrl+V)
=> The enddate of the copied todo has changed to the first of the month.
This is wrong.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24010
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Copy+Paste of a todo with recurrence should not change the enddate (rt#6046)

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


From issues at kolab.org  Mon Mar  8 14:01:49 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 08 Mar 2010 13:01:49 +0000
Subject: [Kolab-devel] [issue4196] frebusy list is broken.
In-Reply-To: <1268053309.54.0.697403312185.issue4196@kolab.org>
Message-ID: <1268053309.54.0.697403312185.issue4196@kolab.org>


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

tested with Kontact e35 kdepim 20100305.1099262-kk1

Test:
1. Switch o the calendar component.
2. Start to create a new event.
3. Switch to the attendee tab.
4. Enter a new attendee.
=> Both have the same entries in the fb list, but the organizor and the attendee
have different events in their calendars.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24038
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: frebusy list is broken.

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


From issues at kolab.org  Mon Mar  8 16:53:04 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 08 Mar 2010 15:53:04 +0000
Subject: [Kolab-devel] [issue4197] Conflict in matching of email addresses
	doesn't open	certificate select dialog
In-Reply-To: <1268063584.64.0.0985298050259.issue4197@kolab.org>
Message-ID: <1268063584.64.0.0985298050259.issue4197@kolab.org>


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

Tested with Gpg4win 2.0.2-rc2:
- Import OpenPGP certificate (a)
- Import X.509 certificate (b)
- (a) and (b) have the same email address (c) - e.g. gpg4winusera at test.hq

Test 1: Send an _encrypted_ email address to (c) with GpgOL
=> No certificate select dialog was shown! Expected because matching of email
address should bring a conflict - there are tho matching certificates: (a) and (b).
Receive and encrypt the mail
=> pinentry ask for passphrase of (b) = SMIME!

Test 2: Send an _signed/encrypted_ email address to (c) with GpgOL
=> No certificate select dialog! Pinentry ask for passphrase of (b) = SMIME!

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24047
nosy: emanuel, marc
priority: urgent
status: unread
title: Conflict in matching of email addresses doesn't open certificate select dialog

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


From issues at kolab.org  Tue Mar  9 12:28:25 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 09 Mar 2010 11:28:25 +0000
Subject: [Kolab-devel] [issue4198] Certificate Details: Show ownertrust,
	validity
In-Reply-To: <1268134105.96.0.644584184692.issue4198@kolab.org>
Message-ID: <1268134105.96.0.644584184692.issue4198@kolab.org>


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

There's no way in Kleopatra to see the ownertrust or validity of certificates
(OpenPGP ones).
Should be in the details dialog.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24060
nosy: bernhard, emanuel, marc, till
priority: feature
status: unread
title: Certificate Details: Show ownertrust, validity

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


From issues at kolab.org  Tue Mar  9 14:55:43 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 09 Mar 2010 13:55:43 +0000
Subject: [Kolab-devel] [issue4199] Certificate Details: Show validity of
	user-ids
In-Reply-To: <1268142943.44.0.148456581834.issue4199@kolab.org>
Message-ID: <1268142943.44.0.148456581834.issue4199@kolab.org>


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

Copy of issue 4198

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24063
nosy: bernhard, emanuel, marc, till
priority: feature
status: unread
title: Certificate Details: Show validity of user-ids

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


From issues at kolab.org  Tue Mar  9 15:39:18 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 09 Mar 2010 14:39:18 +0000
Subject: [Kolab-devel] [issue4200] Reminder date sorting doesn't recognize
	different	month.(rt#6047)
In-Reply-To: <1268145558.35.0.891780635774.issue4200@kolab.org>
Message-ID: <1268145558.35.0.891780635774.issue4200@kolab.org>


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

tested with Kontact e35 kdepim 20100305.1099262-kk1

Test:
1. Create an event at the 2010-03-09 with alarm.
2. Create an event at the 2010-04-10 with alarm.
3. Create an event at the 2010-03-16 with alarm.
4. Wait for the alarm.
=> The events in the reminder are not sorted by the date and the time, but by
the number of the day. They should be sorted after the date and the time.
See screenshot.

----------
assignedto: allen
files: reminder-wrong-sorting-20100309.png
keyword: enterprise35, kde client, kkc
messages: 24067
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Reminder date sorting doesn't recognize different month.(rt#6047)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4200>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reminder-wrong-sorting-20100309.png
Type: image/png
Size: 42749 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100309/f0720e13/reminder-wrong-sorting-20100309-0001.png

From issues at kolab.org  Wed Mar 10 10:24:14 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Mar 2010 09:24:14 +0000
Subject: [Kolab-devel] [issue4201] Spellchecking in composer:RMB->suggestion
	deletes wrong	word.(rt#6050)
In-Reply-To: <1268213054.59.0.116449495229.issue4201@kolab.org>
Message-ID: <1268213054.59.0.116449495229.issue4201@kolab.org>


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

tested with Kontact e35 20100305.1099262-kk1

Spellchecking in the composer: A user tries to correct a wrong word with
RMB->word suggestion, but the wrong word is deleted and the new suggestion is
not inserted.

Test:
1. Switch to mail component.
2. Open a composer.
3. Enter some wrong word.
4. RMB on a word word->Choose a suggestion.
=> The wrong word is deleted and the suggest is not inserted.

output:
ASSERT: "i <= nodes" in /usr/share/qt3/include/qvaluelist.h (376)

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24078
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Spellchecking in composer:RMB->suggestion deletes wrong word.(rt#6050)

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


From issues at kolab.org  Wed Mar 10 12:40:43 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 10 Mar 2010 11:40:43 +0000
Subject: [Kolab-devel] [issue4203] A reminder can contain non-existing
	events.(rt#6051)
In-Reply-To: <1268221243.88.0.735668845144.issue4203@kolab.org>
Message-ID: <1268221243.88.0.735668845144.issue4203@kolab.org>


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

tested with Kontact e35 kdepim 20100305.1099262-kk1

Test:
1. Create an event with alarm in a few minutes (e.g starttime 12:30).
2. Wait for the alarm.
3. Close the reminder with the X/close button in the titlebar.
4. Edit the event and add 2 minutes to the start time (e.g starttime 12:32)
5. Wait or the alarm.
=> The reminder now contains two events. (Startime 12:30, 12:32), but the first
event no longer exists.

The reminder should not contain entries for non-existing events.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24083
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: A reminder can contain non-existing events.(rt#6051)

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


From =?utf-8?b?QWxicmVjaHQgRHJlw58gPGlzc3Vlc0Brb2xhYi5vcmc+?= at issues.kolab.org  Thu Mar  4 10:25:17 2010
From: =?utf-8?b?QWxicmVjaHQgRHJlw58gPGlzc3Vlc0Brb2xhYi5vcmc+?= at issues.kolab.org (=?utf-8?b?QWxicmVjaHQgRHJlw58gPGlzc3Vlc0Brb2xhYi5vcmc+?=@issues.kolab.org)
Date: Thu, 04 Mar 2010 09:25:17 +0000
Subject: [Kolab-devel] [issue4186] Kolab filter PHP crashes
In-Reply-To: <1267694717.32.0.708009360943.issue4186@kolab.org>
Message-ID: <1267694717.32.0.708009360943.issue4186@kolab.org>


New submission from Albrecht Dreß <albrecht.dress at lios-tech.com>:

I see reproducible crashes when one user tries to create appointments for
himself, and inviting a shared "info" calendar.  The appointment is added to his
personal calendar, but he also gets a postmaster message with subject
"Undelivered Mail Returned to Sender" saying

<info at my-domain.com>: Command died with status 255: "/kolab/bin/php"

The file /kolab/var/kolab-filter/log/fatal.log contains a message

PHP Catchable fatal error:  Argument 1 passed to DOMNode::appendChild() must be
an instance of DOMNode, null given, called in
/kolab/lib/php/Horde/Kolab/Format/XML.php on line 798 and defined in
/kolab/lib/php/Horde/DOM.php on line 397

The related log entries in /kolab/var/kolab-filter/log/filter.log are attached.

The server is a self-compiled Kolab 2.2.3 on Ubuntu/Hardy x86_64.  The user
triggering the crash uses Outlook 2007 w/ the Toltec connector.  I think I
should also add here that I am able to create the similar appointment, including
the invitation for the "info" account", with Kontact.  Also, an other user using
the same versions of Outlook and Toltec has no problems with this.

----------
files: php-crash.log
messages: 23965
nosy: albrecht.dress
priority: urgent
status: unread
title: Kolab filter PHP crashes

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4186>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: php-crash.log
Type: text/x-log
Size: 7469 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100304/ad56dce6/php-crash.bin

From thomas at intevation.de  Wed Mar 10 16:50:55 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 10 Mar 2010 16:50:55 +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: <20100310154522.122106617.thomas@intevation.de>

* Thomas Arendsen Hein <thomas at intevation.de> [20100225 16:29]:
> 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.

So at the deadline and until now we have:
AU$0.02
+1
+1
-1 changed into a 0
(and of course two +1 from Sascha and me, but I wasn't sure if I
should count them, luckily it does not matter)

So the result is something between +2.02 and +5, which is not much,
but enough to approve the choice of Mercurial as the next SCM for
Kolab server development.

Thank you for participating in this little poll!

Next step is providing the infrastructure. While there already is
hg.intevation.org, we also wanted to create a Mercurial plugin for
wald.intevation.org, which currently runs GForge.

For the implementation Wald should be upgraded to a current
FusionForge installation, so we can write the plugin for a project
which is not dead, but I just noticed that this was already done:
gforge-plugin-scmhg (which despite the packaghe name is FusionForge)
is already available in Debian/experimental.

Emanuel (who wrote the Kolab Server 2.2 operating manual) already
created the project pages http://wald.intevation.org/projects/kolab/
and http://wald.intevation.org/projects/kolab-server/, currently
the kolab-users-de mailing list is hosted here.

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/20100310/b21b93ab/attachment.bin

From issues at kolab.org  Thu Mar 11 10:41:32 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Mar 2010 09:41:32 +0000
Subject: [Kolab-devel] [issue4204] Copying a contact to different resource
	breaks the	umlauts.
In-Reply-To: <1268300492.44.0.666805454068.issue4204@kolab.org>
Message-ID: <1268300492.44.0.666805454068.issue4204@kolab.org>


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

tested with Kontact e35 kdepim 20100305.1099262-kk1

Test:
Req: Two kolab contact resources
1. Swictch to the contacts component.
2. Select a contact with umlauts.
3. RMB->Copy.
4. Deactivate the resource where the contact is from.
5. RMB->Paste.
=> The umlauts of the contact are no longer displayed corretly. They are just
displayed as small rectangels. This is a problem. Something with the umlauts
handling is wrong.
Other tests would be to check cut+paste contacts, Copy to.., Move to..

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24098
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Copying a contact to different resource breaks the umlauts.

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


From issues at kolab.org  Thu Mar 11 13:14:49 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 11 Mar 2010 12:14:49 +0000
Subject: [Kolab-devel] [issue4205] Use kolabwizard to configure a second
	dimpa account, configuration broken.
In-Reply-To: <1268309689.73.0.786215701021.issue4205@kolab.org>
Message-ID: <1268309689.73.0.786215701021.issue4205@kolab.org>


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

tested with Kontact e35 kdepim 20100305.1101870-kk3

Test:
Req: kontact is configured with account A and not running.
1. $kolabwiard
=> Dialog appears: Really start?
2. Start assistent.
3. Enter the data of account B into the assistent and press okay.
=> KWallet asks for the password.
4. Enter the password.
5. Start kontact.
7. Open the mail conf dialog.
=> The account->receving list contain "Kolab-Server" twice. Edit them shows that
both accounts have the conf of account A. But in the mail folder list are two
different dimaps accounts after sync. So the edit dialog displays wrong information.
The account->sending list contains two default SMTP accounts. This is also
wrong. Both contain information of account B. Wrong.

The users want to use the kolabwizard to add new accounts to kontact.
This should add a new id, account->receiving and account->sending.
If Kolab-Server already exists, this new conf should be called Kolab-Server2, etc.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24110
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Use kolabwizard to configure a second dimpa account, configuration broken.

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


From issues at kolab.org  Thu Mar 11 14:46:01 2010
From: issues at kolab.org (Marc Mutz)
Date: Thu, 11 Mar 2010 13:46:01 +0000
Subject: [Kolab-devel] [issue4206] Offer to set ownertrust of imported keys
	after import
In-Reply-To: <1268315161.66.0.999013923306.issue4206@kolab.org>
Message-ID: <1268315161.66.0.999013923306.issue4206@kolab.org>


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

Esp. secret keys are not automatically set to ulitmate trust when importing.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24113
nosy: bernhard, emanuel, marc, till
priority: wish
status: unread
title: Offer to set ownertrust of imported keys after import

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


From issues at kolab.org  Fri Mar 12 12:40:58 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Mar 2010 11:40:58 +0000
Subject: [Kolab-devel] [issue4207] alarm time textfield in advanced alarm
	dialog should be	5-digits. (rt#6055)
In-Reply-To: <1268394058.13.0.331363903268.issue4207@kolab.org>
Message-ID: <1268394058.13.0.331363903268.issue4207@kolab.org>


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

Test:
1. Start to create a new event.
2. Set alarm on. Look at the alarm time field. It has 5-digits.
3. Click on advanced alarm.
=> The advanced alarm dialog pops up.
4. Look at the alarm time field in the advanced alarm dialog. It has 2-digits.
It should also have 5-digits to be consistent.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24129
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: alarm time textfield in advanced alarm dialog should be 5-digits. (rt#6055)

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


From issues at kolab.org  Fri Mar 12 12:54:34 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Mar 2010 11:54:34 +0000
Subject: [Kolab-devel] [issue4208] Wish: Calendar context menu option "Paste
	at original	time"
In-Reply-To: <1268394874.91.0.759760570241.issue4208@kolab.org>
Message-ID: <1268394874.91.0.759760570241.issue4208@kolab.org>


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

The customer asked for following feature:

The calendar context menu should have an additional option "Paste at original
time". This option should paste the event at the original starttime of the event
at the selected day.

Test (e.g.):
1. Switch to calendar.
2. Select an event at 2010-03-12 12:00
3. RMB->"Paste at original time" at the 2010-03-14 at 17:00 
=> the event is paste at the 2010-03-14 at 12:00.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24131
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: Calendar context menu option "Paste at original time"

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


From issues at kolab.org  Fri Mar 12 15:48:18 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 12 Mar 2010 14:48:18 +0000
Subject: [Kolab-devel] [issue4209] Monthview: drag'n'drop events does
	nothing, should move/resize the events. (rt#6049)
In-Reply-To: <1268405298.29.0.788742621246.issue4209@kolab.org>
Message-ID: <1268405298.29.0.788742621246.issue4209@kolab.org>


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

The user wants to move and resize the events in the monthview with drag and drop.
Like it is possible in the agenda view.

Test:
1. Switch to calendar component and activate the monthview.
2. Create a new event.
3. Drag the event and try to move it to a different day.
=> The event stays at the current day.
It should be possible to move an event this way.

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24138
nosy: allen, emanuel, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Monthview: drag'n'drop events does nothing, should move/resize the events. (rt#6049)

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


From issues at kolab.org  Mon Mar 15 12:21:26 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Mar 2010 11:21:26 +0000
Subject: [Kolab-devel] [issue4210] Self test dialog to small
In-Reply-To: <1268652086.88.0.478624118611.issue4210@kolab.org>
Message-ID: <1268652086.88.0.478624118611.issue4210@kolab.org>


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

The width of Kleopatra's self test dialog (in German) is to small. There is a
horizontally scroll bar by default.
Only for German dialog. The English dialog is ok.

Please increase default windows width for this dialog.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24164
nosy: emanuel, marc
priority: bug
status: unread
title: Self test dialog to small

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


From issues at kolab.org  Mon Mar 15 12:35:01 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Mar 2010 11:35:01 +0000
Subject: [Kolab-devel] [issue4211] Self test comes up in background after
	start up
In-Reply-To: <1268652901.28.0.303787609062.issue4211@kolab.org>
Message-ID: <1268652901.28.0.303787609062.issue4211@kolab.org>


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

Tested with Kleo 2.0.14 (Windows):

Start Kleopatra.
-> After splashscreen the self test appears (because one libkleopatrarc error
under windows) in _background_!

Note: This issue describe the background problem not the self test error.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24167
nosy: emanuel, marc
priority: bug
status: unread
title: Self test comes up in background after start up

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


From issues at kolab.org  Mon Mar 15 14:16:40 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Mar 2010 13:16:40 +0000
Subject: [Kolab-devel] [issue4212] Kleopatra hangs because pinentry-qt4
	comes not up
In-Reply-To: <1268659000.81.0.0497277232473.issue4212@kolab.org>
Message-ID: <1268659000.81.0.0497277232473.issue4212@kolab.org>


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

Tested with gpg4win-svn1359 + kdepim-r1102305 (kleo 2.0.14):

- Start Kleopatra
- Import openpgp secret key and set owner trust
- Start Outlook/gpgol
- Send an signed openpgp message with gpgol
=> Outlook and Kleopatra hangs because pinentry-qt4 doesn't comes up. A pinentry
procress was started but no dialog is opened! So Kleopatra couln't finish the
sign operation. The Outlook composer window freezed.
See attached kleo-log.

It's a critical issue!

----------
assignedto: marc
files: kleo-log.txt
keyword: gpg4win2, kleo
messages: 24180
nosy: emanuel, marc, werner
priority: critical
status: unread
title: Kleopatra hangs because pinentry-qt4 comes not up

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4212>
______________________________________
-------------- next part --------------
Startup timing: 516 ms elapsed: Application created 
Startup timing: 578 ms elapsed: UiServer created 
Startup timing: 594 ms elapsed: UiServer started 
UiServer: client connect on fd 1396
[3952.1396] DBG: -> OK GPG UI server (Kleopatra/2.0.14) ready to serve
UiServer: client connection 014CD868 established successfully
[3952.1396] DBG: <- GETINFO pid
[3952.1396] DBG: -> D 3952
[3952.1396] DBG: -> OK
Server PID = 3952 
[3952.1396] DBG: <- [Error: Resource temporarily unavailable]
AllowSetForegroundWindow( 3952 ) failed:  5 
[3952.1396] DBG: <- BYE
[3952.1396] DBG: -> OK closing connection
UiServer: connection 014CD868 closed
ArchiveDefinition[ "tar" ] ("tar", "cf", "-") 
Fehler in der Archiv-Definition tar: Befehl leer oder nicht gefunden 
ArchiveDefinition[ "zip" ] ("zip", "-r", "-", "%f") 
Fehler in der Archiv-Definition zip: Befehl leer oder nicht gefunden 
ArchiveDefinition[ "bzip2" ] ("tar", "cfj", "-") 
Fehler in der Archiv-Definition bzip2: Befehl leer oder nicht gefunden 
Startup timing: 4312 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 , 0x14e8770 ) 
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: 5547 ms elapsed: KeyCache loaded 
KeyFilterManager::reload: final filter count is 12
Startup timing: 5719 ms elapsed: new instance created 
scd_getattr_status( CHV-STATUS ): got ( status( "CHV-STATUS" ) = "3 3 3 0" 
) 
gpgagent_transact( SCD LEARN --keypairinfo ) 
parse_keypairinfo_and_lookup_key: pattern= &5873571FF1FC25D56F5884889EA7C3819A9428A6 
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &096AA67BD7ACB1AEB9E12DBBD49E7BC7B32F9D22 
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &1407AFEF9AB4783A717D984ADE74BC9638A13998 
parse_keypairinfo_and_lookup_key: e= 0 ; key.isNull() false 
parse_keypairinfo_and_lookup_key: pattern= &9C0FA63B05FAC1E913DB640D8B5419915BBE18C1 
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" ) = "101 0 101" 
) 
eventCounter: 101 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
UiServer: client connect on fd 1516
[3952.1516] DBG: -> OK GPG UI server (Kleopatra/2.0.14) ready to serve
UiServer: client connection 01563C18 established successfully
[3952.1516] DBG: <- GETINFO pid
[3952.1516] DBG: -> D 3952
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- [Error: Resource temporarily unavailable]
[3952.1516] DBG: <- OPTION window-id=30154
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- RESET
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- SESSION 2 test sig
session_handler: id=2, title=test sig
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- SENDER -- gpg4winusera at test.hq
[3952.1516] DBG: -> # ok, parsed as "gpg4winusera at test.hq"
[3952.1516] DBG: -> # matching OpenPGP key B726CB6BD1BB45392621CD598B59AB93C6BF6664
[3952.1516] DBG: -> S PROTOCOL OpenPGP
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- INPUT FD=1148
KDPipeIODevice::doOpen (01581E28): created reader (015835B0) for fd -1
AssuanServerConnection: added "Nachricht #1" 
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- OUTPUT FD=1028
KDPipeIODevice::doOpen (015884A0): created writer (015A90E0) for fd -1
AssuanServerConnection: added "" 
[3952.1516] DBG: -> OK
[3952.1516] DBG: <- SIGN --protocol=OpenPGP --detached
015832E8: KDPipeIODevice::readData: data=0158E588, maxSize=512
KDPipeIODevice::Private::startReaderThread(): locking reader (CONSUMER THREAD)
KDPipeIODevice::Private::startReaderThread(): locked reader (CONSUMER THREAD)
KDPipeIODevice::Private::startReaderThread(): waiting for hasStarted (CONSUMER THREAD)
015835B0: Reader::run: started
015835B0: Reader::run: rptr=0, wptr=0 -> numBytes=4096
015835B0: Reader::run: trying to read 4096 bytes from fd -1
015835B0 (fd=-1): Reader::run: read 100 bytes
015835B0 (fd=-1): Reader::run: Content-Type: text/plain;

	charset="us-ascii"

Content-Transfer-Encoding: 7bit



test

23456z7u8


015835B0: Reader::run: buffer before: rptr=   0, wptr=   0
015835B0: Reader::run: buffer after:  rptr=   0, wptr= 100
015835B0: Reader::run: buffer no longer empty, waking everyone
notifyReadyRead: 100 bytes available
notifyReadyRead: emit signal
KDPipeIODevice::Private::startReaderThread(): returned from hasStarted (CONSUMER THREAD)
015832E8: KDPipeIODevice::readData: try to lock reader (CONSUMER THREAD)
015832E8: KDPipeIODevice::readData: locked reader (CONSUMER THREAD)
015832E8: KDPipeIODevice::readData: got bufferNotEmptyCondition, trying to read 100 bytes
015835B0: KDPipeIODevice::readData: data=0158E588, maxSize=100; rptr=0, wptr=0 (bytesInBuffer=100); -> numRead=100
015835B0: KDPipeIODevice::readData: signal bufferNotFullCondition
015832E8: KDPipeIODevice::readData: read 100 bytes
015832E8 (fd=-1): KDPipeIODevice::readData: Content-Type: text/plain;

	charset="us-ascii"

Content-Transfer-Encoding: 7bit



test

23456z7u8


notifyReadyRead: returning from waiting, leave
015835B0: Reader::run: rptr=0, wptr=0 -> numBytes=4096
015835B0: Reader::run: trying to read 4096 bytes from fd -1
015835B0: Reader::run: got eof (broken pipe)
015835B0 (fd=-1): Reader::run: read 0 bytes
015835B0 (fd=-1): Reader::run: Content-Type: text/plain;

	charset="us-ascii"

Content-Transfer-Encoding: 7bit



test

23456z7u8


015835B0: Reader::run: received eof(1) or error(0), waking everyone
notifyReadyRead: 0 bytes available
notifyReadyRead: emit signal
KDPipeIODevice::Private::emitReadyRead 01581E28
KDPipeIODevice::Private::emitReadyRead 01581E28: locking reader (CONSUMER THREAD)
KDPipeIODevice::Private::emitReadyRead 01581E28: locked reader (CONSUMER THREAD)
KDPipeIODevice::Private::emitReadyRead 01581E28: buffer empty: 1 reader in ReadFile: 0
notifyReadyRead: returning from waiting, leave
KDPipeIODevice::Private::emitReadyRead 01581E28 leaving
KDPipeIODevice::Private::emitReadyRead 01581E28
KDPipeIODevice::Private::emitReadyRead 01581E28: locking reader (CONSUMER THREAD)
KDPipeIODevice::Private::emitReadyRead 01581E28: locked reader (CONSUMER THREAD)
KDPipeIODevice::Private::emitReadyRead 01581E28: buffer empty: 1 reader in ReadFile: 0
KDPipeIODevice::Private::emitReadyRead 01581E28 leaving
015832E8: KDPipeIODevice::readData: data=0158E588, maxSize=512
015832E8: KDPipeIODevice::readData: try to lock reader (CONSUMER THREAD)
015832E8: KDPipeIODevice::readData: locked reader (CONSUMER THREAD)
015832E8: KDPipeIODevice::readData: got empty buffer, signal eof
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ
ReaderStatusThread[2nd]: .oOO
ReaderStatusThread[2nd]: new iteration command= "__check__"  ; nullSlot= true 
gpgagent_transact( GETEVENTCOUNTER ) 
get_event_counter(): got ( status( "EVENTCOUNTER" ) = "101 0 101" 
) 
ReaderStatusThread[2nd]: .zZZ

From issues at kolab.org  Mon Mar 15 14:25:19 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 15 Mar 2010 13:25:19 +0000
Subject: [Kolab-devel] [issue4213] Format Choice dialog comes up in
	background
In-Reply-To: <1268659519.51.0.559444915993.issue4213@kolab.org>
Message-ID: <1268659519.51.0.559444915993.issue4213@kolab.org>


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

Tested with gpg4win-svn1359 + kdepim-r1102305 (kleo 2.0.14):

- Install gpg4win.
- Start Kleopatra.
- Import your own openpgp and smime certificates.
- Start Outlook with GpgOL.
- Send an signed message with GpgOL.
=> Format Choice dialog (see attachment) comes up in background!

----------
assignedto: marc
files: format-choice-dialog.png
keyword: gpg4win2, kleo
messages: 24182
nosy: emanuel, marc
priority: urgent
status: unread
title: Format Choice dialog comes up in background

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4213>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: format-choice-dialog.png
Type: image/png
Size: 9027 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100315/aaeb1264/format-choice-dialog-0001.png

From issues at kolab.org  Mon Mar 15 15:31:50 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 15 Mar 2010 14:31:50 +0000
Subject: [Kolab-devel] [issue4214] Calendar not-organizer can change event
	and organizor	doesn't get update mail but other attendees get
	updates.
In-Reply-To: <1268663510.89.0.291170954704.issue4214@kolab.org>
Message-ID: <1268663510.89.0.291170954704.issue4214@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103167-kk5

Test:
1. A invites B and C.
2. B and C accept.
3. B changes the event.
(He is not asked, if he wants to send update mails)
=> C gets an update mail from B, that the organizor had changed the event.
=> But A is not informed about the changed event.
4. C records this into his calendar.
Broken in many ways.

I think this is created by kolab/issue4096. Anyway this is broken.
B should only change the event locally. No update mail should be sent.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24188
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: critical
status: unread
title: Calendar not-organizer can change event and organizor doesn't get update mail but other attendees get updates.

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


From issues at kolab.org  Mon Mar 15 20:05:18 2010
From: issues at kolab.org (Sergio Martins)
Date: Mon, 15 Mar 2010 19:05:18 +0000
Subject: [Kolab-devel] [issue4215] Events ending at 00h appear in the wrong
	day in day-view
In-Reply-To: <1268679918.2.0.514425971911.issue4215@kolab.org>
Message-ID: <1268679918.2.0.514425971911.issue4215@kolab.org>


New submission from Sergio Martins <sergio at kdab.com>:

1. Create an event starting at 18h and ending at 00h (duration = 6 hours ), at
March 15th.

2. Click on March 15th, in the mini-calendar. Agenda will turn into Day-View and
you'll see your event at 18h.

3. Now, click on March 16th, the event appears again, at the same time (18h),
which is wrong.

4. If you select two days (15 and 16) everything is correct.

----------
assignedto: sergio
keyword: enterprise35, kde client
messages: 24204
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: in-progress
title: Events ending at 00h appear in the wrong day in day-view

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


From kanarip at kanarip.com  Tue Mar 16 13:27:42 2010
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Tue, 16 Mar 2010 13:27:42 +0100
Subject: [Kolab-devel] Introduction
Message-ID: <4B9F793E.20200@kanarip.com>

Hello there,

I wanted to briefly introduce myself, before I start firing off all
kinds of questions and remarks and such more.

My name is Jeroen van Meeuwen. I'm Dutch and I sincerely apologize for that.

My resume is on the world-wide web, but if I were to highlight the most
relevant aspects, I'd say I'm a Fedora (and all derivatives) packaging
guru, inherently an admittedly naive RPM enthusiast, (continuous
integration) build environment wizard, pragmatic source code management
fanatic, absolutely anti-OpenPKG, absolutely anti-OpenPKG, and a little
anti-OpenPKG.

Looking forward to working with you / meeting you all ;-)

-- Jeroen


From christoph.wickert at googlemail.com  Tue Mar 16 16:51:11 2010
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 16 Mar 2010 16:51:11 +0100
Subject: [Kolab-devel] Yet another Introduction (was Re: Introduction)
In-Reply-To: <4B9F793E.20200@kanarip.com>
References: <4B9F793E.20200@kanarip.com>
Message-ID: <1268754671.2656.39.camel@wicktop.localdomain>

After Jeroen was so kind to introduce himself, I'd like to do the same.
Here we go:

My Name is Christoph Wickert, I'm 34 years old and currently working as
self employed IT consultant at M?nster, Germany. Yes, I'm German, but
no, I'm not going to apologize for that. ;)

Like Jereon I'm a Fedora packager too. Fore more info about my work on
Fedora, see [?]. Before I joined Fedora, I used Debian and did some
packaging there too. I hate installing anything from source and whatever
gets installed on any of my systems gets installed with proper package
management.

While we are at it: OpenPKG is NOT what I'd call proper package
management and install-kolab.sh is even worse. That's why I will work
with Jeroen on providing native packages.

There are quite a lot of packages floating around at the moment and FWIW
many of them are not needed. Instead of maintaining custom packages we
should focus on upstreaming our changes. I know it will be a lot of work
and well take some time, but I'm convinced that it will pay off in long
term.

While Jeroen is more the build system wizard and the genius, I'm more
the pedantic packager. I apologize for being boring and pedantic but I
can't help it: Remember, I'm German. I want to enforce higher packaging
quality and I hope we manage to do this without to much pain for
everyone involved.

I'm looking forward to work with all of you to get kolab into Fedora and
RHEL and to improve the Debian packages.

Have fun,
Christoph

[?] http://fedoraproject.org/wiki/User:Cwickert


From thomas at intevation.de  Tue Mar 16 17:40:07 2010
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 16 Mar 2010 17:40:07 +0100
Subject: [Kolab-devel] New Root Certificate Authority for Intevation (and
	thus kolab.org)
Message-ID: <20100316173434.934585075.thomas@intevation.de>

Hi!

Our new PKI went productive today and we will exchange the SSL
certificates of all servers (e.g. issues.kolab.org and
files.kolab.org) before March 24th, 2010.

Please import our new Root CA from https://ssl.intevation.de/
if you want to establish a complete trust path to our servers.

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/20100316/d860753d/attachment.bin

From greve at kolabsys.com  Wed Mar 17 09:04:35 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Wed, 17 Mar 2010 09:04:35 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
Message-ID: <201003170904.36553.greve@kolabsys.com>

Hi all,

Alain Abbas and myself have been sitting together on Monday to discuss the 
roadmap for completing ActiveSync integration in Kolab.

This follows on some early discussions and a meeting that Paul and I had with 
CeBIT where we agreed to work together on Z-Push with the people at Zarafa, so 
the Kolab connector to Z-Push would become part of the main Z-Push repository.

Everything starts off with another release of the current code during this 
week. As of next week, development will focus on

        - Finish update to Z-Push 1.3
        - Complete subfolder support
        - Special characters (accents & umlauts) support
        - Track down & resolve push issues
                (Alain discovered last week there is a  memory leak on
                the server when using the iPhone's push synchronisation
		feature.)

to be release for testing the week after (week 13). Everyone interested in 
ActiveSync functionality is then encouraged to test this as much as possible 
in order for a release in week 14. Weeks 15 & 16 will see development on

 	- Annotation & Configuration Management (see below)
        - Cut off date implementation (complication: recurrence)
        - Z-Push module configuration management
        - ACL for ActiveSync (which user is allowed to use it)

with week 17 for testing. This will be followed by similar cycles to complete 
the functionality and provide some cleanup in the backend to prepare for the 
1.0 release in a few months.

For the moment, the bigger issue is the configuration management, which we have 
begun discussing internally with Thomas, Sascha and others and believe that 
the best (and most "Kolabian") way forward is likely to store this in the IMAP 
annotatemore extensions.

So we plan to introduce a

	/vendor/kolab/activesync

which defaults to YES, if not set, and which is a string of the format

                <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]

        with <BOOL> = 1 or 0 (for yes or no)
        and <SERIAL NO> = serial number of the phone

to allow a per-device setting of synchronisation preferences.

In order to make these preferences per-user, this annotation needs to be per-
user-writeable, including for

	(a) shared folders where user has at least (but maybe only) read access
        (b) other user's folders to which the user has read access (or more)

The IMAP annotatemore extension allows for namespaces, see

	http://tools.ietf.org/html/draft-daboo-imap-annotatemore-17#section-3.2

so this would be defined as a private (and thus living in the user specific 
namespace) annotation that should be set by each user for any folder where 
they have read access (or more).

This should work according to specification, but the question is whether it is 
currently implemented in Cyrus, and how. Has someone tried this before? Is 
someone willing to help us test this to make sure it works?

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100317/0dda2b5a/attachment.bin

From bh at intevation.de  Wed Mar 17 12:43:42 2010
From: bh at intevation.de (Bernhard Herzog)
Date: Wed, 17 Mar 2010 12:43:42 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003170904.36553.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
Message-ID: <201003171243.43053.bh@intevation.de>

On 17.03.2010, Georg C. F. Greve wrote:

> So we plan to introduce a
>
> 	/vendor/kolab/activesync
>
> which defaults to YES, if not set, and which is a string of the format
>
>                 <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
>
>         with <BOOL> = 1 or 0 (for yes or no)
>         and <SERIAL NO> = serial number of the phone
>
> to allow a per-device setting of synchronisation preferences.
>
> In order to make these preferences per-user, this annotation needs to be
> per- user-writeable, including for
>
> 	(a) shared folders where user has at least (but maybe only) read access
>         (b) other user's folders to which the user has read access (or
> more)
>
> The IMAP annotatemore extension allows for namespaces, see
>
> 	http://tools.ietf.org/html/draft-daboo-imap-annotatemore-17#section-3.2
> 
> so this would be defined as a private (and thus living in the user specific
> namespace) annotation that should be set by each user for any folder where
> they have read access (or more).
>
> This should work according to specification, but the question is whether it
> is currently implemented in Cyrus, and how.

IIRC Cyrus IMAPd actually implements an older version of that draft, 
draft-daboo-imap-annotatemore-05, which is somewhat different.

In the older draft, setting a private annotation would be e.g.

x SETANNOTATION "INBOX/Kalender" "/vendor/kolab/activesync" ("value.priv" "1")

A public annotation would use "value.shared". Reading would be

x GETANNOTATION "INBOX/Kalender" "/vendor/kolab/activesync" "value.priv"

Private annotations seem to work at least for folders owned by the user and 
the "/vendor/kolab/folder-type" annotation (just tested that a little).

The newer drafts and the actual RFC that came out of it (rfc5464) make 
private, i.e. per user, annotations optional, though.  Kolab could make them 
mandatory for the activesync support, of course, but it could make it more 
difficult to switch from cyrus to some other imap server, like dovecot.
Publich annotations/metadata are easier to implement than private ones.


Regards

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100317/f8f2656c/attachment.bin

From issues at kolab.org  Wed Mar 17 14:05:12 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 13:05:12 +0000
Subject: [Kolab-devel] [issue4216] Spellchecking: After replacement is a
	correct word is	displayed in red.
In-Reply-To: <1268831112.92.0.0909265422092.issue4216@kolab.org>
Message-ID: <1268831112.92.0.0909265422092.issue4216@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Open a composer.
2. Enter a test line containing a wrong word.
=> The wrong word is displayed in red color.
3. Open Tools->Spellchecking
4. Replace the wrong word. Finish.
=> The correct word is displayed in red color.
This is a small problem and should not happen. A correct word should be
displayed in black color.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24230
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Spellchecking: After replacement is a correct word is displayed in red.

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


From issues at kolab.org  Wed Mar 17 14:17:09 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 13:17:09 +0000
Subject: [Kolab-devel] [issue4217] Spellchecking: inconsistence ignore all
	in context menu	vs dialog
In-Reply-To: <1268831829.12.0.605624863409.issue4217@kolab.org>
Message-ID: <1268831829.12.0.605624863409.issue4217@kolab.org>


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

If the action "ignore all" from the context menu is used on a red word, all this
word will become lack. If the action "ignore all" in the Tools->Spellchecking..
dialog is used on a red word, the word will stay red. 
This is a bit inconsistent.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24231
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Spellchecking: inconsistence ignore all in context menu vs dialog

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


From issues at kolab.org  Wed Mar 17 14:58:21 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 13:58:21 +0000
Subject: [Kolab-devel] [issue4218] Tasks: Copy to of a recurring event
	forgets the	recurrence.
In-Reply-To: <1268834301.63.0.596501580954.issue4218@kolab.org>
Message-ID: <1268834301.63.0.596501580954.issue4218@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the todo component.
2. Create a todo with weekly recurrence (start/due: today times:yes)
3. RMB->Copy to...and select tomorrow in the date dialog.
=> The recurrence gets lost.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24239
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Tasks: Copy to of a recurring event forgets the recurrence.

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


From issues at kolab.org  Wed Mar 17 15:06:16 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 14:06:16 +0000
Subject: [Kolab-devel] [issue4219] Tasks: Copy, Select nothing,
	Paste of a subtask copies it as subtask.
In-Reply-To: <1268834776.43.0.555269071697.issue4219@kolab.org>
Message-ID: <1268834776.43.0.555269071697.issue4219@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the todo component.
2. Create a task
3. Create a subtask of the first task.
4. Select the subtask.
5. Edit->Copy.
6. Select no task.
7. Edit->Paste
=> The task is copied as subtask of the first task, but this first task was not
selected. I expect that the task is copied to the upper hierarchy.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24240
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Tasks: Copy, Select nothing, Paste of a subtask copies it as subtask.

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


From issues at kolab.org  Wed Mar 17 15:34:45 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 14:34:45 +0000
Subject: [Kolab-devel] [issue4220] Calander tabular view ,
	side-by-side tab Move an event asks for resource.
In-Reply-To: <1268836485.49.0.343694852824.issue4220@kolab.org>
Message-ID: <1268836485.49.0.343694852824.issue4220@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the calendar component and tabular view.
2. Switch to side-by-side view.
3. Move a event with recurrence.
=> recurrence handling dialog pops up.
4. Choose future events.
=> A resource chooser dialog pops up. But kontact should know the resource in
this case.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24242
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Calander tabular view , side-by-side tab Move an event asks for resource.

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


From issues at kolab.org  Wed Mar 17 15:39:20 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 17 Mar 2010 14:39:20 +0000
Subject: [Kolab-devel] [issue4221] Abort in the choose dialog removes a
	recurring event.
In-Reply-To: <1268836760.93.0.278062222624.issue4221@kolab.org>
Message-ID: <1268836760.93.0.278062222624.issue4221@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the calendar component, tab view, side-by-side tab.
2. Create an event with daily recurrence.
3. Move the event.
4. Choose future ones.
=> resource dialog appears(wrong).
5. Click on Abort.
=> The event is removed.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24244
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Abort in the choose dialog removes a recurring event.

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


From alain.abbas at libertech.fr  Wed Mar 17 19:41:10 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Wed, 17 Mar 2010 19:41:10 +0100
Subject: [Kolab-devel] New release : Kolab backend 0.3 for z-push
Message-ID: <4BA12246.5070005@libertech.fr>

hi all

We have releazed the versoion 0.3 of kolab Zpush backend.

http://wiki.kolab.org/index.php/Z_push

Regards
Alain Abbas
Libertech


From greve at kolabsys.com  Wed Mar 17 19:50:47 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Wed, 17 Mar 2010 19:50:47 +0100
Subject: [Kolab-devel] New release : Kolab backend 0.3 for z-push
In-Reply-To: <4BA12246.5070005@libertech.fr>
References: <4BA12246.5070005@libertech.fr>
Message-ID: <201003171950.47809.greve@kolabsys.com>

On Wednesday 17 March 2010 19:41:10 Alain Abbas wrote:
> http://wiki.kolab.org/index.php/Z_push

Thanks, Alain!

"Let's go hunt that bug" challenge for everyone: In order to make it more 
interesting, this version has a memory leak on the server with iPhones when 
putting them on "push" mode, for which debugging help would be most useful.

If you can help Alain find it, he'll be able to push out the next test 
candidate, which should then include:

       - Finish update to Z-Push 1.3
        - Complete subfolder support
        - Special characters (accents & umlauts) support

and will hopefully already be located in the Z-Push repository.

The hunt is on. :)

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100317/b3911f2d/attachment-0001.bin

From wrobel at pardus.de  Wed Mar 17 22:31:59 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 17 Mar 2010 22:31:59 +0100
Subject: [Kolab-devel] Poll: Kolab server switching to Mercurial SCM?
In-Reply-To: <20100310154522.122106617.thomas@intevation.de>
References: <20100225150155.723599004.thomas@intevation.de>
	<20100310154522.122106617.thomas@intevation.de>
Message-ID: <20100317223159.16086kxnsnhf7rks@webmail.pardus.de>

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

> * Thomas Arendsen Hein <thomas at intevation.de> [20100225 16:29]:
>> 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.
>
> So at the deadline and until now we have:
> AU$0.02
> +1
> +1
> -1 changed into a 0
> (and of course two +1 from Sascha and me, but I wasn't sure if I
> should count them, luckily it does not matter)
>
> So the result is something between +2.02 and +5, which is not much,
> but enough to approve the choice of Mercurial as the next SCM for
> Kolab server development.
>
> Thank you for participating in this little poll!
>
> Next step is providing the infrastructure. While there already is
> hg.intevation.org, we also wanted to create a Mercurial plugin for
> wald.intevation.org, which currently runs GForge.
>
> For the implementation Wald should be upgraded to a current
> FusionForge installation, so we can write the plugin for a project
> which is not dead, but I just noticed that this was already done:
> gforge-plugin-scmhg (which despite the packaghe name is FusionForge)
> is already available in Debian/experimental.
>
> Emanuel (who wrote the Kolab Server 2.2 operating manual) already
> created the project pages http://wald.intevation.org/projects/kolab/
> and http://wald.intevation.org/projects/kolab-server/, currently
> the kolab-users-de mailing list is hosted here.

Do you have a rough idea when the switch might happen?

Thanks!

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



From issues at kolab.org  Thu Mar 18 10:53:27 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Mar 2010 09:53:27 +0000
Subject: [Kolab-devel] [issue4222] Crash in
	(KMMessage::setTransferInProgress at	kmmessage.cpp:248) while
	printing a mail(rt#6025)
In-Reply-To: <1268906007.12.0.521501120528.issue4222@kolab.org>
Message-ID: <1268906007.12.0.521501120528.issue4222@kolab.org>


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

The customer reported a crash, which happens while printing a mail.

See the backtrace.
Please have a short look at at it.

----------
assignedto: allen
files: 100210_kontact.kcrash
keyword: enterprise35, kde client, kkc
messages: 24261
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Crash in (KMMessage::setTransferInProgress at kmmessage.cpp:248) while printing a mail(rt#6025)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4222>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 100210_kontact.kcrash
Type: application/octet-stream
Size: 2645 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100318/a2470fd2/100210_kontact.exe

From issues at kolab.org  Thu Mar 18 11:15:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Mar 2010 10:15:06 +0000
Subject: [Kolab-devel] [issue4223] Calendar: Move a whole day event leads to
	small overlap	problem.
In-Reply-To: <1268907306.01.0.241214965095.issue4223@kolab.org>
Message-ID: <1268907306.01.0.241214965095.issue4223@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the calendar component.
2. Select three days.
3. Create a whole day event at the first day.
4. Create a whole day event at the third day.
5. Create a 3-days event at all three days.
6. Drag on the first event. Move to the third day. Move back to the first day.
   Release the drag. (The event should not change.)
=> The first event overlaps the third one. This is a wrong display.

See screenshot (different titles of the events.)

----------
assignedto: allen
files: overlaping-events-20100318.png
keyword: enterprise35, kde client
messages: 24263
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Calendar: Move a whole day event leads to small overlap problem.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4223>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overlaping-events-20100318.png
Type: image/png
Size: 13951 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100318/7e01ba82/overlaping-events-20100318-0001.png

From issues at kolab.org  Thu Mar 18 12:12:32 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Mar 2010 11:12:32 +0000
Subject: [Kolab-devel] [issue4224] event viewer dialog to small. (rt#6060)
In-Reply-To: <1268910752.86.0.0431198145392.issue4224@kolab.org>
Message-ID: <1268910752.86.0.0431198145392.issue4224@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the calendar component
2. Select an event.
3. RMB->Show.
=> A small event viewer pops up.
The customer wants the event viewer window to be larger.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24264
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: event viewer dialog to small. (rt#6060)

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


From issues at kolab.org  Thu Mar 18 12:52:30 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Mar 2010 11:52:30 +0000
Subject: [Kolab-devel] [issue4225] small month view: selected weekend days
	and holidays	should be colored red in blue (rt#6061)
In-Reply-To: <1268913150.35.0.565588043345.issue4225@kolab.org>
Message-ID: <1268913150.35.0.565588043345.issue4225@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Test:
1. Switch to the calendar component.2
2. Select a weekend day in the small month view /navigator (upper left)
=> the selected field is displayed white with blue background. Should be red in
blue, if the color of the day is red in unselected state.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24265
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: small month view: selected weekend days and holidays should be colored red in blue (rt#6061)

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


From issues at kolab.org  Thu Mar 18 13:44:16 2010
From: issues at kolab.org (Heiner)
Date: Thu, 18 Mar 2010 12:44:16 +0000
Subject: [Kolab-devel] [issue4226] Exclusions of recurring events done in
	Horde are not	shown in Kontact
In-Reply-To: <1268916256.38.0.588546044713.issue4226@kolab.org>
Message-ID: <1268916256.38.0.588546044713.issue4226@kolab.org>


New submission from Heiner <mephisto at gmx.net>:

In current Kolab 2.2.3 when adding exclusions to recurring events from the web
interface/Horde, these exclusions are ignored by kontact (KDE 3.5 version).

It is working the other way: deleting single occurrences of a recurring event in
Kontact will also remove them in Horde. However, if this information is then
modified through Horde by e.g. deleting another occurrence of the event, all
exclusion information in kontact is lost (Horde still shows correct info).

----------
messages: 24266
nosy: jaywalker
priority: bug
status: unread
title: Exclusions of recurring events done in Horde are not shown in Kontact

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


From issues at kolab.org  Thu Mar 18 14:15:17 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 18 Mar 2010 13:15:17 +0000
Subject: [Kolab-devel] [issue4227] To-do: time associate flag not saved at a
	starttime only	event.
In-Reply-To: <1268918117.39.0.129320302288.issue4227@kolab.org>
Message-ID: <1268918117.39.0.129320302288.issue4227@kolab.org>


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

tested with Kontact e35 kdepim 20100312.1103674-kk7

Problems with set start time. time associate flag not saved.

Test:
1. Switch to the todos component.
2. Create a new todo (only startdate and start time, set time associate)
3. Reopen the test todo.
=> The time associate checkbox isn't set.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24267
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: To-do: time associate flag not saved at a starttime only event.

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


From issues at kolab.org  Fri Mar 19 10:20:29 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Fri, 19 Mar 2010 09:20:29 +0000
Subject: [Kolab-devel] [issue4229] Kontact hangs when switching to calendar
	with incorrect	interval tag in event (rt#6063)
In-Reply-To: <1268990429.34.0.361991469596.issue4229@kolab.org>
Message-ID: <1268990429.34.0.361991469596.issue4229@kolab.org>


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

Tested with Kontact enterprise35 20100312.1103674:

- create new calendar folder in KMail
- sync
- save incorrect events [1] in IMAP calendar folder on server side
- sync Kontact (in KMail view)
-> events now visible in calender folder (via KMail)
- switch to calendar component
=> Kontact hangs while reading events of calendar!

[1] I get 5 problematical events from our customer. Note: The events are
confidential, so I'll send the files in personal mail to allen.

All 5 events are event with recurrence and have a empty "<interval></interval>"
tag. The Kolab format spec requires a number as value:
"<interval>(number, default 1)</interval>"
(see http://kolab.org/doc/kolabformat-2.0rc7-html/c300.html)

All 5 events are created by "User-Agent: proko2/resmgr". Probably a Kolab Server
issue because the resmgr accepts automatically new invitations.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24293
nosy: allen, emanuel
priority: critical
status: unread
title: Kontact hangs when switching to calendar with incorrect interval tag in event (rt#6063)

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


From info at alvin.be  Tue Mar 16 21:11:01 2010
From: info at alvin.be (Alvin)
Date: Tue, 16 Mar 2010 21:11:01 +0100
Subject: [Kolab-devel] New Root Certificate Authority for Intevation
	(and thus kolab.org)
In-Reply-To: <20100316173434.934585075.thomas@intevation.de>
References: <20100316173434.934585075.thomas@intevation.de>
Message-ID: <201003162111.01621.info@alvin.be>

On Tuesday 16 March 2010 17:40:07 Thomas Arendsen Hein wrote:
> Hi!
> 
> Our new PKI went productive today and we will exchange the SSL
> certificates of all servers (e.g. issues.kolab.org and
> files.kolab.org) before March 24th, 2010.
> 
> Please import our new Root CA from https://ssl.intevation.de/
> if you want to establish a complete trust path to our servers.

Hey, don't laugh with us, poor KDE4 users!
We might be using 'The Kolab Client', but importing root certificates has been 
only a dream so far:
https://bugs.kde.org/show_bug.cgi?id=162485


From adams at kolabsys.com  Fri Mar 19 11:54:48 2010
From: adams at kolabsys.com (Paul James Adams)
Date: Fri, 19 Mar 2010 10:54:48 +0000
Subject: [Kolab-devel] New release : Kolab backend 0.3 for z-push
In-Reply-To: <4BA12246.5070005@libertech.fr>
References: <4BA12246.5070005@libertech.fr>
Message-ID: <201003191054.52632.adams@kolabsys.com>

Hi Alain (et al),

On Wednesday 17 Mar 2010 18:41:10 Alain Abbas wrote:
> We have releazed the versoion 0.3 of kolab Zpush backend.

Does this combination of Z-Push 1.3 and backend 0.3 still support the 
"debug.txt" file for logging errors?

I have tried to sync my Nokia 5800 but I am only able to sync my email Inbox. 
As soon as I try and sync anything else I get an error saying "System Error. 
Try again later."

Without any server-side debugging to go on, I am stuck.


All the best,
Paul

-- 
Dr. Paul J. Adams
Chief Operating Officer

Kolab Systems AG
Zurich, Switzerland

e: adams at kolabsys.com
t: +447745 133 285
w: http://kolabsys.com

pgp: 899674F6 Paul James Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100319/c4f30ee1/attachment.bin

From alain.abbas at libertech.fr  Fri Mar 19 12:31:35 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Fri, 19 Mar 2010 12:31:35 +0100
Subject: [Kolab-devel] New release : Kolab backend 0.3 for z-push
In-Reply-To: <201003191054.52632.adams@kolabsys.com>
References: <4BA12246.5070005@libertech.fr>
	<201003191054.52632.adams@kolabsys.com>
Message-ID: <4BA36097.7050005@libertech.fr>

Paul James Adams a ?crit :
> Hi Alain (et al),
>
> On Wednesday 17 Mar 2010 18:41:10 Alain Abbas wrote:
>   
>> We have releazed the versoion 0.3 of kolab Zpush backend.
>>     
>
> Does this combination of Z-Push 1.3 and backend 0.3 still support the 
> "debug.txt" file for logging errors?
>
>   
yes like in the old version
> I have tried to sync my Nokia 5800 but I am only able to sync my email Inbox. 
> As soon as I try and sync anything else I get an error saying "System Error. 
> Try again later."
>
>   
could you check the url ?  http://1.2.3.4/Microsoft ...  ?
this is a fresh install ?
if you have nothing in debug.txt means that the error is at the 
beginning , check your config.php and config-kolab.php

> Without any server-side debugging to go on, I am stuck.
>
>
> All the best,
> Paul
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From issues at kolab.org  Fri Mar 19 12:32:39 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 19 Mar 2010 11:32:39 +0000
Subject: [Kolab-devel] [issue4230] Todo: alarm 0 mins vs 1 min in advanced
	alarm dialog.
In-Reply-To: <1268998359.34.0.0804128446127.issue4230@kolab.org>
Message-ID: <1268998359.34.0.0804128446127.issue4230@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105128-kk2

Test:
1. Switch to the todo component.
2. Start to create a new todo.
3. Set alarm on. 
4. Set alarm time to 0 mins.
5. Click on "Advanced..."
=> The advanced alarm is set to 1 min before due. 
  I expect that here also the 0 mins is used.
=>Ok in the advanced dialog creates an advanced reminder and I cannot change the
alarm time in the todo dialog anymore.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24297
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Todo: alarm 0 mins vs 1 min in advanced alarm dialog.

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


From issues at kolab.org  Fri Mar 19 13:04:54 2010
From: issues at kolab.org (Heiner)
Date: Fri, 19 Mar 2010 12:04:54 +0000
Subject: [Kolab-devel] [issue4231] Synchronisation of EXDATE with Nokia does
	not work
In-Reply-To: <1269000294.35.0.290326789231.issue4231@kolab.org>
Message-ID: <1269000294.35.0.290326789231.issue4231@kolab.org>


New submission from Heiner <mephisto at gmx.net>:

When synchronizing recurring events with more than one exceptions to a Nokia
phone via SyncML, the exceptions are lost. This is true for both directions
(mobile to server and vice versa): at most one exception is transmitted.

This is due to different EXDATE:xxxx formats in the underlying text/calendar
data formats of the Nokia mobile and the kolab server.

I have written a patch against
/kolab/var/kolab/www/client/lib/SyncML/Device/Nokia.php that does the required
format conversions in both directions. For me the patch is working, besides
issue4226 (excluded dates are not correctly shown in Kontact).

Best regards,
Heiner

----------
files: exdate-nokia-sync.diff
messages: 24300
nosy: jaywalker
status: unread
title: Synchronisation of EXDATE with Nokia does not work

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4231>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: exdate-nokia-sync.diff
Type: text/x-diff
Size: 5937 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100319/18c13bbb/exdate-nokia-sync.bin

From adams at kolabsys.com  Fri Mar 19 15:38:51 2010
From: adams at kolabsys.com (Paul James Adams)
Date: Fri, 19 Mar 2010 14:38:51 +0000
Subject: [Kolab-devel] New release : Kolab backend 0.3 for z-push
In-Reply-To: <4BA36097.7050005@libertech.fr>
References: <4BA12246.5070005@libertech.fr>
	<201003191054.52632.adams@kolabsys.com>
	<4BA36097.7050005@libertech.fr>
Message-ID: <201003191438.54893.adams@kolabsys.com>

On Friday 19 Mar 2010 11:31:35 Alain Abbas wrote:
> Paul James Adams a ?crit :
> > Does this combination of Z-Push 1.3 and backend 0.3 still support the
> > "debug.txt" file for logging errors?
> 
> yes like in the old version

My mistake; I forgot to set the permissions on the debug file.

-- 
Dr. Paul J. Adams
Chief Operating Officer

Kolab Systems AG
Zurich, Switzerland

e: adams at kolabsys.com
t: +447745 133 285
w: http://kolabsys.com

pgp: 899674F6 Paul James Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100319/0e354a64/attachment.bin

From issues at kolab.org  Fri Mar 19 22:11:18 2010
From: issues at kolab.org (Diego Woitasen)
Date: Fri, 19 Mar 2010 21:11:18 +0000
Subject: [Kolab-devel] [issue4232] Enable SASL support in OpenLDAP
In-Reply-To: <1269033078.87.0.892646963587.issue4232@kolab.org>
Message-ID: <1269033078.87.0.892646963587.issue4232@kolab.org>


New submission from Diego Woitasen <diegows at xtech.com.ar>:

OpenLDAP should have SASL support. It's useful for example if you want to
forward autentication against another LDAP servers.

I've attached a small patch with .spec changes.

----------
files: openldap.spec.patch
messages: 24321
nosy: diegows
priority: feature
status: unread
title: Enable SASL support in OpenLDAP

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4232>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openldap.spec.patch
Type: text/x-patch
Size: 598 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100319/a1b8bcb2/openldap.spec.bin

From issues at kolab.org  Sat Mar 20 01:39:26 2010
From: issues at kolab.org (Allen Winter)
Date: Sat, 20 Mar 2010 00:39:26 +0000
Subject: [Kolab-devel] [issue4233] Moving weekly recurring events fails in
	agenda views
In-Reply-To: <1269045566.9.0.731207808524.issue4233@kolab.org>
Message-ID: <1269045566.9.0.731207808524.issue4233@kolab.org>


New submission from Allen Winter <allen at kdab.net>:

tested with enterprise35 0.20100319.1105067

go into calendar, side-by-side or merged tab
create an event that recurs weekly
use the mouse to move the event to another day
at the prompt say to move all occurrences or all future occurrences
=> fail, the item moves back to its original place

----------
assignedto: sergio
keyword: enterprise35, kde client
messages: 24324
nosy: allen, sergio
priority: bug
status: unread
title: Moving weekly recurring events fails in agenda views

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


From issues at kolab.org  Mon Mar 22 09:47:25 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 22 Mar 2010 08:47:25 +0000
Subject: [Kolab-devel] [issue4234] SignEncryptEMailConflictDialog: doesn't
	pick OpenPGP when	only recipient holds only OpenPGP,
	but sender holds both OpenPGP and S/MIME certs
In-Reply-To: <1269247645.78.0.494652965401.issue4234@kolab.org>
Message-ID: <1269247645.78.0.494652965401.issue4234@kolab.org>


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

To reproduce:
1. Let A:=email address of user with just an (trusted) OpenPGP key.
   Let B:=email address of user with both a (trusted) OpenPGP and S/MIME cert,
          and both have secret key available.
2. exec gpg-connect-agent -S ~/.gnupg/S.uiserver --run <(cat <<BYE
sender --info -- $B
recipient $A
prep_encrypt --expect-sign
BYE
)
-> Dialog prompts to select protocol
Expected: Should pick OpenPGP, since A doesn't have S/MIME.

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24330
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: SignEncryptEMailConflictDialog: doesn't pick OpenPGP when only recipient holds only OpenPGP, but sender holds both OpenPGP and S/MIME certs

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


From issues at kolab.org  Mon Mar 22 09:51:59 2010
From: issues at kolab.org (Marc Mutz)
Date: Mon, 22 Mar 2010 08:51:59 +0000
Subject: [Kolab-devel] [issue4235] SignEncryptEMailConflictDialog: doesn't
	work with	sign-only
In-Reply-To: <1269247919.15.0.466650606344.issue4235@kolab.org>
Message-ID: <1269247919.15.0.466650606344.issue4235@kolab.org>


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

No other information given so far other than "doesn't work" :(

----------
assignedto: marc
keyword: gpg4win2, kleo
messages: 24331
nosy: bernhard, emanuel, marc, till
priority: urgent
status: unread
title: SignEncryptEMailConflictDialog: doesn't work with sign-only

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


From issues at kolab.org  Mon Mar 22 11:23:56 2010
From: issues at kolab.org (Gavin McCullagh)
Date: Mon, 22 Mar 2010 10:23:56 +0000
Subject: [Kolab-devel] [issue4236] Outlook cannot publish to Horde webdav
In-Reply-To: <1269253436.21.0.437177149983.issue4236@kolab.org>
Message-ID: <1269253436.21.0.437177149983.issue4236@kolab.org>


New submission from Gavin McCullagh <gavin.mccullagh at gcd.ie>:

Using Kolab v2.2.3 on Debian lenny.

Adding this rewrite rule to Apache:

RewriteRule rpc.php/kronolith/(.*?)/(.*?)_Calendar\.ics$
rpc.php/kronolith/$1/$1.ics [L]

seems like it should allow Outlook to connect to the kronolith WebDAV service. 
However, this doesn't appear to work.

client/horde.log has:

Mar 18 16:07:27 HORDE [notice] [imp] Login success for xxxxxxxxxxxxxxx at
yyyyyy.zz [172.16.17.41] to {server.tld:143 [imap/notls/novalidate-cert]} [pid
32226 on line 304 of "/kolab/var/kolab/www/client/imp/lib/Session.php"]
Mar 18 16:07:27 HORDE [debug] [kronolith] Hook _horde_hook_share_init in
application horde not called. [pid 32226 on line 1683 of
"/kolab/var/kolab/www/client/lib/Horde.php"]
Mar 18 16:07:27 HORDE [debug] [horde] Max memory usage: 20447232 bytes [pid
32226 on line 339 of "/kolab/var/kolab/www/client/lib/Horde/Registry.php"]
Mar 18 16:07:27 HORDE [debug] [horde] IMAP errors: SECURITY PROBLEM: insecure
server advertised AUTH=PLAIN [pid 32226 on line 175 of
"/kolab/var/kolab/www/client/imp/lib/IMAP.php"]

Apache's access.log has

172.16.17.41 - xxxxxxxxxxxxxxx at yyyyyy.zz [18/Mar/2010:15:50:41 +0000]
"PROPFIND /client/rpc.php/kronolith/xxxxxxxxxxxxxxx at yyyyyy.zz/ HTTP/1.1" 207 1031
172.16.17.41 - - [18/Mar/2010:15:50:44 +0000] "PUT
/client/rpc.php/kronolith/xxxxxxxxxxxxxxx at yyyyyy.zz/Name_Calendar.ics
HTTP/1.1" 400 354

The PROPFIND is apparently okay, but the following PUT request gives a 400 error.

A discussion about this is here:

http://kolab.org/pipermail/kolab-users/2010-March/thread.html#11113

----------
messages: 24336
nosy: gavinmc
priority: bug
status: unread
title: Outlook cannot publish to Horde webdav

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


From christoph.wickert at googlemail.com  Mon Mar 22 12:24:44 2010
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 22 Mar 2010 12:24:44 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
Message-ID: <1269257084.2837.16.camel@wicktop.localdomain>

I've noticed that the Kolab perl-* packages contain a lot of perl
modules each, some of them up to 70 modules. Are all these modules
really needed or did soneone just take the open-pkg packages because
they were already available?

Regards,
Christoph


From issues at kolab.org  Mon Mar 22 12:28:07 2010
From: issues at kolab.org (Thomas Arendsen Hein)
Date: Mon, 22 Mar 2010 11:28:07 +0000
Subject: [Kolab-devel] [issue4237] additional event.default folder created
	by kolabd	(rt#6038)
In-Reply-To: <1269257287.92.0.208577651303.issue4237@kolab.org>
Message-ID: <1269257287.92.0.208577651303.issue4237@kolab.org>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kolab Server 2.2.3, OpenPKG:

A group account already has a folder named "Kalender" with annotation
"event.default". During a migration from server 2.2.0 to 2.2.3 the uuid cache
was not transfered (which should be no problem).

kolabd tried to create the user mailbox and noticed that the mailbox is
already there, but additionally it created a new folder "Calender", also with
annotation "event.default", so now two folders marked "event.default" exist.

To simulate this, manually, use cyradm to create mailboxes:

cm user/foo at example.com
cm user/foo/Kalender at example.com
mboxcfg user/foo/Kalender at example.com /vendor/kolab/folder-type event.default
sam user/foo/Kalender at example.com calendar at example.com lrswipkxtecda

Now create group account foo at example.com in web admin, after this check
annotations with cyradm:

localhost> info  user/foo/Kalender at example.com
{user/foo/Kalender at example.com}:
  condstore: false
  duplicatedeliver: false
  lastpop:  
  lastupdate: 22-Mar-2010 12:21:05 +0100
  partition: default
  sharedseen: false
  size: 0
  folder-type: event.default
localhost> info user/foo/Calendar at example.com
{user/foo/Calendar at example.com}:
  condstore: false
  duplicatedeliver: false
  lastpop:  
  lastupdate: 22-Mar-2010 12:22:18 +0100
  partition: default
  sharedseen: false
  size: 0
  folder-type: event.default


Wrobel: Obviously to be fixed in HEAD, but estimation for kolab_2_2_branch would
be good, too.

----------
assignedto: wrobel
keyword: kkc, server
messages: 24346
nosy: martin, thomas, wilde, wrobel
priority: urgent
status: unread
title: additional event.default folder created by kolabd (rt#6038)

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


From issues at kolab.org  Mon Mar 22 12:38:44 2010
From: issues at kolab.org (Thomas Arendsen Hein)
Date: Mon, 22 Mar 2010 11:38:44 +0000
Subject: [Kolab-devel] [issue4238] Caches in /tmp are not deleted (rt#6039)
In-Reply-To: <1269257924.64.0.0430940868876.issue4238@kolab.org>
Message-ID: <1269257924.64.0.0430940868876.issue4238@kolab.org>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kolab Server 2.2.3 (OpenPKG):

When using the web client, /tmp will be cluttered with files like the
following, which are not deleted:

cache_0484082162416b7ca1f9238f524e267f
cache_04f558db4ccb640b9b26c753fffacdfc
horde_cache_gc
kolab_cache77dfcc40f18109ad8c1bf05ebe8678e9
kolab_cache832c91500d94766fbcafd24f29c4fb67

Is there a way to delete them by the web client or is using something like
'tmpreaper' the only way to get rid of them?

----------
assignedto: wrobel
keyword: kkc, web client
messages: 24348
nosy: martin, thomas, wilde, wrobel
status: unread
title: Caches in /tmp are not deleted (rt#6039)

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


From bernhard at intevation.de  Mon Mar 22 13:15:22 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Mar 2010 13:15:22 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003170904.36553.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
Message-ID: <201003221315.26054.bernhard@intevation.de>

Am Mittwoch, 17. M?rz 2010 09:04:35 schrieb Georg C. F. Greve:
> So we plan to introduce a
>
> ????????/vendor/kolab/activesync

While the protocol is activesync, 
I wonder if using a more generic name would be have an advantage.

> which defaults to YES, if not set

We possibly have to make this more complicated.
Note that anyone could just give you an ACL on a folder, so if the default 
is "yes", this means I can just spam your appointments by giving you a folder 
that immedeately gets synced. So a default of NO seems to be the better 
solution. Or something like YES for folders where in my personal namespace
and NO for all others.

> , and which is a string of the format 
>
> ? ? ? ? ? ? ? ? <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
>
> ? ? ? ? with <BOOL> = 1 or 0 (for yes or no)
> ? ? ? ? and <SERIAL NO> = serial number of the phone
> to allow a per-device setting of synchronisation preferences

Is the serial number unique?
If I think about having two or more devices, is there a way to make that a 
client configuration option?

Arg, this brings me back to the much debated question of where should client 
configuration go so. We never had a good conclusion on this one as far as I 
remember.

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100322/50d02127/attachment.bin

From greve at kolabsys.com  Mon Mar 22 13:34:43 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Mon, 22 Mar 2010 13:34:43 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221315.26054.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221315.26054.bernhard@intevation.de>
Message-ID: <201003221334.43724.greve@kolabsys.com>

On Monday 22 March 2010 13:15:22 Bernhard Reiter wrote:
> While the protocol is activesync, I wonder if using a more generic name
> would be have an advantage.

Other protocols would likely want to store different metadata, or at least in 
different format. Since we would then be in a namespace conflict, this seemed 
like the right abstraction level.


> We possibly have to make this more complicated.
> Note that anyone could just give you an ACL on a folder, so if the default
> is "yes", this means I can just spam your appointments by giving you a
>  folder that immedeately gets synced. So a default of NO seems to be the
>  better solution. Or something like YES for folders where in my personal
>  namespace and NO for all others.

Agreed.


> Is the serial number unique?

AFAWK, Yes.


> If I think about having two or more devices, is there a way to make that a
> client configuration option?

The current configuration layout allows to have as many devices as you want, 
and individually set your synchronisation preferences for each of them.


> Arg, this brings me back to the much debated question of where should
>  client configuration go so. We never had a good conclusion on this one as
>  far as I remember.

There are two places where this information can logically go: LDAP & IMAP.

LDAP has been excluded for a wide variety of reasons which Thomas and Sascha 
can highlight again if you feel the need to go through the motions one more 
time. That is why the conclusion has been to put this into a private extended 
annotation.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100322/c7a98d4a/attachment.bin

From wrobel at pardus.de  Mon Mar 22 13:40:37 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Mar 2010 13:40:37 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <1269257084.2837.16.camel@wicktop.localdomain>
References: <1269257084.2837.16.camel@wicktop.localdomain>
Message-ID: <20100322134037.66582hhn6bjk86yo@webmail.pardus.de>

Hi Christoph,

Quoting Christoph Wickert <christoph.wickert at googlemail.com>:

> I've noticed that the Kolab perl-* packages contain a lot of perl
> modules each, some of them up to 70 modules. Are all these modules
> really needed or did soneone just take the open-pkg packages because
> they were already available?

No, I'm certain not all of them are needed. We stick as much as  
possible to the upstream packages. So yes, we use them because they  
are available in that form.

Cheers,

Gunnar

>
> Regards,
> Christoph
>
> _______________________________________________
> 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 Mar 22 14:28:20 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Mar 2010 14:28:20 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and	a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221334.43724.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221315.26054.bernhard@intevation.de>
	<201003221334.43724.greve@kolabsys.com>
Message-ID: <20100322142820.1882140rj271yp34@webmail.pardus.de>

Quoting "Georg C. F. Greve" <greve at kolabsys.com>:

> On Monday 22 March 2010 13:15:22 Bernhard Reiter wrote:
>> While the protocol is activesync, I wonder if using a more generic name
>> would be have an advantage.
>
> Other protocols would likely want to store different metadata, or at least in
> different format. Since we would then be in a namespace conflict, this seemed
> like the right abstraction level.
>
>
>> We possibly have to make this more complicated.
>> Note that anyone could just give you an ACL on a folder, so if the default
>> is "yes", this means I can just spam your appointments by giving you a
>>  folder that immedeately gets synced. So a default of NO seems to be the
>>  better solution. Or something like YES for folders where in my personal
>>  namespace and NO for all others.
>
> Agreed.
>
>
>> Is the serial number unique?
>
> AFAWK, Yes.
>
>
>> If I think about having two or more devices, is there a way to make that a
>> client configuration option?
>
> The current configuration layout allows to have as many devices as you want,
> and individually set your synchronisation preferences for each of them.
>
>
>> Arg, this brings me back to the much debated question of where should
>>  client configuration go so. We never had a good conclusion on this one as
>>  far as I remember.
>
> There are two places where this information can logically go: LDAP & IMAP.

Correct.

>
> LDAP has been excluded for a wide variety of reasons which Thomas and Sascha
> can highlight again if you feel the need to go through the motions one more
> time.

+1


> That is why the conclusion has been to put this into a private extended
> annotation.

Concerning IMAP the annotations are of course not the only storage  
space available. I would consider the folder contents to be a much  
more appropriate storage space.

For small configuration values as you describe them the approach may  
work. So I'm not saying we shouldn't use this approach for Z-Push now.  
It might be difficult to find a common ground concerning the  
configuration format in time for the desired delivery date for a  
working Z-Push solution on the Kolab server.

The main problem I see with using annotations is the fact that they  
are not meant to be used as a generic data storage element. The have a  
fixed string length. So once you start storing data such as

<BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]

this hits a limit at some point. Concerning ActiveSync this might play  
no role as you can probably still store hundreds of devices in the  
annotation.

But from the purist point of view I would say it smells :)

As we are adding the second annotation of this type now I feel we  
should indeed tackle the configuration topic again in the near future.

Cheers,

Gunnar

>
> Best regards,
> Georg
>
> --
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
>



-- 
______ 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/20100322/172044e7/attachment-0001.bin

From kanarip at kanarip.com  Mon Mar 22 15:24:29 2010
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Mon, 22 Mar 2010 15:24:29 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <1269257084.2837.16.camel@wicktop.localdomain>
References: <1269257084.2837.16.camel@wicktop.localdomain>
Message-ID: <f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>



"Christoph Wickert" <christoph.wickert at googlemail.com> wrote:

>I've noticed that the Kolab perl-* packages contain a lot of perl
>modules each, some of them up to 70 modules. Are all these modules
>really needed or did soneone just take the open-pkg packages because
>they were already available?
>

As a side-note question; are Christoph and I going to have to make available cross-distro all the packages included in the OpenPKG version of Kolab packages, and if so, is that:

- because of OpenPKG, or
- because they are all dependencies of Kolab?

For more details on the background of this question, please see http://wiki.kolab.org/index.php/User:Kanarip/Package_Dependencies

Kind regards,

-- Jeroen

From wrobel at pardus.de  Mon Mar 22 15:58:06 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 22 Mar 2010 15:58:06 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
References: <1269257084.2837.16.camel@wicktop.localdomain>
	<f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
Message-ID: <20100322155806.13055xpchvqxzpoo@webmail.pardus.de>

Quoting Jeroen van Meeuwen <kanarip at kanarip.com>:

>
>
> "Christoph Wickert" <christoph.wickert at googlemail.com> wrote:
>
>> I've noticed that the Kolab perl-* packages contain a lot of perl
>> modules each, some of them up to 70 modules. Are all these modules
>> really needed or did soneone just take the open-pkg packages because
>> they were already available?
>>
>
> As a side-note question; are Christoph and I going to have to make  
> available cross-distro all the packages included in the OpenPKG  
> version of Kolab packages, and if so, is that:
>
> - because of OpenPKG, or
> - because they are all dependencies of Kolab?
>
> For more details on the background of this question, please see  
> http://wiki.kolab.org/index.php/User:Kanarip/Package_Dependencies

Your goal is to get the Kolab server running on Fedora, right? I don't  
see any reason why you would need to look at any packages far down in  
the dependency hierarchy when transferring from OpenPKG to Fedora.  
Each distro has it's own packaging concepts and not all of them match.  
So some packages will be present in some distros and will not make  
much sense in others.

In order to get a native install of the Kolab server you only need to  
identify the top level components that make a kolab server a kolab  
server and ensure that you get the dependencies of these components  
right.

Taking the perl-packages as an example: I don't think it is necessary  
to analyze the OpenPKG perl packages in detail. The Kolab server has  
only one perl-package that is important: perl-kolab. Once you know  
it's dependencies you should be fine. At least as long as your chosen  
distro supports all of the required dependencies. Otherwise you need  
to fill the missing gaps. But assuming all dependencies are available  
you should be fine to allow your distros packaging system to handle  
the dependencies down to the bottom.

Does that answer your question or did I somehow misunderstand it?

Cheers,

Gunnar

>
> Kind regards,
>
> -- Jeroen



-- 
______ 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/20100322/16d0d64c/attachment.bin

From greve at kolabsys.com  Mon Mar 22 16:32:29 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Mon, 22 Mar 2010 16:32:29 +0100
Subject: [Kolab-devel]
 =?iso-8859-2?q?Completing_ActiveSync_integration_in?=
 =?iso-8859-2?q?_Kolab=2C_and=09a_request_for_input_on_IMAP_annotatemore_e?=
 =?iso-8859-2?q?xtensions?=
In-Reply-To: <20100322142820.1882140rj271yp34@webmail.pardus.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221334.43724.greve@kolabsys.com>
	<20100322142820.1882140rj271yp34@webmail.pardus.de>
Message-ID: <201003221632.30170.greve@kolabsys.com>

On Monday 22 March 2010 14:28:20 Gunnar Wrobel wrote:
> > That is why the conclusion has been to put this into a private extended
> > annotation.

> Concerning IMAP the annotations are of course not the only storage
> space available. I would consider the folder contents to be a much
> more appropriate storage space.

Ah, yes.

Configuration management & storage in Kolab for third party integration.

I very much agree this would be worthwhile to have, although this will 
certainly require a little bit more thought & work than we have available 
under this project - at least if we want to produce tangible results in time.

 
> The main problem I see with using annotations is the fact that they
> are not meant to be used as a generic data storage element. The have a
> fixed string length. So once you start storing data such as
> 
> <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
> 
> this hits a limit at some point. Concerning ActiveSync this might play
> no role as you can probably still store hundreds of devices in the
> annotation.

Yes, that was also our thinking.

Since every user can store hundreds of devices this way, we felt safe enough 
for the moment, although I am fully aware of the curse that is on all such 
assumptions in our industry ("nobody will ever need more than 640k of RAM").


> But from the purist point of view I would say it smells :)

I think it's not perfect, but substantially better than the alternative.


> As we are adding the second annotation of this type now I feel we
> should indeed tackle the configuration topic again in the near future.

Agreed. We might want to start collecting thoughts on this soon.

For the moment however we should think about how to make the extended 
annotation storage work reliably as expected. Help for this would be most 
appreciated.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100322/61a2b48a/attachment.bin

From math.parent at gmail.com  Mon Mar 22 17:06:44 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Mon, 22 Mar 2010 17:06:44 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <20100322155806.13055xpchvqxzpoo@webmail.pardus.de>
References: <1269257084.2837.16.camel@wicktop.localdomain>
	<f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
	<20100322155806.13055xpchvqxzpoo@webmail.pardus.de>
Message-ID: <960738411003220906t2d4e2530qae9b29a4a451608e@mail.gmail.com>

Hello,


On Mon, Mar 22, 2010 at 3:58 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Quoting Jeroen van Meeuwen <kanarip at kanarip.com>:
>
>>
>>
>> "Christoph Wickert" <christoph.wickert at googlemail.com> wrote:
>>
>>> I've noticed that the Kolab perl-* packages contain a lot of perl
>>> modules each, some of them up to 70 modules. Are all these modules
>>> really needed or did soneone just take the open-pkg packages because
>>> they were already available?
>>>

You can take a look at the current debian dependencies,
<http://packages.debian.org/sid/kolabd>.

Currently the Kolab deb team only maintains 7 packages:
- 5 server packages (kolab-webadmin, kolabd, libkolab-perl,
php-kolab-filter, php-kolab-freebusy),
- one dependency package (kolab-cyrus-imapd, which is cyrus-imap with
some patches ; postfix patches are already upstream),
- one web client package (kolab-webclient, currently experimental).
- (there is also the unmaintained kolabadmin, you can ignore).

There are strong dependencies on perl packages and Horde packages (for
php-kolab-* and for kolab-webclient), but none of those dependencies
are patched for kolab (except kolab-cyrus-imapd).

I you want a complete kolab web client, you will probably need to
patch the horde packages also, but it works without.


Mathieu Parent


From bernhard at intevation.de  Mon Mar 22 17:37:42 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Mar 2010 17:37:42 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221334.43724.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221315.26054.bernhard@intevation.de>
	<201003221334.43724.greve@kolabsys.com>
Message-ID: <201003221737.42990.bernhard@intevation.de>

Am Montag, 22. M?rz 2010 13:34:43 schrieb Georg C. F. Greve:
> On Monday 22 March 2010 13:15:22 Bernhard Reiter wrote:
> > While the protocol is activesync, I wonder if using a more generic name
> > would be have an advantage.
>
> Other protocols would likely want to store different metadata, or at least
> in different format. Since we would then be in a namespace conflict, this
> seemed like the right abstraction level.

Currently you are looking at creating an annotation to indicate
which folder is relevant for mobile sync for which device.
Given that serial number just is a unique number, this looks universal to me.

Note that clients would also need to support reading and setting this 
annotation. Overall I think we should also bring this discussion to 
kolab-format at .

Just out of curiosity: Where is the status of the sync saved in the z-push 
backend? Usually there will be a place for this in the connector itself.
I am asking because I think that should be a full cache, so if thrown 
completely away, the system should be self healing.

Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100322/62b0104b/attachment.bin

From bernhard at intevation.de  Mon Mar 22 17:43:56 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 22 Mar 2010 17:43:56 +0100
Subject: [Kolab-devel]
	=?utf-8?q?Completing_ActiveSync_integration_in_Kola?=
	=?utf-8?q?b=2C_and=09a_request_for_input_on_IMAP_annotatemore_exte?=
	=?utf-8?q?nsions?=
In-Reply-To: <201003221632.30170.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<20100322142820.1882140rj271yp34@webmail.pardus.de>
	<201003221632.30170.greve@kolabsys.com>
Message-ID: <201003221743.56547.bernhard@intevation.de>

Am Montag, 22. M?rz 2010 16:32:29 schrieb Georg C. F. Greve:
> On Monday 22 March 2010 14:28:20 Gunnar Wrobel wrote:
> > > That is why the conclusion has been to put this into a private extended
> > > annotation.
> >
> > Concerning IMAP the annotations are of course not the only storage
> > space available. I would consider the folder contents to be a much
> > more appropriate storage space.
>
> Ah, yes.
>
> Configuration management & storage in Kolab for third party integration.

This has been a long debate for a while, because there are not a lot IMAP 
servers out there that implement annotations in full bloom. So if you just 
have an imap server, it is harder to use as Kolab Calender folder.
Using a special object would change that.

Also the question is: One person has several clients (all Kolab clients)
and would want to keep parts of the configuration for some of them and some 
for all of them. How should Kolab model that in the future.
Doing special objects in the folder would be one way, but this does not solve 
all problems. Especially it is not clear where the configuration for 
clients * folder shall go to.
The Cyrus people experimented with a few more protocols in addition to IMAP,
but gave up on that. 

> > As we are adding the second annotation of this type now I feel we
> > should indeed tackle the configuration topic again in the near future.

I think we either have more annotations like this or it is the first.
So which one are you thinking about?

> Agreed. We might want to start collecting thoughts on this soon.
>
> For the moment however we should think about how to make the extended
> annotation storage work reliably as expected. Help for this would be most
> appreciated.

Given the change of implementations on the server side we probably need to 
evaluate what we want to do on the client side. Another topic for 
kolab-format@ IMO.

Bernhard



-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100322/3d379612/attachment-0001.bin

From greve at kolabsys.com  Mon Mar 22 18:21:31 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Mon, 22 Mar 2010 18:21:31 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221737.42990.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221334.43724.greve@kolabsys.com>
	<201003221737.42990.bernhard@intevation.de>
Message-ID: <201003221821.31864.greve@kolabsys.com>

On Monday 22 March 2010 17:37:42 Bernhard Reiter wrote:
> Given that serial number just is a unique number, this looks universal to
>  me.

Ah, but this is an ActiveSync based serial number, from what I understood, 
generated on the client through some weird magic.

So in the end the number will be ActiveSync specific, and we cannot safely 
exclude namespace conflicts with other synchronisation schemes, e.g. one 
ActiveSync phone having the same serial id as another phone with Cool2012Sync 
while the user would want them to behave separately.

As we are unlikely to end up with more than 10 supported synchronisation 
schemes (which would mean 10 annotations), the overhead seems manageable, and 
keeping it focused seems sensible.


> Just out of curiosity: Where is the status of the sync saved in the z-push
> backend? 

You mean the state & mapping of the objects? In database files in a specific 
directory on the hard disk right now, one file per user, IIRC.


> I am asking because I think that should be a full cache, so if thrown
> completely away, the system should be self healing.

I am not sure what you mean by "system" and what is your scenario for "thrown 
completely away" in the above.

For synchronisation the answers to the above would be largely dependent upon 
the ActiveSync standard and the way it is implemented on the device. 

Ultimately my experience is that attempts to self-heal are easy paths for 
eternally replicating information, potentially tearing down your Kontact 
client with thousands and thousands of duplicate entries.

Yes. I had this with the Funmabol connector once. It is not fun.

Sometimes dumber is smarter. ;)

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100322/7e7a7043/attachment.bin

From greve at kolabsys.com  Mon Mar 22 18:22:49 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Mon, 22 Mar 2010 18:22:49 +0100
Subject: [Kolab-devel]
 =?iso-8859-2?q?Completing_ActiveSync_integration_in?=
 =?iso-8859-2?q?_Kolab=2C_and=09a_request_for_input_on_IMAP_annotatemore_e?=
 =?iso-8859-2?q?xtensions?=
In-Reply-To: <201003221743.56547.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221632.30170.greve@kolabsys.com>
	<201003221743.56547.bernhard@intevation.de>
Message-ID: <201003221822.50347.greve@kolabsys.com>

On Monday 22 March 2010 17:43:56 Bernhard Reiter wrote:
> This has been a long debate for a while, because there are not a lot IMAP
> servers out there that implement annotations in full bloom. So if you just
> have an imap server, it is harder to use as Kolab Calender folder.
> Using a special object would change that.

Uh, this seems yet another discussion, and not one we would resolve in two 
days, so I suggest we stick with the established path forward for the moment.

If we think about changing the Kolab concept so fundamentally, it would affect 
all clients anyhow.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100322/4a88a00d/attachment.bin

From alain.abbas at libertech.fr  Mon Mar 22 18:54:36 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Mon, 22 Mar 2010 18:54:36 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221737.42990.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221315.26054.bernhard@intevation.de>
	<201003221334.43724.greve@kolabsys.com>
	<201003221737.42990.bernhard@intevation.de>
Message-ID: <B610F5ED-3CD5-4BE6-BD27-2CC4336026BF@libertech.fr>





Le 22 mars 2010 ? 17:37, Bernhard Reiter <bernhard at intevation.de> a  
?crit :

> Am Montag, 22. M?rz 2010 13:34:43 schrieb Georg C. F. Greve:
>> On Monday 22 March 2010 13:15:22 Bernhard Reiter wrote:
>>> While the protocol is activesync, I wonder if using a more generic  
>>> name
>>> would be have an advantage.
>>
>> Other protocols would likely want to store different metadata, or  
>> at least
>> in different format. Since we would then be in a namespace  
>> conflict, this
>> seemed like the right abstraction level.
>
> Currently you are looking at creating an annotation to indicate
> which folder is relevant for mobile sync for which device.
> Given that serial number just is a unique number, this looks  
> universal to me.
>
> Note that clients would also need to support reading and setting this
> annotation. Overall I think we should also bring this discussion to
> kolab-format at .
>
> Just out of curiosity: Where is the status of the sync saved in the  
> z-push
> backend? Usually there will be a place for this in the connector  
> itself.
> I am asking because I think that should be a full cache, so if thrown
> completely away, the system should be self healing.
>
> Bernhard
>
>
the state of the sync is saved by zpush  in the state folder
i use kolabindex to retrieve imapid and folder from kolab uid aand i  
store too some informations like annotation to for having good  
performance

regards
alain
> -- 
> Managing Director - Owner: www.intevation.net       (Free Software  
> Company)
> Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagn 
> er
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alain.abbas at libertech.fr  Mon Mar 22 19:03:22 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Mon, 22 Mar 2010 19:03:22 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221821.31864.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221334.43724.greve@kolabsys.com>
	<201003221737.42990.bernhard@intevation.de>
	<201003221821.31864.greve@kolabsys.com>
Message-ID: <A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>





Le 22 mars 2010 ? 18:21, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Monday 22 March 2010 17:37:42 Bernhard Reiter wrote:
>> Given that serial number just is a unique number, this looks  
>> universal to
>> me.
>
> Ah, but this is an ActiveSync based serial number, from what I  
> understood,
> generated on the client through some weird magic.
>
this is the serial number of the phone ( hardwired) it is inique
> So in the end the number will be ActiveSync specific, and we cannot  
> safely
> exclude namespace conflicts with other synchronisation schemes, e.g.  
> one
> ActiveSync phone having the same serial id as another phone with  
> Cool2012Sync
> while the user would want them to behave separately.
>
i think its not possible it is hard like the mac address
there are another unique id that is generated to the activesync state
but it change at each reset of the synchronisation
> As we are unlikely to end up with more than 10 supported  
> synchronisation
> schemes (which would mean 10 annotations), the overhead seems  
> manageable, and
> keeping it focused seems sensible.
>
>
>> Just out of curiosity: Where is the status of the sync saved in the  
>> z-push
>> backend?
>
> You mean the state & mapping of the objects? In database files in a  
> specific
> directory on the hard disk right now, one file per user, IIRC.
>
>
>> I am asking because I think that should be a full cache, so if thrown
>> completely away, the system should be self healing.
>
> I am not sure what you mean by "system" and what is your scenario  
> for "thrown
> completely away" in the above.
>
> For synchronisation the answers to the above would be largely  
> dependent upon
> the ActiveSync standard and the way it is implemented on the device.
>
> Ultimately my experience is that attempts to self-heal are easy  
> paths for
> eternally replicating information, potentially tearing down your  
> Kontact
> client with thousands and thousands of duplicate entries.
>
> Yes. I had this with the Funmabol connector once. It is not fun.
>
> Sometimes dumber is smarter. ;)
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From ml at radoeka.nl  Mon Mar 22 20:34:21 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 22 Mar 2010 20:34:21 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
References: <1269257084.2837.16.camel@wicktop.localdomain>
	<f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
Message-ID: <201003222034.22456.ml@radoeka.nl>

Hello Jeroen,

Op maandag 22 maart 2010 15:24:29 schreef Jeroen van Meeuwen:
> As a side-note question; are Christoph and I going to have to make
>  available cross-distro all the packages included in the OpenPKG version of
>  Kolab packages, and if so, is that:
> 
> - because of OpenPKG, or
> - because they are all dependencies of Kolab?

Would your build effort result in a repository similar to this one:
http://download.opensuse.org/repositories/home:/rbos:/ib/
Or do you mean something different with "cross-distro all the packages"?

-- 
Richard


From ml at radoeka.nl  Mon Mar 22 20:34:23 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 22 Mar 2010 20:34:23 +0100
Subject: [Kolab-devel] Do we need all these perl modules?
In-Reply-To: <20100322155806.13055xpchvqxzpoo@webmail.pardus.de>
References: <1269257084.2837.16.camel@wicktop.localdomain>
	<f6d58ede-4a19-4c53-a2a8-2be40072fa28@email.android.com>
	<20100322155806.13055xpchvqxzpoo@webmail.pardus.de>
Message-ID: <201003222034.23806.ml@radoeka.nl>

Op maandag 22 maart 2010 15:58:06 schreef Gunnar Wrobel:
>   Quoting Jeroen van Meeuwen <kanarip at kanarip.com>:
> > "Christoph Wickert" <christoph.wickert at googlemail.com> wrote:
> >> I've noticed that the Kolab perl-* packages contain a lot of perl
> >> modules each, some of them up to 70 modules. Are all these modules
> >> really needed or did soneone just take the open-pkg packages because
> >> they were already available?
> >
> > As a side-note question; are Christoph and I going to have to make  
> > available cross-distro all the packages included in the OpenPKG  
> > version of Kolab packages, and if so, is that:
> >
> > - because of OpenPKG, or
> > - because they are all dependencies of Kolab?
> >
> > For more details on the background of this question, please see  
> > http://wiki.kolab.org/index.php/User:Kanarip/Package_Dependencies
> 
> Your goal is to get the Kolab server running on Fedora, right? I don't  
> see any reason why you would need to look at any packages far down in  
> the dependency hierarchy when transferring from OpenPKG to Fedora.  
> Each distro has it's own packaging concepts and not all of them match.  
> So some packages will be present in some distros and will not make  
> much sense in others.
> 
> In order to get a native install of the Kolab server you only need to  
> identify the top level components that make a kolab server a kolab  
> server and ensure that you get the dependencies of these components  
> right.

Let's not forget to get the dist_conf file correct.  That's the spil to get 
packages natively running on a distribution.


-- 
Richard


From soliva at comcept.ch  Mon Mar 22 23:43:15 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Mon, 22 Mar 2010 23:43:15 +0100
Subject: [Kolab-devel] Strange behavior with ICal snychronisation Kolab 2.2.3
Message-ID: <000101caca11$0fe48610$2fad9230$@ch>

Hi all

Following feedback from a test which I did with a MAC and ICal functionality
using Kolab 2.2.3. I configured a ICal Kalender with the name of the user
account and with the URL:

https://[host}/client/rpc.php/kronolith/[Kolab User ID]

After the configuration I announced the configured Calender within ICal to
the Kolab server and each entry of the calender was "put" to the related
account on the Kolab server. After successful "announcement" we checked over
Horde if all events was put correct to the users account and we can confirm
this. In the first view everything was looking perfect. After more tests we
noticed following:

- Within every announcement or/and actualization of the related Calender
within ICal the request is deleting EVERY Calender entry and "put's" every
entry again to the Kolab server (no synch only a "delete all" as afterwards
a "put again all"). Why is the stuff not synched and instead every time
deleted and from scratch "put" again to the server?

- Another issue we recognized is, if the users launches within ICal the
announcement and if you have more as - lets say 50 entry - ICal will give
back an Error telling that the announcement was not successfull but in the
background all data is "put" correctly (except that everything is again
first of all "deleted" and afterwards from scratch again "put" to the Kolab
server). It seems that ICal goes in a timeout and and Kolab works straight
ahead in the background?

- I looked to the flat files on the Kolab Server and the format I see there
is similar to a Mail entry (Imap entry) meaning the stuff is in kolab.xml
format and everything seems to be fine as it must be.

- Is this something which is supported or did I try something which is not
visible on was not planed?

The main issue here is really that everytime a calender entry changes or
whatever that the process will delete EVERYTHING within the Calender on the
Kolab server and put afterwards again EVERYTHING on the server. From
performance etc. reasons this is ugly and not really that what should be
or.....?

- Within Snow Leopard 10.6 -if I'm correctly informed - Apple remove the
WebDAV functionality within ICal (they want that .MAC is used to earn $). I
know there is a hack to be again able to use WebDAV but if I'm correct Kolab
does not support WebDAV in this way that the stuff is afterwards available
within Horde etc. correct?

Sorry many questions but at the moment I'm a little bit confiused and not
understanding the behavior specially because from scratch it would work if
this case with DELETE all first and afterwards put again all on the server
wouldn't be. Can you please give me quick a feedback if I did something
false or did understand something false? Wihtin the logs I did not noticed
something special.

Kind regards

Andrea Soliva

Mail: soliva at comcept.ch 


From greve at kolabsys.com  Tue Mar 23 09:09:06 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Tue, 23 Mar 2010 09:09:06 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221821.31864.greve@kolabsys.com>
	<A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>
Message-ID: <201003230909.06991.greve@kolabsys.com>

On Monday 22 March 2010 19:03:22 Alain Abbas wrote:
> this is the serial number of the phone ( hardwired) it is inique

Thanks for the clarification, this is good to know.

But I still believe it makes a lot of sense to define the extended IMAP 
attribute phone specific, because in my experience it is possible that users 
would want to define two different paths of synchronisation for different 
information on their phone.

That way they can synchronise Contacts through ActiveSync and Calendar through 
SuperSync2012, because there are two clients on their "futurephone" that are 
both broken in different ways that we could not anticipate.


> i think its not possible it is hard like the mac address

Indeed. There may be future synchronisation schemes that use a different source 
number for their identification towards the server, and we cannot exlude a 
potential overlap of these namespaces.

Hence so far I'm still in favor of

	/vendor/kolab/activesync

as the name for the extended IMAP annotation, which could be re-used in case 
someone else (Horde?) came up with another activesync implementation, but 
won't taint the namespaces for other potential syncronisation protocols.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100323/87ab5bcc/attachment.bin

From wrobel at pardus.de  Tue Mar 23 09:53:33 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 23 Mar 2010 09:53:33 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and	a request for input on IMAP annotatemore extensions
In-Reply-To: <201003221743.56547.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<20100322142820.1882140rj271yp34@webmail.pardus.de>
	<201003221632.30170.greve@kolabsys.com>
	<201003221743.56547.bernhard@intevation.de>
Message-ID: <20100323095333.45130anc8qh59yts@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Am Montag, 22. M?rz 2010 16:32:29 schrieb Georg C. F. Greve:
>> On Monday 22 March 2010 14:28:20 Gunnar Wrobel wrote:
>> > > That is why the conclusion has been to put this into a private extended
>> > > annotation.
>> >
>> > Concerning IMAP the annotations are of course not the only storage
>> > space available. I would consider the folder contents to be a much
>> > more appropriate storage space.
>>
>> Ah, yes.
>>
>> Configuration management & storage in Kolab for third party integration.
>
> This has been a long debate for a while, because there are not a lot IMAP
> servers out there that implement annotations in full bloom. So if you just
> have an imap server, it is harder to use as Kolab Calender folder.
> Using a special object would change that.
>
> Also the question is: One person has several clients (all Kolab clients)
> and would want to keep parts of the configuration for some of them and some
> for all of them. How should Kolab model that in the future.
> Doing special objects in the folder would be one way, but this does not solve
> all problems. Especially it is not clear where the configuration for
> clients * folder shall go to.
> The Cyrus people experimented with a few more protocols in addition to IMAP,
> but gave up on that.
>
>> > As we are adding the second annotation of this type now I feel we
>> > should indeed tackle the configuration topic again in the near future.
>
> I think we either have more annotations like this or it is the first.
> So which one are you thinking about?

We also store a potentially unlimited list of elements in the  
pxfb-readable-for annotation. We discussed the very same problem when  
we implemented the xfb concept as I had the same concerns then.

Cheers,

Gunnar

>
>> Agreed. We might want to start collecting thoughts on this soon.
>>
>> For the moment however we should think about how to make the extended
>> annotation storage work reliably as expected. Help for this would be most
>> appreciated.
>
> Given the change of implementations on the server side we probably need to
> evaluate what we want to do on the client side. Another topic for
> kolab-format@ IMO.
>
> Bernhard
>
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100323/401920a7/attachment.bin

From issues at kolab.org  Tue Mar 23 10:59:54 2010
From: issues at kolab.org (Marc Mutz)
Date: Tue, 23 Mar 2010 09:59:54 +0000
Subject: [Kolab-devel] [issue4239] GpgOL should always send SENDER with
	actual sender email.
In-Reply-To: <1269338394.0.0.99741940737.issue4239@kolab.org>
Message-ID: <1269338394.0.0.99741940737.issue4239@kolab.org>


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

GpgOL sometimes sends
> SENDER -- <kleopatra-does-not-allow-empty-sender at example.net>

This is GpgOL's attempt to access the "default signer" functionality of the 
UiServer protocol spec. However, that functionality has never been and will 
never be implemented in Kleopatra, because it's impossible to do so, since 
Kleopatra doesn't have access to the Identity information stored in OL. 
Therefore, GpgOL _always_ needs to send this information to Kleopatra, 
irregardless of whether the mail is sent via the default account or a secondary 
one.

----------
assignedto: werner
keyword: gnupg, gpg4win2, gpgol
messages: 24376
nosy: bernhard, emanuel, marc, till, werner
status: unread
title: GpgOL should always send SENDER with actual sender email.

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


From alain.abbas at libertech.fr  Tue Mar 23 11:08:47 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Tue, 23 Mar 2010 11:08:47 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003230909.06991.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221821.31864.greve@kolabsys.com>
	<A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>
	<201003230909.06991.greve@kolabsys.com>
Message-ID: <9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>

hi all
im working on the "flat mode " for device who doesnt support others  
calendars an contacts than the default one
i need a supplementary setting
1) a variables who tell if the device is in folder mode or flat mode
2) we could have a global setting by device type in the config file


where to store the by device setting?

another question:
is cyrus is ready to store our annotations or it needs patchs ?




Le 23 mars 2010 ? 09:09, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Monday 22 March 2010 19:03:22 Alain Abbas wrote:
>> this is the serial number of the phone ( hardwired) it is inique
>
> Thanks for the clarification, this is good to know.
>
> But I still believe it makes a lot of sense to define the extended  
> IMAP
> attribute phone specific, because in my experience it is possible  
> that users
> would want to define two different paths of synchronisation for  
> different
> information on their phone.
>
> That way they can synchronise Contacts through ActiveSync and  
> Calendar through
> SuperSync2012, because there are two clients on their "futurephone"  
> that are
> both broken in different ways that we could not anticipate.
>
>
>> i think its not possible it is hard like the mac address
>
> Indeed. There may be future synchronisation schemes that use a  
> different source
> number for their identification towards the server, and we cannot  
> exlude a
> potential overlap of these namespaces.
>
> Hence so far I'm still in favor of
>
>    /vendor/kolab/activesync
>
> as the name for the extended IMAP annotation, which could be re-used  
> in case
> someone else (Horde?) came up with another activesync  
> implementation, but
> won't taint the namespaces for other potential syncronisation  
> protocols.
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From greve at kolabsys.com  Tue Mar 23 11:19:53 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Tue, 23 Mar 2010 11:19:53 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003230909.06991.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
Message-ID: <201003231119.54201.greve@kolabsys.com>

On Tuesday 23 March 2010 11:08:47 Alain Abbas wrote:
> 1) a variables who tell if the device is in folder mode or flat mode
> 2) we could have a global setting by device type in the config file
> where to store the by device setting?

In order to avoid introducing too many flags, we could put this  into the same 
variable by making the binary "yes/no" synchronisation a bit mask.

In result, it would look like this:

        /vendor/kolab/activesync

defaults to a value of 1, if not set, or will be parsed as a string of the 
format:

                <BITMAP>[;<SERIAL NO>:<BITMAP>[;<SERIAL NO>:<BITMAP>[...]]]

        with <SERIAL NO> = serial number of the phone
        and <BITMAP> =
           bit 0: synchronise: <yes|no>
           bit 1: fold into flat hierarchy: <yes|no>
           bit 2: make this the target for new items from the phone: <yes|no>

where sanity checking of bit 2 would be the responsibility of the 
administrative interface, you would simply look for the first folder you find 
with this flag set and put new items of that category into them.

This should allow for any possible use case anyone might ever want, I think.


> is cyrus is ready to store our annotations or it needs patchs ?

That is the big question, and the one that was really the one posed to the 
list in the initial email - unfortunately we got sidetracked.

We know it should, and I believe Bernhard Herzog has pointed out how it is 
supposed to work with the current cyrus, but we still need to define that 
annotation and then test whether it works as well in practice as theory 
suggests.

Any help on that would be greatly appreciated!

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100323/cd95b2b7/attachment.bin

From alain.abbas at libertech.fr  Tue Mar 23 11:26:12 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Tue, 23 Mar 2010 11:26:12 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003231119.54201.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003230909.06991.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
	<201003231119.54201.greve@kolabsys.com>
Message-ID: <2495D9C4-D00D-4F4E-AFD4-3B47354125A0@libertech.fr>





Le 23 mars 2010 ? 11:19, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Tuesday 23 March 2010 11:08:47 Alain Abbas wrote:
>> 1) a variables who tell if the device is in folder mode or flat mode
>> 2) we could have a global setting by device type in the config file
>> where to store the by device setting?
>
> In order to avoid introducing too many flags, we could put this   
> into the same
> variable by making the binary "yes/no" synchronisation a bit mask.
>
> In result, it would look like this:
>
>        /vendor/kolab/activesync
>
> defaults to a value of 1, if not set, or will be parsed as a string  
> of the
> format:
>
>                <BITMAP>[;<SERIAL NO>:<BITMAP>[;<SERIAL NO>:<BITMAP> 
> [...]]]
>
>        with <SERIAL NO> = serial number of the phone
>        and <BITMAP> =
>           bit 0: synchronise: <yes|no>
>           bit 1: fold into flat hierarchy: <yes|no>
>           bit 2: make this the target for new items from the phone:  
> <yes|no>
>
this is a global parameter
store in INBOX annotation ?

> where sanity checking of bit 2 would be the responsibility of the
> administrative interface, you would simply look for the first folder  
> you find
> with this flag set and put new items of that category into them.
>
> This should allow for any possible use case anyone might ever want,  
> I think.
>
>
>> is cyrus is ready to store our annotations or it needs patchs ?
>
> That is the big question, and the one that was really the one posed  
> to the
> list in the initial email - unfortunately we got sidetracked.
>
> We know it should, and I believe Bernhard Herzog has pointed out how  
> it is
> supposed to work with the current cyrus, but we still need to define  
> that
> annotation and then test whether it works as well in practice as  
> theory
> suggests.
>
> Any help on that would be greatly appreciated!
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From greve at kolabsys.com  Tue Mar 23 12:02:51 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Tue, 23 Mar 2010 12:02:51 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <2495D9C4-D00D-4F4E-AFD4-3B47354125A0@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003231119.54201.greve@kolabsys.com>
	<2495D9C4-D00D-4F4E-AFD4-3B47354125A0@libertech.fr>
Message-ID: <201003231202.52322.greve@kolabsys.com>

On Tuesday 23 March 2010 11:26:12 Alain Abbas wrote:
> this is a global parameter store in INBOX annotation ?

No. This would still be private to each users namespace, as previously 
discussed. Of course we could also have a global annotation that can have some 
system wide default values. Do you think we need them?

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100323/7f0bf91c/attachment.bin

From alain.abbas at libertech.fr  Tue Mar 23 18:05:16 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Tue, 23 Mar 2010 18:05:16 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003231202.52322.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003231119.54201.greve@kolabsys.com>
	<2495D9C4-D00D-4F4E-AFD4-3B47354125A0@libertech.fr>
	<201003231202.52322.greve@kolabsys.com>
Message-ID: <3ED4B8FD-76BD-4F24-BED9-040FC3FBF02C@libertech.fr>

hi
yes because the mode is global foldermode or flatmode for a  
mobiledevice and we must know that at the login before to parse  
folderlist



the way that run the 2 modes are very differents and for a device is  
flatmode or foldermode but nit the two in the same device
  i will commit the first code for the flatmode at the end of week
for the test i put a global define in the configfile to select it.


Le 23 mars 2010 ? 12:02, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Tuesday 23 March 2010 11:26:12 Alain Abbas wrote:
>> this is a global parameter store in INBOX annotation ?
>
> No. This would still be private to each users namespace, as previously
> discussed. Of course we could also have a global annotation that can  
> have some
> system wide default values. Do you think we need them?
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve


From alain.abbas at libertech.fr  Tue Mar 23 18:06:28 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Tue, 23 Mar 2010 18:06:28 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <201003231202.52322.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003231119.54201.greve@kolabsys.com>
	<2495D9C4-D00D-4F4E-AFD4-3B47354125A0@libertech.fr>
	<201003231202.52322.greve@kolabsys.com>
Message-ID: <DC524A78-AE09-42B1-9D4D-A088FBF33038@libertech.fr>





Le 23 mars 2010 ? 12:02, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Tuesday 23 March 2010 11:26:12 Alain Abbas wrote:
>> this is a global parameter store in INBOX annotation ?
>
> No. This would still be private to each users namespace, as previously
> discussed. Of course we could also have a global annotation that can  
> have some
> system wide default values. Do you think we need them?
>
i wanted to say global for the user not global for the system

> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From wrobel at pardus.de  Wed Mar 24 11:02:44 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 24 Mar 2010 11:02:44 +0100
Subject: [Kolab-devel] Strange behavior with ICal snychronisation
	Kolab	2.2.3
In-Reply-To: <000101caca11$0fe48610$2fad9230$@ch>
References: <000101caca11$0fe48610$2fad9230$@ch>
Message-ID: <20100324110244.14753ek54oju3dyc@webmail.pardus.de>

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi all
>
> Following feedback from a test which I did with a MAC and ICal functionality
> using Kolab 2.2.3. I configured a ICal Kalender with the name of the user
> account and with the URL:
>
> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>
> After the configuration I announced the configured Calender within ICal to
> the Kolab server and each entry of the calender was "put" to the related
> account on the Kolab server. After successful "announcement" we checked over
> Horde if all events was put correct to the users account and we can confirm
> this. In the first view everything was looking perfect. After more tests we
> noticed following:
>
> - Within every announcement or/and actualization of the related Calender
> within ICal the request is deleting EVERY Calender entry and "put's" every
> entry again to the Kolab server (no synch only a "delete all" as afterwards
> a "put again all"). Why is the stuff not synched and instead every time
> deleted and from scratch "put" again to the server?

I do not think you can do more with WebDAV. "PUT" is restricted to  
uploading a complete file to the server.

I checked the code and it also does not support more than this.

Another indication that the behavior you describe is to be expected  
might be that your client apparently knows this also. Otherwise it  
would try to update single events, no?

>
> - Another issue we recognized is, if the users launches within ICal the
> announcement and if you have more as - lets say 50 entry - ICal will give
> back an Error telling that the announcement was not successfull but in the
> background all data is "put" correctly (except that everything is again
> first of all "deleted" and afterwards from scratch again "put" to the Kolab
> server). It seems that ICal goes in a timeout and and Kolab works straight
> ahead in the background?

Do you see any associated errors on the server? Or is this purely a  
client issue? Does the client tell you more about the reason why it  
fails?

>
> - I looked to the flat files on the Kolab Server and the format I see there
> is similar to a Mail entry (Imap entry) meaning the stuff is in kolab.xml
> format and everything seems to be fine as it must be.
>
> - Is this something which is supported or did I try something which is not
> visible on was not planed?
>
> The main issue here is really that everytime a calender entry changes or
> whatever that the process will delete EVERYTHING within the Calender on the
> Kolab server and put afterwards again EVERYTHING on the server. From
> performance etc. reasons this is ugly and not really that what should be
> or.....?

This will only change with support for better protocols such as CalDAV  
or GroupDAV. At least as far as I know. Currently only WebDAV is  
supported.

>
> - Within Snow Leopard 10.6 -if I'm correctly informed - Apple remove the
> WebDAV functionality within ICal (they want that .MAC is used to earn $). I
> know there is a hack to be again able to use WebDAV but if I'm correct Kolab
> does not support WebDAV in this way that the stuff is afterwards available
> within Horde etc. correct?

I would say it does. But I might misunderstand your question.

Cheers,

Gunnar

>
> Sorry many questions but at the moment I'm a little bit confiused and not
> understanding the behavior specially because from scratch it would work if
> this case with DELETE all first and afterwards put again all on the server
> wouldn't be. Can you please give me quick a feedback if I did something
> false or did understand something false? Wihtin the logs I did not noticed
> something special.
>
> Kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
>
> _______________________________________________
> 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/20100324/c1c44155/attachment.bin

From soliva at comcept.ch  Wed Mar 24 11:52:41 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Wed, 24 Mar 2010 11:52:41 +0100
Subject: [Kolab-devel] Strange behavior with ICal snychronisationKolab
	2.2.3
In-Reply-To: <20100324110244.14753ek54oju3dyc@webmail.pardus.de>
References: <000101caca11$0fe48610$2fad9230$@ch>
	<20100324110244.14753ek54oju3dyc@webmail.pardus.de>
Message-ID: <000501cacb40$2086a180$6193e480$@ch>

Hi Gunnar

Many thanks for your feedback (by the way I wrote Bernhard a sperate mail
with a issue you would be probably intressted but is nothing to be posted
:-)



-----Urspr?ngliche Nachricht-----
Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Mittwoch, 24. M?rz 2010 11:03
An: kolab-devel at kolab.org
Betreff: Re: [Kolab-devel] Strange behavior with ICal snychronisationKolab
2.2.3

Hi Andrea,

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi all
>
> Following feedback from a test which I did with a MAC and ICal
functionality
> using Kolab 2.2.3. I configured a ICal Kalender with the name of the user
> account and with the URL:
>
> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>
> After the configuration I announced the configured Calender within ICal to
> the Kolab server and each entry of the calender was "put" to the related
> account on the Kolab server. After successful "announcement" we checked
over
> Horde if all events was put correct to the users account and we can
confirm
> this. In the first view everything was looking perfect. After more tests
we
> noticed following:
>
> - Within every announcement or/and actualization of the related Calender
> within ICal the request is deleting EVERY Calender entry and "put's" every
> entry again to the Kolab server (no synch only a "delete all" as
afterwards
> a "put again all"). Why is the stuff not synched and instead every time
> deleted and from scratch "put" again to the server?

>> I do not think you can do more with WebDAV. "PUT" is restricted to  
>> uploading a complete file to the server.

>> I checked the code and it also does not support more than this.

>> Another indication that the behavior you describe is to be expected  
>> might be that your client apparently knows this also. Otherwise it  
>> would try to update single events, no?

That is a good question and has probably something to do that Apple removed
the WebDav config position within ICal?!

>
> - Another issue we recognized is, if the users launches within ICal the
> announcement and if you have more as - lets say 50 entry - ICal will give
> back an Error telling that the announcement was not successfull but in the
> background all data is "put" correctly (except that everything is again
> first of all "deleted" and afterwards from scratch again "put" to the
Kolab
> server). It seems that ICal goes in a timeout and and Kolab works straight
> ahead in the background?

>> Do you see any associated errors on the server? Or is this purely a  
>> client issue? Does the client tell you more about the reason why it  
>> fails?

As a pity no the client only tells "it was not possible to announce the
data/calender" nothing else?! The server itself shows absolut no errors.

>
> - I looked to the flat files on the Kolab Server and the format I see
there
> is similar to a Mail entry (Imap entry) meaning the stuff is in kolab.xml
> format and everything seems to be fine as it must be.
>
> - Is this something which is supported or did I try something which is not
> visible on was not planed?
>
> The main issue here is really that everytime a calender entry changes or
> whatever that the process will delete EVERYTHING within the Calender on
the
> Kolab server and put afterwards again EVERYTHING on the server. From
> performance etc. reasons this is ugly and not really that what should be
> or.....?

>> This will only change with support for better protocols such as CalDAV  
>> or GroupDAV. At least as far as I know. Currently only WebDAV is  
>> supported.

Understood....the question would be in this case "Because I do not have
anymore the WebDAV config position in ICal "only the position private
server" how can ICal be configured to use WebDAV?

>
> - Within Snow Leopard 10.6 -if I'm correctly informed - Apple remove the
> WebDAV functionality within ICal (they want that .MAC is used to earn $).
I
> know there is a hack to be again able to use WebDAV but if I'm correct
Kolab
> does not support WebDAV in this way that the stuff is afterwards available
> within Horde etc. correct?

>> I would say it does. But I might misunderstand your question.

As mentioned above I only have two position to configure which means:

   .Mac mobile
   Private Server

I used Private Server and used the link:

https://[host}/client/rpc.php/kronolith/[Kolab User ID]

username and password

More I can not configure which means if this is done every event is going to
the server and on the server every event is stored in kolab.xml format
within IMAP. Again that we have no misunderstanding if so done the stuff is
in a perfect way afterwards available within kronolith. The only issue is
that if a event or whatever is changed the stuff is on the server from the
client overall deleted and again send to the server (this is a bad think and
is pointed to Bernhard within a separate mail).

If I understood you correct you have the opinion that ICal within Snow
Leopard can be configured with WebDAV function (even it is limited) that can
be the question is only how is this done if I do not have anymore the WebDav
function within ICal Snow Leopard?

Kind regards

Andrea

>
> Sorry many questions but at the moment I'm a little bit confiused and not
> understanding the behavior specially because from scratch it would work if
> this case with DELETE all first and afterwards put again all on the server
> wouldn't be. Can you please give me quick a feedback if I did something
> false or did understand something false? Wihtin the logs I did not noticed
> something special.
>
> Kind regards
>
> Andrea Soliva
>
> Mail: soliva at comcept.ch
>
> _______________________________________________
> 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  Wed Mar 24 12:58:30 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 24 Mar 2010 12:58:30 +0100
Subject: [Kolab-devel] Strange behavior with ICal
	snychronisationKolab	2.2.3
In-Reply-To: <000501cacb40$2086a180$6193e480$@ch>
References: <000101caca11$0fe48610$2fad9230$@ch>
	<20100324110244.14753ek54oju3dyc@webmail.pardus.de>
	<000501cacb40$2086a180$6193e480$@ch>
Message-ID: <20100324125830.203758fb9zp18e4g@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi Gunnar
>
> Many thanks for your feedback (by the way I wrote Bernhard a sperate mail
> with a issue you would be probably intressted but is nothing to be posted
> :-)
>
>
>
> -----Urspr?ngliche Nachricht-----
> Von: Gunnar Wrobel [mailto:wrobel at pardus.de] Im Auftrag von
> kolab-devel-bounces at kolab.org
> Gesendet: Mittwoch, 24. M?rz 2010 11:03
> An: kolab-devel at kolab.org
> Betreff: Re: [Kolab-devel] Strange behavior with ICal snychronisationKolab
> 2.2.3
>
> Hi Andrea,
>
> Quoting ComCept Soliva <soliva at comcept.ch>:
>
>> Hi all
>>
>> Following feedback from a test which I did with a MAC and ICal
> functionality
>> using Kolab 2.2.3. I configured a ICal Kalender with the name of the user
>> account and with the URL:
>>
>> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>>
>> After the configuration I announced the configured Calender within ICal to
>> the Kolab server and each entry of the calender was "put" to the related
>> account on the Kolab server. After successful "announcement" we checked
> over
>> Horde if all events was put correct to the users account and we can
> confirm
>> this. In the first view everything was looking perfect. After more tests
> we
>> noticed following:
>>
>> - Within every announcement or/and actualization of the related Calender
>> within ICal the request is deleting EVERY Calender entry and "put's" every
>> entry again to the Kolab server (no synch only a "delete all" as
> afterwards
>> a "put again all"). Why is the stuff not synched and instead every time
>> deleted and from scratch "put" again to the server?
>
>>> I do not think you can do more with WebDAV. "PUT" is restricted to
>>> uploading a complete file to the server.
>
>>> I checked the code and it also does not support more than this.
>
>>> Another indication that the behavior you describe is to be expected
>>> might be that your client apparently knows this also. Otherwise it
>>> would try to update single events, no?
>
> That is a good question and has probably something to do that Apple removed
> the WebDav config position within ICal?!
>
>>
>> - Another issue we recognized is, if the users launches within ICal the
>> announcement and if you have more as - lets say 50 entry - ICal will give
>> back an Error telling that the announcement was not successfull but in the
>> background all data is "put" correctly (except that everything is again
>> first of all "deleted" and afterwards from scratch again "put" to the
> Kolab
>> server). It seems that ICal goes in a timeout and and Kolab works straight
>> ahead in the background?
>
>>> Do you see any associated errors on the server? Or is this purely a
>>> client issue? Does the client tell you more about the reason why it
>>> fails?
>
> As a pity no the client only tells "it was not possible to announce the
> data/calender" nothing else?! The server itself shows absolut no errors.
>
>>
>> - I looked to the flat files on the Kolab Server and the format I see
> there
>> is similar to a Mail entry (Imap entry) meaning the stuff is in kolab.xml
>> format and everything seems to be fine as it must be.
>>
>> - Is this something which is supported or did I try something which is not
>> visible on was not planed?
>>
>> The main issue here is really that everytime a calender entry changes or
>> whatever that the process will delete EVERYTHING within the Calender on
> the
>> Kolab server and put afterwards again EVERYTHING on the server. From
>> performance etc. reasons this is ugly and not really that what should be
>> or.....?
>
>>> This will only change with support for better protocols such as CalDAV
>>> or GroupDAV. At least as far as I know. Currently only WebDAV is
>>> supported.
>
> Understood....the question would be in this case "Because I do not have
> anymore the WebDAV config position in ICal "only the position private
> server" how can ICal be configured to use WebDAV?
>
>>
>> - Within Snow Leopard 10.6 -if I'm correctly informed - Apple remove the
>> WebDAV functionality within ICal (they want that .MAC is used to earn $).
> I
>> know there is a hack to be again able to use WebDAV but if I'm correct
> Kolab
>> does not support WebDAV in this way that the stuff is afterwards available
>> within Horde etc. correct?
>
>>> I would say it does. But I might misunderstand your question.
>
> As mentioned above I only have two position to configure which means:
>
>    .Mac mobile
>    Private Server
>
> I used Private Server and used the link:
>
> https://[host}/client/rpc.php/kronolith/[Kolab User ID]
>
> username and password
>
> More I can not configure which means if this is done every event is going to
> the server and on the server every event is stored in kolab.xml format
> within IMAP. Again that we have no misunderstanding if so done the stuff is
> in a perfect way afterwards available within kronolith. The only issue is
> that if a event or whatever is changed the stuff is on the server from the
> client overall deleted and again send to the server (this is a bad think and
> is pointed to Bernhard within a separate mail).
>
> If I understood you correct you have the opinion that ICal within Snow
> Leopard can be configured with WebDAV function (even it is limited) that can
> be the question is only how is this done if I do not have anymore the WebDav
> function within ICal Snow Leopard?

Hm, no not really. First of all I don't know anything about ICal on  
Snow Leopard. I might ask my wife if I dare touch her Mac Book and  
play around with ICal. But I assume she'd rather divorce than let a  
programmer misconfigure her precious toy :)

So I used Thunderbird/Lightning to test the WebDAV functionality today.

And I think that this is working fine for you from what you describe.  
I think this is the intended mode of operation when using WebDAV. I  
assume the intended
mode of synchronization is GET -> make local changes -> PUT (or better  
LOCK -> GET -> make local changes -> PUT -> UNLOCK)

Cheers,

Gunnar


>
> Kind regards
>
> Andrea
>
>>
>> Sorry many questions but at the moment I'm a little bit confiused and not
>> understanding the behavior specially because from scratch it would work if
>> this case with DELETE all first and afterwards put again all on the server
>> wouldn't be. Can you please give me quick a feedback if I did something
>> false or did understand something false? Wihtin the logs I did not noticed
>> something special.
>>
>> Kind regards
>>
>> Andrea Soliva
>>
>> Mail: soliva at comcept.ch
>>
>> _______________________________________________
>> 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 <<
--------------------------------------------------------------------

-------------- 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/20100324/00d510a8/attachment.bin

From issues at kolab.org  Wed Mar 24 14:05:09 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:05:09 +0000
Subject: [Kolab-devel] [issue4240] Wish: Maillist icons for invitations and
	update mails	(rt#6065)
In-Reply-To: <1269435909.05.0.341863703774.issue4240@kolab.org>
Message-ID: <1269435909.05.0.341863703774.issue4240@kolab.org>


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

A customer wishs for a graphic feedback(icons) which mails are invitations (or
update mails) in the maillist. (like the clip icon of attachments.)

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24402
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Maillist icons for invitations and update mails (rt#6065)

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


From issues at kolab.org  Wed Mar 24 14:10:04 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:10:04 +0000
Subject: [Kolab-devel] [issue4241] Wish: Mark mail in the maillist with
	different colored	flags(rt#6066)
In-Reply-To: <1269436204.46.0.241370030466.issue4241@kolab.org>
Message-ID: <1269436204.46.0.241370030466.issue4241@kolab.org>


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

It should be possible to mark mails with different colored flags in the maillist.
(Like in e5 and in OL 2003).

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24404
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Mark mail in the maillist with different colored flags(rt#6066)

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


From issues at kolab.org  Wed Mar 24 14:19:20 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:19:20 +0000
Subject: [Kolab-devel] [issue4242] Wish: printed mail should contain the id
	name	optional.(rt#6067)
In-Reply-To: <1269436760.85.0.898371966398.issue4242@kolab.org>
Message-ID: <1269436760.85.0.898371966398.issue4242@kolab.org>


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

A customer wishs that it should be configurable to print the identity name on
the top of the mail print.

Use case: The printer is used by different people. It is not clear, to which
user a printed mail belongs (e.g. a mail with dist list in the To field).

Test:
1. Select a mail.
2. Click on Print.
=> Mail dialog pops up.
3. Set  option print id name at top of the print.
4. Print.
=> The mail print should contain the id name on the top.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24405
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: printed mail should contain the id name optional.(rt#6067)

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


From issues at kolab.org  Wed Mar 24 14:33:51 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:33:51 +0000
Subject: [Kolab-devel] [issue4243] Wish: Print all mails of a selected
	folder. (rt#6069)
In-Reply-To: <1269437631.52.0.373505232481.issue4243@kolab.org>
Message-ID: <1269437631.52.0.373505232481.issue4243@kolab.org>


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

A customer wants to print all mails of a selected folder. At the moment it is
not possible to print more than one mail at once.

RMB on a folder in the folder list should offer the "print whole folder" action.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24407
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Print all mails of a selected folder. (rt#6069)

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


From issues at kolab.org  Wed Mar 24 14:39:53 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:39:53 +0000
Subject: [Kolab-devel] [issue4244] Composer: attachment columns size should
	be	saved.(rt#6070)
In-Reply-To: <1269437993.25.0.965475045486.issue4244@kolab.org>
Message-ID: <1269437993.25.0.965475045486.issue4244@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Open a composer.
2. Add an attachment.
3. Change the column sizes of the attachment part in the composer.
4. Send the mail.
5. Open a composer.
6. Add an attachment
=> the column sizes of the attachment part is reset.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24408
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Composer: attachment columns size should be saved.(rt#6070)

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


From issues at kolab.org  Wed Mar 24 14:47:46 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:47:46 +0000
Subject: [Kolab-devel] [issue4245] Wish: searchbar should also search for
	mail	addresses(rt#6071)
In-Reply-To: <1269438466.58.0.0812287296504.issue4245@kolab.org>
Message-ID: <1269438466.58.0.0812287296504.issue4245@kolab.org>


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

A customer wishs that the fast searchbar in the mail component also searches for
mail addresses. If a To address have a name and an address part, only in the
name part will be searched.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24409
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: searchbar should also search for mail addresses(rt#6071)

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


From issues at kolab.org  Wed Mar 24 14:57:31 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 13:57:31 +0000
Subject: [Kolab-devel] [issue4246] Not possible to add umlauts to the move
	message	dialog(rt#6072)
In-Reply-To: <1269439051.97.0.74238911174.issue4246@kolab.org>
Message-ID: <1269439051.97.0.74238911174.issue4246@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Switch to the mail component.
2. Select a mail.
3. Press "m".
=> move message dialog appears.
4. Try to enter a folder with umlauts.
=> It is not possible to enter umlauts in this dialog.
The customer expects that he can also add umlauts in this dialog.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24410
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Not possible to add umlauts to the move message dialog(rt#6072)

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


From issues at kolab.org  Wed Mar 24 15:03:29 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 14:03:29 +0000
Subject: [Kolab-devel] [issue4247] Composer: After removing an attachment is
	the focus not	on the next attachment.
In-Reply-To: <1269439409.57.0.36837159278.issue4247@kolab.org>
Message-ID: <1269439409.57.0.36837159278.issue4247@kolab.org>


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

Tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Open a composer.
2. Add some attachments.
3. Select the second attachment and press Remove.
=> the next attachment is not selected/ the focus is not on the next attachment.
(Use case: It should be possible to delete all attachments from the composer, if
the user presses "remove" many times.)

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24411
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Composer: After removing an attachment is the focus not on the next attachment.

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


From issues at kolab.org  Wed Mar 24 15:11:26 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 24 Mar 2010 14:11:26 +0000
Subject: [Kolab-devel] [issue4248] Configure Filter dialog: Some filter
	conditions are not	translated to German(rt#6074)
In-Reply-To: <1269439886.38.0.0044245320109.issue4248@kolab.org>
Message-ID: <1269439886.38.0.0044245320109.issue4248@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
Req: Use German as language.
1. Switch to the mail component.
2. Settings->Configure filter....
=> Filter dialog opens.
filter conditions contain the untranslated (Subject, From, To, CC, Reply-To).
The customer expects these words to be translated to German consistent like in
the composer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24412
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Configure Filter dialog: Some filter conditions are not translated to German(rt#6074)

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


From issues at kolab.org  Thu Mar 25 10:19:23 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 09:19:23 +0000
Subject: [Kolab-devel] [issue4249] Crash while printing a mail without
	preview pane.	(rt#6075)
In-Reply-To: <1269508763.25.0.286148444839.issue4249@kolab.org>
Message-ID: <1269508763.25.0.286148444839.issue4249@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Switch to the mail component.
2. Configure Mail...->View ->Window deactivate the mail preview pane.
3. Select a mail.
4. File->Print
=> Crash. see backtrace.

----------
assignedto: allen
files: print-crash-20100325.kcrash
keyword: enterprise35, kde client, kkc
messages: 24426
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: critical
status: unread
title: Crash while printing a mail without preview pane. (rt#6075)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4249>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print-crash-20100325.kcrash
Type: application/octet-stream
Size: 3206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/611f13d9/print-crash-20100325.exe

From bernhard at intevation.de  Thu Mar 25 11:48:31 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 11:48:31 +0100
Subject: [Kolab-devel] Completing ActiveSync integration in Kolab,
	and a request for input on IMAP annotatemore extensions
In-Reply-To: <20100323095333.45130anc8qh59yts@webmail.pardus.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003221743.56547.bernhard@intevation.de>
	<20100323095333.45130anc8qh59yts@webmail.pardus.de>
Message-ID: <201003251148.35067.bernhard@intevation.de>

Am Dienstag, 23. M?rz 2010 09:53:33 schrieb Gunnar Wrobel:
> >> > As we are adding the second annotation of this type now I feel we
> >> > should indeed tackle the configuration topic again in the near future.
> >
> > I think we either have more annotations like this or it is the first.
> > So which one are you thinking about?
>
> We also store a potentially unlimited list of elements in the ?
> pxfb-readable-for annotation. We discussed the very same problem when ?
> we implemented the xfb concept as I had the same concerns then.

Okay, you've meant the length restriction.
I believe this could be solved in the server implementation,
if we find that conceptually putting the configuration in there 
is the right thing.

For me this is the first annotation that conceptually puts client 
configuration on the server. So far, we have markers for folders.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/fd07bf6d/attachment.bin

From bernhard at intevation.de  Thu Mar 25 11:55:12 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 11:55:12 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003230909.06991.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
Message-ID: <201003251155.13259.bernhard@intevation.de>

Am Dienstag, 23. M?rz 2010 11:08:47 schrieb Alain Abbas:
> im working on the "flat mode " for device who doesnt support others ?
> calendars an contacts than the default one
> i need a supplementary setting
> 1) a variables who tell if the device is in folder mode or flat mode
> 2) we could have a global setting by device type in the config file
>
> where to store the by device setting?

Ideally: On the device itself.
So you would probably need to transfer it. I cannot say if this is possible 
within active sync.

A workaround idea I have is:
Just offer two urls or the service, one flat and one hiearchical,
this way you can configure this on the device by chosing the service URL. 

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/f3ca29f6/attachment.bin

From greve at kolabsys.com  Thu Mar 25 12:34:26 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 12:34:26 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251155.13259.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
	<201003251155.13259.bernhard@intevation.de>
Message-ID: <201003251234.27039.greve@kolabsys.com>

On Thursday 25 March 2010 11:55:12 Bernhard Reiter wrote:
> Ideally: On the device itself.
> So you would probably need to transfer it. I cannot say if this is possible
> within active sync.

I don't think that's possible.

Also: Flattening the hierarchy is something that the server needs to do to 
then hide it from the device. So the code that depends on this configuration 
setting is on the server, not the device.


> A workaround idea I have is:
> Just offer two urls or the service, one flat and one hiearchical,
> this way you can configure this on the device by chosing the service URL.

Interesting idea.

ActiveSync uses a default URL, IIRC.

So maybe this would require some DNS magic.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/b7f14ee1/attachment.bin

From bernhard at intevation.de  Thu Mar 25 12:48:11 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 12:48:11 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251234.27039.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251155.13259.bernhard@intevation.de>
	<201003251234.27039.greve@kolabsys.com>
Message-ID: <201003251248.15283.bernhard@intevation.de>

Am Donnerstag, 25. M?rz 2010 12:34:26 schrieb Georg C. F. Greve:
> On Thursday 25 March 2010 11:55:12 Bernhard Reiter wrote:
> > Ideally: On the device itself.
> > So you would probably need to transfer it. I cannot say if this is
> > possible within active sync.
>
> I don't think that's possible.
>
> Also: Flattening the hierarchy is something that the server needs to do to
> then hide it from the device. So the code that depends on this
> configuration setting is on the server, not the device.

Sure the code is on the server, but the client (our device) should say what it 
wants, this is why conceptually the configuration should live on the client
in this case. (Again in an ideal world.)

> > A workaround idea I have is:
> > Just offer two urls or the service, one flat and one hiearchical,
> > this way you can configure this on the device by chosing the service URL.
>
> Interesting idea.
>
> ActiveSync uses a default URL, IIRC.
>
> So maybe this would require some DNS magic.

Yes, whatever. It is just a way to transfer the configuration from the device 
to the server.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/00fbe01e/attachment.bin

From alain.abbas at libertech.fr  Thu Mar 25 13:15:30 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 13:15:30 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251234.27039.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
	<201003251155.13259.bernhard@intevation.de>
	<201003251234.27039.greve@kolabsys.com>
Message-ID: <41F84D83-22EC-419B-8CF8-F62394EA99A0@libertech.fr>





Le 25 mars 2010 ? 12:34, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Thursday 25 March 2010 11:55:12 Bernhard Reiter wrote:
>> Ideally: On the device itself.
>> So you would probably need to transfer it. I cannot say if this is  
>> possible
>> within active sync.
>
> I don't think that's possible.
>
> Also: Flattening the hierarchy is something that the server needs to  
> do to
> then hide it from the device. So the code that depends on this  
> configuration
> setting is on the server, not the device.
>
>
>> A workaround idea I have is:
>> Just offer two urls or the service, one flat and one hiearchical,
>> this way you can configure this on the device by chosing the  
>> service URL.
>
> Interesting idea.
>
> ActiveSync uses a default URL, IIRC.
>
> So maybe this would require some DNS magic.
>
perhaps we could choise for the device
for the moment i know that just th iphone support more than one  
calendars and contacts addresbooks
> Best regards,
> Georg
>
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alain.abbas at libertech.fr  Thu Mar 25 13:22:17 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 13:22:17 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251234.27039.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<9346FC1E-FB54-4851-8143-D92F22FF639D@libertech.fr>
	<201003251155.13259.bernhard@intevation.de>
	<201003251234.27039.greve@kolabsys.com>
Message-ID: <F030B2D1-054B-4317-9CFA-4DA58257E115@libertech.fr>





Le 25 mars 2010 ? 12:34, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Thursday 25 March 2010 11:55:12 Bernhard Reiter wrote:
>> Ideally: On the device itself.
>> So you would probably need to transfer it. I cannot say if this is  
>> possible
>> within active sync.
>
> I don't think that's possible.
>
> Also: Flattening the hierarchy is something that the server needs to  
> do to
> then hide it from the device. So the code that depends on this  
> configuration
> setting is on the server, not the device.
>
>
true not possible without "usine a gaz"

>> A workaround idea I have is:
>> Just offer two urls or the service, one flat and one hiearchical,
>> this way you can configure this on the device by chosing the  
>> service URL.
>
> Interesting idea.
>
> ActiveSync uses a default URL, IIRC.
>
> So maybe this would require some DNS magic.
>
> Best regards,
> Georg
>
>
we must be carreful to do not have a complicated concept
think to the 2nd system .....

if we use annotation we could put it in the inbox annotation serial:mode
i could read it early in the sync process (just after the login)
default -> flat mode beczuse the magority of the mobile dont support  
the folder mode
and have an automatic mode because i could have the type of the mobile  
who sync

alain

> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alain.abbas at libertech.fr  Thu Mar 25 13:26:54 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 13:26:54 +0100
Subject: [Kolab-devel] zpushbackend and memory leak
Message-ID: <CD43439C-1DE2-47D9-BFBD-E9616C956353@libertech.fr>


i tested in stand alone mode on a debian 5 and apache 2 php 5.2.6-1  
and it seems that i dont have this memory leak
i will confirm soon with a kolab php install ( 5.2.8) ( must test  
again in the same configuration )
compilation options?

to test it just put the mobile in push mode


From greve at kolabsys.com  Thu Mar 25 13:27:11 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 13:27:11 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251248.15283.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251234.27039.greve@kolabsys.com>
	<201003251248.15283.bernhard@intevation.de>
Message-ID: <201003251327.12249.greve@kolabsys.com>

On Thursday 25 March 2010 12:48:11 Bernhard Reiter wrote:
> Sure the code is on the server, but the client (our device) should say what
>  it wants, this is why conceptually the configuration should live on the
>  client in this case. (Again in an ideal world.)

In an ideal world, all devices would support multiple folders.

The reason we need to discuss this is that we don't live in an ideal world, so 
a proposed resolution for the patch to cover our living in a non-ideal world 
that works only in the ideal world is a bit circular. ;)

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/8655dde2/attachment.bin

From issues at kolab.org  Thu Mar 25 14:17:12 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:17:12 +0000
Subject: [Kolab-devel] [issue4250] Edit "Out of office" replies: Resend
	notification only	after: days is missing.(rt#6076)
In-Reply-To: <1269523032.07.0.313857822059.issue4250@kolab.org>
Message-ID: <1269523032.07.0.313857822059.issue4250@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

In the Edit "out of office" replies dialog under the topic "Resend notification
only after" is in the textfield the days missing. Changing this value shows the
days.

Test:
1. Switch to Mail component.
2. Tools->Edit "out of office" replies
=> Open dialog. Look for the resend notification only after topic: 7 
Should be 7 days.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24434
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Edit "Out of office" replies: Resend notification only after: days is missing.(rt#6076)

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


From h.helwich at tarent.de  Thu Mar 25 14:19:34 2010
From: h.helwich at tarent.de (Hendrik Helwich)
Date: Thu, 25 Mar 2010 14:19:34 +0100
Subject: [Kolab-devel] Kolab SyncML Extension
Message-ID: <4BAB62E6.1040606@tarent.de>

Dear Kolab Developers,

my company has developed an open source SyncML server which is based on
the Kolab groupware. We are pleased to share this application with you
and hope you find it useful.
We have connected the Funambol SyncML Server with the Kolab Server to be able to support many devices.
We also added the very useful extension of a webservice which can be
used to access the kolab server by a sync client. This also includes an
XML Schema for the kolab types. Client development can be done in a more
streamlined, robust and defined way by accessing the webservice instead
of directly work on the imap server. It is possible to use established
tools to serialize the kolab types in a standardized defined format.
We would be pleased to receive any suggestions you may have.

You can access this project on:
http://evolvis.org/projects/syncphony/

Best regards,
Hendrik


-- 
tarent Gesellschaft f?r Softwareentwicklung und IT-Beratung mbH
Gesch?ftsf?hrer: Boris Esser, Elmar Geese
HRB AG Bonn 5168 - Ust-ID: DE122264941
http://www.tarent.com/

Heilsbachstr. 24, 53123 Bonn,   fon +49 228 52675-0,   fax +49 228 52675-25
Weigandufer 45,   12059 Berlin, fon +49 30 5682943-30, fax +49 228 52675-25
Sch?tzenstr. 18,  10117 Berlin, fon +49 30 27594853,   fax +49 30 78709617


From issues at kolab.org  Thu Mar 25 14:24:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:24:40 +0000
Subject: [Kolab-devel] [issue4251] Wish for option: Remove own Identities
	from reply list	for reply to all.(default unset) (rt#6077)
In-Reply-To: <1269523480.27.0.114441303954.issue4251@kolab.org>
Message-ID: <1269523480.27.0.114441303954.issue4251@kolab.org>


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

The customer wishs for an option "remove own identities from reply list" for the
reply to all action. With this option the user should be able to configure how
to handle the own identities with the reply to all action.The default should be
unset. So own ids shouldn't be remove.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24435
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish for option: Remove own Identities from reply list for reply to all.(default unset) (rt#6077)

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


From greve at kolabsys.com  Thu Mar 25 14:30:50 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 14:30:50 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <F030B2D1-054B-4317-9CFA-4DA58257E115@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251234.27039.greve@kolabsys.com>
	<F030B2D1-054B-4317-9CFA-4DA58257E115@libertech.fr>
Message-ID: <201003251430.51617.greve@kolabsys.com>

On Thursday 25 March 2010 13:22:17 Alain Abbas wrote:
> we must be carreful to do not have a complicated concept
> think to the 2nd system .....

I agree.

So maybe stick with the current idea, which may not win a beauty concept, but 
uses tested concepts and should get the job done solidly.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/d318ee08/attachment.bin

From issues at kolab.org  Thu Mar 25 14:31:16 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:31:16 +0000
Subject: [Kolab-devel] [issue4252] Wish: New options for reply to all
	(rt#6078)
In-Reply-To: <1269523876.02.0.112183225466.issue4252@kolab.org>
Message-ID: <1269523876.02.0.112183225466.issue4252@kolab.org>


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

The default behaviour of "reply to all" should be:
  * From address should be used as To address.
  * To addresses should be used as To addresses.
  * CC addresses should be still used as CC addresses.

The customer wishs also for a new option "reply to all in CC":
  * FROM -> TO
  * TO + CC -> CC

Please also have a look at the wish kolab/issue4251
Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24436
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: New options for reply to all (rt#6078)

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


From issues at kolab.org  Thu Mar 25 14:41:17 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:41:17 +0000
Subject: [Kolab-devel] [issue4253] Wish: Contacts: Global option to use Work
	address as	favorite address.(rt#6079)
In-Reply-To: <1269524477.88.0.308048149329.issue4253@kolab.org>
Message-ID: <1269524477.88.0.308048149329.issue4253@kolab.org>


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

A customer wishs for an option with which the contact work address becomes the
favorite address. At the moment the home address is the favorite.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24437
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Contacts: Global option to use Work address as favorite address.(rt#6079)

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


From issues at kolab.org  Thu Mar 25 14:46:54 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:46:54 +0000
Subject: [Kolab-devel] [issue4254] Side-by-Side view: d'n'd between
	calendars should be	possible(rt#6080)
In-Reply-To: <1269524814.6.0.564391760706.issue4254@kolab.org>
Message-ID: <1269524814.6.0.564391760706.issue4254@kolab.org>


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

Test:
Req: two calendar folders.
1. Switch to the calendar component with side-by-side view.
2. Create a test event.
3. D'n'D the test event from one calendar/agenda to a different calendar/agenda
at a different time.
This shold move the event to the new calendar. At the moment d'n'd between
calendars is not possible.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24438
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Side-by-Side view: d'n'd between calendars should be possible(rt#6080)

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


From issues at kolab.org  Thu Mar 25 14:52:32 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:52:32 +0000
Subject: [Kolab-devel] [issue4255] Kontact should show if a mail is urgent.
	(rt#5897)
In-Reply-To: <1269525152.64.0.540057474735.issue4255@kolab.org>
Message-ID: <1269525152.64.0.540057474735.issue4255@kolab.org>


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

Test:
1. Switch to mail component.
2. Open a composer.
3. Set option->urgent.
4. Send the mail to the test account.
5. Sync and look at the mail.
=> The urgent option doesn't have an effect.
The customer excepts that the mail is somehow highlighted.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24439
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Kontact should show if a mail is urgent. (rt#5897)

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


From issues at kolab.org  Thu Mar 25 14:59:43 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 13:59:43 +0000
Subject: [Kolab-devel] [issue4256] Event attendees tab,
	Select Addressee.. Enter Filter, empty topics are shown. (rt#6081)
In-Reply-To: <1269525583.82.0.386464730557.issue4256@kolab.org>
Message-ID: <1269525583.82.0.386464730557.issue4256@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Open create event dialog.
2. Switch to attendee tab.
3. Click on Select Addressee...
4. Enter "xxx" into the Filter on field.
=> Empty Other Addresses and empty dists lists points are displayed.
The custoemr expects, that empty topics are not displayed.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24440
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
status: unread
title: Event attendees tab, Select Addressee.. Enter Filter, empty topics are shown. (rt#6081)

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


From issues at kolab.org  Thu Mar 25 15:03:13 2010
From: issues at kolab.org (Sergio Martins)
Date: Thu, 25 Mar 2010 14:03:13 +0000
Subject: [Kolab-devel] [issue4257] "Always accept" policy doesn't set
	atendee status to	"accepted"
In-Reply-To: <1269525793.22.0.819146781551.issue4257@kolab.org>
Message-ID: <1269525793.22.0.819146781551.issue4257@kolab.org>


New submission from Sergio Martins <sergio at kdab.com>:

Requirements:

- Two user accounts, A and B.
- Account B has invitation policy set to "Always accept" (this config option is
in the admin interface).

Test:

1. A creates an event and invites B.
2. User calendar@<host>.com writes the event to B's calendar.
3. The invitation is automatically accepted (i.e. e-mail sent do A)

Bug:

>From user A point of view, B accepted and that is correct.

But, from B's POV, if he double clicks on the event, he will see that his status
isn't ACCEPTED. And, if you open the kolab.xml in kmail it says
<status>none</status>.


Excepted:

It should be accepted, just like when you use a policy of manually accepting
invitations.

Tested on e35.

----------
assignedto: thomas
keyword: server
messages: 24441
nosy: allen, martin, sergio, thomas, wilde, wrobel
priority: bug
status: unread
title: "Always accept" policy doesn't set atendee status to "accepted"

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


From ninaramus at mail.ru  Thu Mar 25 14:39:43 2010
From: ninaramus at mail.ru (=?koi8-r?Q?=CE=C9=CE=C1_=D2=C1=CD=D5=D3?=)
Date: Thu, 25 Mar 2010 16:39:43 +0300
Subject: [Kolab-devel]
	=?koi8-r?b?S29sYWItZGV2ZWwgRGlnZXN0LCBWb2wgODAsIElz?=
	=?koi8-r?b?c3VlIDMz?=
In-Reply-To: <mailman.2607.1269523033.2115.kolab-devel@kolab.org>
References: <mailman.2607.1269523033.2115.kolab-devel@kolab.org>
Message-ID: <E1NunHj-0003cl-00.ninaramus-mail-ru@f292.mail.ru>

??????????????


From issues at kolab.org  Thu Mar 25 15:07:00 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 14:07:00 +0000
Subject: [Kolab-devel] [issue4258] Wish: reminder configuration of calendars,
	IDs, email addresses(rt#6082)
In-Reply-To: <1269526020.25.0.141451428263.issue4258@kolab.org>
Message-ID: <1269526020.25.0.141451428263.issue4258@kolab.org>


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

A customer wish more configuration possibilities for the reminder.

It should be set which calendar resource or which identities in an event or
which email addresses as attendee in an event should trigger an alarm.

Use case: The users want to configure when the reminder should appear. 

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24443
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: reminder configuration of calendars, IDs, email addresses(rt#6082)

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


From bernhard at intevation.de  Thu Mar 25 15:09:45 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 15:09:45 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003230909.06991.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>
	<201003230909.06991.greve@kolabsys.com>
Message-ID: <201003251509.48897.bernhard@intevation.de>

[Just to indicate that there is a discussion going on for adding another 
annotation, I am sending a copy to kolab-format at . ]

Am Dienstag, 23. M?rz 2010 09:09:06 schrieb Georg C. F. Greve:
> Hence so far I'm still in favor of
>
> ????????/vendor/kolab/activesync
>
> as the name for the extended IMAP annotation, which could be re-used in
> case someone else (Horde?) came up with another activesync implementation,
> but won't taint the namespaces for other potential syncronisation
> protocols.

Okay, we need to put mobile device configuration on the server, 
because activesync does not allow to offer the clients a way to transfer a few 
settings. (If it would we could save the configuration on the device which is 
something I would conceptually prefer.)

Any mechanism we invent to do so, should be as generic as possible 
to maximise its use.

Because this is a limitation of activesync, the suggestion is to 
use "activesync" as name for a IMAP folder annotation and to save within each 
folder if it should be synced for a number of different devices.
This indication does not seem to be useful in general as
another sync method, let us call it betasync, might not need such a 
limitation.
So up to now I am okay with using "activesync" as the name of the annotation.
I think it is okay to use an annotation, because this configuration needs to 
be per user on all folders, including the ones that are read-only. An IMAP 
server already has something similiar with the \seen flag, so it will be 
doable. Using something else like a special IMAP object will pose problems 
with doing this per user, e.g. because of the read-only support or it will be 
farer away from the folder.

Am Mittwoch, 17. M?rz 2010 09:04:35 schrieb Georg C. F. Greve:
>                 <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
>
>         with <BOOL> = 1 or 0 (for yes or no)
>         and <SERIAL NO> = serial number of the phone
>
> to allow a per-device setting of synchronisation preferences.

Because the default will be to not sync a device, I think we can do this in a 
simpler way like:

   {$udid} *{<SPACE> {$udid}} 
 
where $udid is a unique device id not containing spaces,
which is similar to how entries are separated 
in  /vendor/kolab/pxfb-readable-for
see 
http://ftp.intevation.de/users/bernhard/scratch/extended-freebusy-concept-0.92%2Bdev20080503-ber1-pub2.pdf

In order to make device numbers unique we could propose prefixes in the kolab 
space like "iphone-" or backendspecifics like "zpush12-".
So it would be come "iphone-123456" if we are sure that 123456 is a unique 
iphone number. 

So an entry like "iphone-123 iphone-789"
would mean the devices 123 and 789 would be synced with this folder, all 
others would not.

Bernhard




-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/3de87cfd/attachment.bin

From issues at kolab.org  Thu Mar 25 15:14:10 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 25 Mar 2010 14:14:10 +0000
Subject: [Kolab-devel] [issue4259] Wish: whole day events should add a small
	side line in	the agenda view. (rt#6083)
In-Reply-To: <1269526450.22.0.975739552849.issue4259@kolab.org>
Message-ID: <1269526450.22.0.975739552849.issue4259@kolab.org>


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

At the moment whole day events are just at the top of the calendar.
Some users miss this information. So the whole day events should also be shown
as small side line in the agenda of the day. (Like in OL).

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24445
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: whole day events should add a small side line in the agenda view. (rt#6083)

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


From greve at kolabsys.com  Thu Mar 25 15:22:25 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 15:22:25 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251509.48897.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003230909.06991.greve@kolabsys.com>
	<201003251509.48897.bernhard@intevation.de>
Message-ID: <201003251522.26491.greve@kolabsys.com>

On Thursday 25 March 2010 15:09:45 Bernhard Reiter wrote:
> Because the default will be to not sync a device, I think we can do this in
>  a simpler way like: [...]

How would this allow to turn synchronisation OFF for a specific device for a 
folder that is synchronised by default?

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/c432f9a0/attachment.bin

From alain.abbas at libertech.fr  Thu Mar 25 15:48:46 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 15:48:46 +0100
Subject: [Kolab-devel] Where to save mobile device configuration?
	(Completing ActiveSync integration in Kolabmore extensions)
In-Reply-To: <201003251327.12249.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251234.27039.greve@kolabsys.com>
	<201003251248.15283.bernhard@intevation.de>
	<201003251327.12249.greve@kolabsys.com>
Message-ID: <EE4138D2-A02B-440C-8A95-2FDF69C939A7@libertech.fr>





Le 25 mars 2010 ? 13:27, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Thursday 25 March 2010 12:48:11 Bernhard Reiter wrote:
>> Sure the code is on the server, but the client (our device) should  
>> say what
>> it wants, this is why conceptually the configuration should live on  
>> the
>> client in this case. (Again in an ideal world.)
>
definitively not possible


> In an ideal world, all devices would support multiple folders.
>
> The reason we need to discuss this is that we don't live in an ideal  
> world, so
> a proposed resolution for the patch to cover our living in a non- 
> ideal world
> that works only in the ideal world is a bit circular. ;)
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alain.abbas at libertech.fr  Thu Mar 25 16:09:29 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 16:09:29 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251509.48897.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<A9F5B3F4-74D2-4B76-AB13-7A784B30FA5A@libertech.fr>
	<201003230909.06991.greve@kolabsys.com>
	<201003251509.48897.bernhard@intevation.de>
Message-ID: <5A88F269-4858-4B83-B65D-9B2C5A68DD5C@libertech.fr>





Le 25 mars 2010 ? 15:09, Bernhard Reiter <bernhard at intevation.de> a  
?crit :

> [Just to indicate that there is a discussion going on for adding  
> another
> annotation, I am sending a copy to kolab-format at . ]
>
> Am Dienstag, 23. M?rz 2010 09:09:06 schrieb Georg C. F. Greve:
>> Hence so far I'm still in favor of
>>
>>         /vendor/kolab/activesync
>>
>> as the name for the extended IMAP annotation, which could be re- 
>> used in
>> case someone else (Horde?) came up with another activesync  
>> implementation,
>> but won't taint the namespaces for other potential syncronisation
>> protocols.
>
> Okay, we need to put mobile device configuration on the server,
> because activesync does not allow to offer the clients a way to  
> transfer a few
> settings. (If it would we could save the configuration on the device  
> which is
> something I would conceptually prefer.)
>
> Any mechanism we invent to do so, should be as generic as possible
> to maximise its use.
>
> Because this is a limitation of activesync, the suggestion is to
> use "activesync" as name for a IMAP folder annotation and to save  
> within each
> folder if it should be synced for a number of different devices.
> This indication does not seem to be useful in general as
> another sync method, let us call it betasync, might not need such a
> limitation.
> So up to now I am okay with using "activesync" as the name of the  
> annotation.
> I think it is okay to use an annotation, because this configuration  
> needs to
> be per user on all folders, including the ones that are read-only.  
> An IMAP
> server already has something similiar with the \seen flag, so it  
> will be
> doable. Using something else like a special IMAP object will pose  
> problems
> with doing this per user, e.g. because of the read-only support or  
> it will be
> farer away from the folder.
>
> Am Mittwoch, 17. M?rz 2010 09:04:35 schrieb Georg C. F. Greve:
>>                <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
>>
>>        with <BOOL> = 1 or 0 (for yes or no)
>>        and <SERIAL NO> = serial number of the phone
>>
>> to allow a per-device setting of synchronisation preferences.
>
> Because the default will be to not sync a device, I think we can do  
> this in a
> simpler way like:
>
>   {$udid} *{<SPACE> {$udid}}
>
seems to be a php serialization ? isnt it ?
where is the value for the uid?
could be 1 0

the default fot INBOX Could be yes by defaut and if we have the sid  
with 0 for a folder we doesn t sync it
and the inverse for shared and user namespace
in that way
with nothing in annotation the device has just INBOX FOLDERs , like  
that without any setting the user would have their things on the device
and if he would have specials things like shared or other he could set  
it

alain
> where $udid is a unique device id not containing spaces,
> which is similar to how entries are separated
> in  /vendor/kolab/pxfb-readable-for
> see
> http://ftp.intevation.de/users/bernhard/scratch/extended-freebusy-concept-0.92%2Bdev20080503-ber1-pub2.pdf
>
> In order to make device numbers unique we could propose prefixes in  
> the kolab
> space like "iphone-" or backendspecifics like "zpush12-".
> So it would be come "iphone-123456" if we are sure that 123456 is a  
> unique
> iphone number.
>
> So an entry like "iphone-123 iphone-789"
> would mean the devices 123 and 789 would be synced with this folder,  
> all
> others would not.
>
not ok with that , it is improbable , impossible that the same user  
has 2 mobiles with the same serial number.
other think , i get the serial number of the device if we add a part  
in the serial number how the bakend could know witch device it is ????


> Bernhard
>
>
>
>
> -- 
> Managing Director - Owner: www.intevation.net       (Free Software  
> Company)
> Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagn 
> er
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From bernhard at intevation.de  Thu Mar 25 16:31:12 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 16:31:12 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251522.26491.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251509.48897.bernhard@intevation.de>
	<201003251522.26491.greve@kolabsys.com>
Message-ID: <201003251631.18995.bernhard@intevation.de>

Am Donnerstag, 25. M?rz 2010 15:22:25 schrieb Georg C. F. Greve:
> On Thursday 25 March 2010 15:09:45 Bernhard Reiter wrote:
> > Because the default will be to not sync a device, I think we can do this
> > in a simpler way like: [...]
>
> How would this allow to turn synchronisation OFF for a specific device for
> a folder that is synchronised by default?

In my understanding so far the values are per folder.
So a folder will only get synced to a device 
if the annotation on that folder lists the id of device.

Having no annotation on the folder or not having the id of the device in 
question in the annotation will lead to a folder not being synced to that 
device.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/bd0ee4da/attachment.bin

From greve at kolabsys.com  Thu Mar 25 17:41:21 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 17:41:21 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251631.18995.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251522.26491.greve@kolabsys.com>
	<201003251631.18995.bernhard@intevation.de>
Message-ID: <201003251741.22191.greve@kolabsys.com>

On Thursday 25 March 2010 16:31:12 Bernhard Reiter wrote:
> Having no annotation on the folder or not having the id of the device in
> question in the annotation will lead to a folder not being synced to that
> device.

I don't think that's a very good idea. 

The most common use case would be for users to set the folders that would be 
synced by default with all their phones. The second most common use case would 
be to define deviations from that for one or two particular phones.

Having to turn off the default for a folder, in order to then turn it on for 
all phones that are supposed to sync, only to exclude the one that you wanted 
to exlude in the first place, seems a rather circuitous route.

And not syncing anything by default is likely to be perceived as a bug, and 
would provide rather maintenance intensive (and thus costly) support for all 
those users who just want to sync their standard folders. 

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/554a6e01/attachment.bin

From bernhard at intevation.de  Thu Mar 25 18:21:00 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 25 Mar 2010 18:21:00 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251741.22191.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251631.18995.bernhard@intevation.de>
	<201003251741.22191.greve@kolabsys.com>
Message-ID: <201003251821.03952.bernhard@intevation.de>

Am Donnerstag, 25. M?rz 2010 17:41:21 schrieb Georg C. F. Greve:
> On Thursday 25 March 2010 16:31:12 Bernhard Reiter wrote:
> > Having no annotation on the folder or not having the id of the device in
> > question in the annotation will lead to a folder not being synced to that
> > device.
>
> I don't think that's a very good idea.
>
> The most common use case would be for users to set the folders that would
> be synced by default with all their phones. The second most common use case
> would be to define deviations from that for one or two particular phones.

You did agree to the notion before that the default cannot be YES:

Am Montag, 22. M?rz 2010 13:34:43 schrieb Georg C. F. Greve:
> > Note that anyone could just give you an ACL on a folder, so if the
> > default is "yes", this means I can just spam your appointments by giving
> > you a folder that immedeately gets synced. So a default of NO seems to be
> > the better solution. Or something like YES for folders where in my
> > personal namespace and NO for all others.
>
> Agreed.

Am Donnerstag, 25. M?rz 2010 17:41:21 schrieb Georg C. F. Greve:
> Having to turn off the default for a folder, in order to then turn it on
> for all phones that are supposed to sync, only to exclude the one that you
> wanted to exlude in the first place, seems a rather circuitous route.

Then we can do it the other ways around:
Existance of the annotation means: The folder can get synced,
unless the device is listed as explicit value.

You still need to enable sync then, though, but you only need to enable it 
once for a folder and it will work with all devices.

> And not syncing anything by default is likely to be perceived as a bug, and
> would provide rather maintenance intensive (and thus costly) support for
> all those users who just want to sync their standard folders.

What your standard folders are cannot be determined that easily.
There are the default folders of each account, but users might already depend 
on folders from group accounts, anonymous accounts or simply other users.
You must enable those to get a good experience, and they cannot be 
automatically enabled as YES.

So I guess one good solution is to have an activation function in the clients, 
especially in the web client. So people will have to configure the device and 
then use the activation function in their client, this one will ask list all 
folders they currently have and will ask if it should set the sync annotation 
on them.

As we need this anyway, we could keep things simple at that point and do not 
introduce another role for default folders or the folders that are under the 
namespace of the first primary user and all that.

Bernhard



-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.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/20100325/23c67d1e/attachment.bin

From alain.abbas at libertech.fr  Thu Mar 25 18:45:38 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Thu, 25 Mar 2010 18:45:38 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251741.22191.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251522.26491.greve@kolabsys.com>
	<201003251631.18995.bernhard@intevation.de>
	<201003251741.22191.greve@kolabsys.com>
Message-ID: <969B7A85-65AF-48B1-8E02-1BD08C5646DA@libertech.fr>





Le 25 mars 2010 ? 17:41, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Thursday 25 March 2010 16:31:12 Bernhard Reiter wrote:
>> Having no annotation on the folder or not having the id of the  
>> device in
>> question in the annotation will lead to a folder not being synced  
>> to that
>> device.
>
> I don't think that's a very good idea.
>
> The most common use case would be for users to set the folders that  
> would be
> synced by default with all their phones. The second most common use  
> case would
> be to define deviations from that for one or two particular phones.
>
> Having to turn off the default for a folder, in order to then turn  
> it on for
> all phones that are supposed to sync, only to exclude the one that  
> you wanted
> to exlude in the first place, seems a rather circuitous route.
>
> And not syncing anything by default is likely to be perceived as a  
> bug, and
> would provide rather maintenance intensive (and thus costly) support  
> for all
completly i agree
best for me is
by default
inbox/* is synced the others namespaces no
>
> those users who just want to sync their standard folders.
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From greve at kolabsys.com  Thu Mar 25 18:51:08 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Thu, 25 Mar 2010 18:51:08 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251821.03952.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251741.22191.greve@kolabsys.com>
	<201003251821.03952.bernhard@intevation.de>
Message-ID: <201003251851.09086.greve@kolabsys.com>

On Thursday 25 March 2010 18:21:00 Bernhard Reiter wrote:
> You did agree to the notion before that the default cannot be YES:

You misunderstood what was written.

That was about shared folders, not a users' own folders.


> Then we can do it the other ways around:
> Existance of the annotation means: The folder can get synced,
> unless the device is listed as explicit value.
> [...]

This is getting more and more complicated, and for no obvious reason.

I would suggest to stick with the simple approach that was suggested by Alain: 
A private (so user specific) annotation per folder that can carry

	(a) the default value for this folder
	(b) deviations for the default for this folder by phone 

If the annotation does not exist, the default is YES for folders in the 
namespace of the user (INBOX/*) and NO for all other folders.

If a device needs special settings, that can be defined as part of the device 
specific settings. Administration will take place over the web admin interface 
by default, Gunnar already said that this kind of structure would be easy to 
implement - in the area of one day.

The only open question is where we get the device serial number from for the 
configuration, as we do not want the user to have to enter this - in fact we 
would prefer to have a better representation of the phone than its serial 
number in the user interface, if possible.

So if you seek to solve a riddle, this would would be worthwhile.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100325/2ed500f7/attachment.bin

From issues at kolab.org  Fri Mar 26 06:20:39 2010
From: issues at kolab.org (Alex Potter)
Date: Fri, 26 Mar 2010 05:20:39 +0000
Subject: [Kolab-devel] [issue4260] Unable to view full headers in web-client
In-Reply-To: <1269580839.36.0.230893251704.issue4260@kolab.org>
Message-ID: <1269580839.36.0.230893251704.issue4260@kolab.org>


New submission from Alex Potter <alex at ap-consulting.co.uk>:

When attempting to view full headers of an email in the web client.

Steps to reproduce:

open the web client via the URL https://smtp.example.com/client
Open an existing email
select headers/show all headers

the email closes and the display returns to the INBOX with the client error
message "Requested message not found."

This occurs both on my "live" system and the testing box, both kolab 2.2.3.

the live system's OS is Ubuntu 8.04, whereas the test system lives on Ubuntu 10.04.

----------
messages: 24462
nosy: alepot
priority: bug
status: unread
title: Unable to view full headers in web-client

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


From issues at kolab.org  Fri Mar 26 14:44:31 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 13:44:31 +0000
Subject: [Kolab-devel] [issue4261] Wish: Print whole day events at top of a
	day print.
In-Reply-To: <1269611071.48.0.326874281617.issue4261@kolab.org>
Message-ID: <1269611071.48.0.326874281617.issue4261@kolab.org>


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

Print a events in day mode. At the moment whole day events are displayed in the
agenda, too. The customer wishs, that these whole day events are displey at the
top of the print(under the the date) and no longer in the agenda. This should
save space for the time associated events.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24470
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Print whole day events at top of a  day print.

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


From issues at kolab.org  Fri Mar 26 14:50:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 13:50:06 +0000
Subject: [Kolab-devel] [issue4262] Wish: add/remove attendee,
	option : send update mail only to changed attendees(rt#6085)
In-Reply-To: <1269611406.4.0.47229874447.issue4262@kolab.org>
Message-ID: <1269611406.4.0.47229874447.issue4262@kolab.org>


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

The customer wish for the option send an update mail only to added/removed
attendees.
Use case: A lot of changing of the attendees, only the changed members should be
informed and not all attendees.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24471
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: add/remove attendee, option : send update mail only to changed attendees(rt#6085)

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


From issues at kolab.org  Fri Mar 26 14:56:14 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 13:56:14 +0000
Subject: [Kolab-devel] [issue4263] Wish: It should be possible with the
	context menu to set	the number of month in the date
	navigator.(rt#6086)
In-Reply-To: <1269611774.34.0.503429787692.issue4263@kolab.org>
Message-ID: <1269611774.34.0.503429787692.issue4263@kolab.org>


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

The customer wishs, that he can set the numbers of month at the small month/date
navigator at the upper left. At he moment the number of month depends on the
size of the pane.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24474
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: It should be possible with the context menu to set the number of month in the date navigator.(rt#6086)

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


From issues at kolab.org  Fri Mar 26 15:02:34 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:02:34 +0000
Subject: [Kolab-devel] =?utf-8?q?=5Bissue4264=5D_Advanced_alarm_dialog_of_?=
 =?utf-8?q?an_event/a_todo=3A_Change_German_=22Hinzuf=C3=BCgen=22_into_=22?=
 =?utf-8?b?TmV1IihydCM2MDg3KQ==?=
In-Reply-To: <1269612154.31.0.151532676515.issue4264@kolab.org>
Message-ID: <1269612154.31.0.151532676515.issue4264@kolab.org>


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

Test:
Req: The language is German.
1. Switch to the calendar.
2. Open a new event.
3. Set alarm on.
4. Click on Advanced...
=> In the dialog is a "Hinzuf?gen". This should be changed into "Neu".
Same in the todo advanced alarm dialog.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24475
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Advanced alarm dialog of an event/a todo: Change German "Hinzuf?gen" into "Neu"(rt#6087)

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


From issues at kolab.org  Fri Mar 26 15:10:17 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:10:17 +0000
Subject: [Kolab-devel] [issue4265] Wish: Archive mail folder: option "remove
	mails from	folders, but don't remove the folders" (rt#6088)
In-Reply-To: <1269612617.95.0.534834381019.issue4265@kolab.org>
Message-ID: <1269612617.95.0.534834381019.issue4265@kolab.org>


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

The customer wishs for another mail archive option.
At the moment the folders could be completely removed.
The option " remove mails from folders, but don't remove the folders" should be
added.

Test:
1. Switch to the mail component.
2. RMB on a folder->archive mail...
=>Mail archive dialog apperas. 

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24476
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Archive mail folder: option "remove mails from folders, but don't remove the folders" (rt#6088)

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


From issues at kolab.org  Fri Mar 26 15:16:10 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:16:10 +0000
Subject: [Kolab-devel] [issue4266] birthday resource should be named
	"Geburtstage" if German	language is used(rt#6089)
In-Reply-To: <1269612970.14.0.763570217923.issue4266@kolab.org>
Message-ID: <1269612970.14.0.763570217923.issue4266@kolab.org>


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

Test:
Req: Use language German
1. Switch to the calendar component.
2. Add resource. birthday resource.
=> The default name is "birthday resource". The customer expects the German name 
"Geburtstage" for this resource.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24477
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
status: unread
title: birthday resource should be named "Geburtstage" if German language is used(rt#6089)

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


From issues at kolab.org  Fri Mar 26 15:23:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:23:40 +0000
Subject: [Kolab-devel] [issue4267] information about the alarm is missing in
	the event	views. (rt#6090)
In-Reply-To: <1269613420.94.0.0163845321649.issue4267@kolab.org>
Message-ID: <1269613420.94.0.0163845321649.issue4267@kolab.org>


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

Test:
1. Switch to the calendar component.
2. Create an event with alarm.
3. Look at the tooltip of the alarm. (no alarm info like when is the alarm
triggerd?)
4. RMB on the event ->View. (no alarm info)
5. Select the event and look at the left event pane (no alarm info).
The customer expects, that the event is display with information about the alarm.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24478
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: information about the alarm is missing in the event views. (rt#6090)

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


From issues at kolab.org  Fri Mar 26 15:50:18 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:50:18 +0000
Subject: [Kolab-devel] [issue4268] Calendar: Black triangle shows that
	events are somewhere	up,
	but the user scrolled already to 0:00 (rt#6091)
In-Reply-To: <1269615018.55.0.0264387773308.issue4268@kolab.org>
Message-ID: <1269615018.55.0.0264387773308.issue4268@kolab.org>


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

Test:
1. Switch to the calendar with agenda view.
2. Create an event at 0:00 to 2:00.
3. Scroll to the top.
=> A small black triangle above the day is still displayed. This triangle should
vanish, if all above events are displayed. As the 0:00-2:00 is the uppest event
and is displayed, the black triangle should vanish.


Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24480
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Calendar: Black triangle shows that events are somewhere up, but the user scrolled already to 0:00 (rt#6091)

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


From issues at kolab.org  Fri Mar 26 15:54:45 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 14:54:45 +0000
Subject: [Kolab-devel] [issue4269] Calendar: title of an event in the agenda
	view should	always be on top of the event(rt#6092)
In-Reply-To: <1269615285.08.0.479547525924.issue4269@kolab.org>
Message-ID: <1269615285.08.0.479547525924.issue4269@kolab.org>


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

Test:
1. Switch to the calendar in agenda view.
2. Create a new event.
=> the title of the event is vertical centered. Should be on top of the event.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24481
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Calendar: title of an event in the agenda view  should always be on top of the event(rt#6092)

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


From issues at kolab.org  Fri Mar 26 16:02:07 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 26 Mar 2010 15:02:07 +0000
Subject: [Kolab-devel] [issue4270] alarm of an event with two lines shows
	strange half line	title.(rt#6093)
In-Reply-To: <1269615727.14.0.76340878837.issue4270@kolab.org>
Message-ID: <1269615727.14.0.76340878837.issue4270@kolab.org>


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

tested with Kontact e35 kdepim 20100319.1105255-kk4

Test:
1. Create an event with alarm and title:
test line 1
test line 2
2. Wait for the alarm.
=> The display of the title of the event is broken. See screenshot. 
It would be better if line breaks are ignored in the display of the title.

----------
assignedto: allen
files: reminder-2lines-20100326.png
keyword: enterprise35, kde client
messages: 24482
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: alarm of an event with two lines shows strange half line title.(rt#6093)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4270>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reminder-2lines-20100326.png
Type: image/png
Size: 36420 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100326/1c7a62c2/reminder-2lines-20100326-0001.png

From issues at kolab.org  Fri Mar 26 17:17:23 2010
From: issues at kolab.org (Sergio Martins)
Date: Fri, 26 Mar 2010 16:17:23 +0000
Subject: [Kolab-devel] [issue4271] In korganizer's resource view,
	creating a subresource containing a / originates a crash
In-Reply-To: <1269620243.75.0.207965530457.issue4271@kolab.org>
Message-ID: <1269620243.75.0.207965530457.issue4271@kolab.org>


New submission from Sergio Martins <sergio at kdab.com>:

In korganizer's resource view, creating a sub-resource containing a / originates
a crash.

----------
assignedto: sergio
keyword: enterprise35, kde client
messages: 24486
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
status: in-progress
title: In korganizer's resource view, creating a subresource containing a / originates a crash

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


From wrobel at pardus.de  Fri Mar 26 17:41:43 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 26 Mar 2010 17:41:43 +0100
Subject: [Kolab-devel] Kolab SyncML Extension
In-Reply-To: <4BAB62E6.1040606@tarent.de>
References: <4BAB62E6.1040606@tarent.de>
Message-ID: <20100326174143.1908360605ps8mgw@webmail.pardus.de>

Quoting Hendrik Helwich <h.helwich at tarent.de>:

> Dear Kolab Developers,
>
> my company has developed an open source SyncML server which is based on
> the Kolab groupware. We are pleased to share this application with you
> and hope you find it useful.
> We have connected the Funambol SyncML Server with the Kolab Server  
> to be able to support many devices.
> We also added the very useful extension of a webservice which can be
> used to access the kolab server by a sync client. This also includes an
> XML Schema for the kolab types. Client development can be done in a more
> streamlined, robust and defined way by accessing the webservice instead
> of directly work on the imap server. It is possible to use established
> tools to serialize the kolab types in a standardized defined format.
> We would be pleased to receive any suggestions you may have.
>
> You can access this project on:
> http://evolvis.org/projects/syncphony/

Nice to see tarent joining the Kolab crowd with an open source  
project. Thanks for providing this!

Cheers,

Gunnar

>
> Best regards,
> Hendrik
>
>
> --
> tarent Gesellschaft f?r Softwareentwicklung und IT-Beratung mbH
> Gesch?ftsf?hrer: Boris Esser, Elmar Geese
> HRB AG Bonn 5168 - Ust-ID: DE122264941
> http://www.tarent.com/
>
> Heilsbachstr. 24, 53123 Bonn,   fon +49 228 52675-0,   fax +49 228 52675-25
> Weigandufer 45,   12059 Berlin, fon +49 30 5682943-30, fax +49 228 52675-25
> Sch?tzenstr. 18,  10117 Berlin, fon +49 30 27594853,   fax +49 30 78709617
>
> _______________________________________________
> 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/20100326/76603036/attachment.bin

From bernhard at intevation.de  Fri Mar 26 21:18:46 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 26 Mar 2010 21:18:46 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003251851.09086.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251821.03952.bernhard@intevation.de>
	<201003251851.09086.greve@kolabsys.com>
Message-ID: <201003262118.46927.bernhard@intevation.de>

On Thursday 25 March 2010 18:51:08 Georg C. F. Greve wrote:
> On Thursday 25 March 2010 18:21:00 Bernhard Reiter wrote:
> > You did agree to the notion before that the default cannot be YES:
>
> You misunderstood what was written.
>
> That was about shared folders, not a users' own folders.

Well, if those folder contain calender data that the users needs on a daily 
basis, this user will miss them on the default sync as well.

> > Then we can do it the other ways around:
> > Existance of the annotation means: The folder can get synced,
> > unless the device is listed as explicit value.
> > [...]
>
> This is getting more and more complicated, and for no obvious reason.

I have the opposite impression and I am trying to understand what is going on.

> I would suggest to stick with the simple approach that was suggested by
> Alain: A private (so user specific) annotation per folder that can carry
>
>         (a) the default value for this folder
>         (b) deviations for the default for this folder by phone
>
> If the annotation does not exist, the default is YES for folders in the
> namespace of the user (INBOX/*) and NO for all other folders.

Overall I think it is more simple to have one rule for each folder
and do not depend on if the folder is part of the inbox or not.
(This is not easy to determine on some IMAP layouts, btw.)

You are saying that people will want to have a sync by default, but for 
security reasons that is not possible for all folders as we have established.
So I am proposing a scheme which keeps one rule for all folders
which includes on activation mechanism with a real Kolab Client, e.g the web 
client. Otherwise I believe quite a few people will miss their events from 
other folders.

> If a device needs special settings, that can be defined as part of the
> device specific settings. Administration will take place over the web admin
> interface by default, Gunnar already said that this kind of structure would
> be easy to implement - in the area of one day.

There is just one potential setting we were talking about: 
hierarchical or flat syn mode.
And this is not per folder, but per device.
So it should not be in every folder otherwise you get a conflict if folder A 
says hierarchical and folder B says flat.

You would need to define the precise folder it is in and this has to exists
for stuff to work. A candidate would be the event.default folder.
If this is just one setting we are talking about, I think that using two 
different URLs could still be an option.

> The only open question is where we get the device serial number from for
> the configuration, as we do not want the user to have to enter this - in
> fact we would prefer to have a better representation of the phone than its
> serial number in the user interface, if possible.

The suggestion of the activation mode might possibly solve this for good
as well. I think of the following steps:
a) enter the right URL and setting in your phone, try to sync
b) zpush does not have any folder with the annotation thus, it will syn back 
with a welcome event or task or contact: saying: please activate your folder 
on url demo.kolab.org/activatezpush. But zpush temporarily remembers the phone 
data.

c) User goes there, get presented a selection of phones that have tried to 
sync in the past (and had the credentials).And of course all folder where 
there is access. User can now initiative the sync, which will write the 
annotation

d) next phone just syncs like the first phone by default. zpush again 
remembers the phone data.

e) User can go to the client to adjust the folder and now has the selection of 
phones,  can be disabled for folders that have been enabled before.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From greve at kolabsys.com  Fri Mar 26 22:53:55 2010
From: greve at kolabsys.com (Georg C. F. Greve)
Date: Fri, 26 Mar 2010 22:53:55 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003262118.46927.bernhard@intevation.de>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251851.09086.greve@kolabsys.com>
	<201003262118.46927.bernhard@intevation.de>
Message-ID: <201003262253.56427.greve@kolabsys.com>

On Friday 26 March 2010 21:18:46 Bernhard Reiter wrote:
> Well, if those folder contain calender data that the users needs on a daily
> basis, this user will miss them on the default sync as well.

If they have a more complex setup, then yes.

But for most people, their personal calendar is the most important and 
essential calendar they have - and the one that they almost certainly will 
want synchronised.

Building a more complicated solution that matches 0% of all user's 
expectations because the simpler approach would match only 95% of all user's 
expectations seems like a bad tradeoff.


> There is just one potential setting we were talking about:

No, this is one of several settings that enter into the whole picture.

There is the setting whether a user can use ActiveSync, at all (in LDAP).

There is the setting for the cut-off date (server default, device modified).

There is the question which folders a user wants synchronised, with the need 
for a default setting, and a need for modification of that default setting (in 
IMAP).

There is the question which device should be in flat mode, and the additional 
question where new events from the device should go WHEN a device is in flat 
mode. 

You may be right however that we need another activesync specific setting, so 
not just

	/vendor/type/activesync

but also 

	/vendor/type/activesync-devices

in the user's base folder to manage (a) which devices are known to be used by 
a particular user, and (b) which device-specific settings we have (e.g. flat 
mode, and which folder is the target for new items).


> You would need to define the precise folder it is in and this has to exists
> for stuff to work. A candidate would be the event.default folder.
> If this is just one setting we are talking about, I think that using two
> different URLs could still be an option.

Only that we have no guarantee that any folder has the ".default" annotation.

There are plenty of versions of Kontact around that remove this annotation at 
random, so we'll need to assume that for the next 5 years, we cannot rely on 
this annotation to actually exist.


> The suggestion of the activation mode might possibly solve this for good
> as well. I think of the following steps: [...]
>  folder on url demo.kolab.org/activatezpush. But zpush temporarily
>  remembers the phone data.

Of course such an intricate scenario could be made to work.

The only problem is that it fragile and the description glosses over the 
actual problem, which has been brought up before with no concrete proposals:

*Where* to remember the phones that a user has tried to connect?

It needs to go where the rest of the configuration system has access to it, so 
either LDAP or IMAP. Putting it somewhere on disk in Z-Push is just not good 
enough.

So which is your proposal? LDAP? IMAP? Where in these two?

And how is this scenario better than:

 (a) User enters details in phone, hits sync, gets default data, which is
	either the Kolab default, configured system wide by the admin, or
	the modified default by the user, with latter overriding former.

	In this step the server memorizes the phone for this user.

 (b) If the phone is a "flat mode" phone, the user will notice that (s)he is
	missing events/contacts/tasks. When looking into the web interface,
	there is a help item "What to do if some items are missing?" that
	explains flat mode and guides the user through activation.

If the phone is a phone that supports multiple folders, step (b) falls away.

Best regards,
Georg

-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Z?rich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100326/ced1afe2/attachment.bin

From alain.abbas at libertech.fr  Sat Mar 27 12:11:59 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Sat, 27 Mar 2010 12:11:59 +0100
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <201003262253.56427.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251851.09086.greve@kolabsys.com>
	<201003262118.46927.bernhard@intevation.de>
	<201003262253.56427.greve@kolabsys.com>
Message-ID: <3889C6B4-69B5-47D0-95CC-09045C726A28@libertech.fr>

hi
completely agree with you georg
we must see what want the magority of users:
my feel
95% of user want their contacts and calendars . i think those users  
woll never connect on the admin interface because they would have that  
they want

few % woulld wants shared address book
and very few other users calendars ( otjers users calendars would not  
very lisible from the flatmode)
with the case that i described we cover that

about flat or folder mode
i resolved the pb with detecting the type of the device who sync
i introduced a new define in the config file.
KOLAB_MODE
0 flatmode
1 foldermode
2 automatic
for the moment just iphone can handle the foldermode
i keep in each sync the mobiletype and the user agent who represent  
the type + the version
with that easy to choose the mode
i will make a config file to put inside with type witch mode for the  
future.

now if one user want to be in flatmode with a phone who handle  
foldermode ( the other wy has no sense)
we could put an annotation in the main inbox( because i must know the  
mode before to retrieve the folder list)

now about annotation
i read again all the posts about that an found a lot of "should work"  
and few "will work"
i want to reopen this talk because im sure that ldap can handle and  
that ther e are too questions without responses about annotation.

on LDAP with simply an auxiliary class we CAN store those parameters  
easly
1) easy to change the admin interface
2) no write rights pbs
3) this is just read very few rights
4) just one search at the login in the other case imap we must read  
the annotation at each folders , what about 2000 users ?
i know we will not have bottlenecks with LDAP

we are used to use Ldap and add some schemas in kolab to use it with  
samba or sympa or other softs and really i don t see whitch problems  
we could have.
we have lot of kolab install with a modified schemas to store  
differents metadatas without problems

the only diff with others kolab install i think that we don t store  
users in a flat tree but in a real ldap tree and we administrate it  
with our proper interface


i will push the release test monday morning with all the feature of  
the m1

Alain


Le 26 mars 2010 ? 22:53, "Georg C. F. Greve" <greve at kolabsys.com> a  
?crit :

> On Friday 26 March 2010 21:18:46 Bernhard Reiter wrote:
>> Well, if those folder contain calender data that the users needs on  
>> a daily
>> basis, this user will miss them on the default sync as well.
>
> If they have a more complex setup, then yes.
>
> But for most people, their personal calendar is the most important and
> essential calendar they have - and the one that they almost  
> certainly will
> want synchronised.
>
> Building a more complicated solution that matches 0% of all user's
> expectations because the simpler approach would match only 95% of  
> all user's
> expectations seems like a bad tradeoff.
>
>
>> There is just one potential setting we were talking about:
>
> No, this is one of several settings that enter into the whole picture.
>
> There is the setting whether a user can use ActiveSync, at all (in  
> LDAP).
>
> There is the setting for the cut-off date (server default, device  
> modified).
>
> There is the question which folders a user wants synchronised, with  
> the need
> for a default setting, and a need for modification of that default  
> setting (in
> IMAP).
>
> There is the question which device should be in flat mode, and the  
> additional
> question where new events from the device should go WHEN a device is  
> in flat
> mode.
>
> You may be right however that we need another activesync specific  
> setting, so
> not just
>
>    /vendor/type/activesync
>
> but also
>
>    /vendor/type/activesync-devices
>
> in the user's base folder to manage (a) which devices are known to  
> be used by
> a particular user, and (b) which device-specific settings we have  
> (e.g. flat
> mode, and which folder is the target for new items).
>
>
>> You would need to define the precise folder it is in and this has  
>> to exists
>> for stuff to work. A candidate would be the event.default folder.
>> If this is just one setting we are talking about, I think that  
>> using two
>> different URLs could still be an option.
>
> Only that we have no guarantee that any folder has the ".default"  
> annotation.
>
> There are plenty of versions of Kontact around that remove this  
> annotation at
> random, so we'll need to assume that for the next 5 years, we cannot  
> rely on
> this annotation to actually exist.
>
>
>> The suggestion of the activation mode might possibly solve this for  
>> good
>> as well. I think of the following steps: [...]
>> folder on url demo.kolab.org/activatezpush. But zpush temporarily
>> remembers the phone data.
>
> Of course such an intricate scenario could be made to work.
>
> The only problem is that it fragile and the description glosses over  
> the
> actual problem, which has been brought up before with no concrete  
> proposals:
>
> *Where* to remember the phones that a user has tried to connect?
>
> It needs to go where the rest of the configuration system has access  
> to it, so
> either LDAP or IMAP. Putting it somewhere on disk in Z-Push is just  
> not good
> enough.
>
> So which is your proposal? LDAP? IMAP? Where in these two?
>
> And how is this scenario better than:
>
> (a) User enters details in phone, hits sync, gets default data,  
> which is
>    either the Kolab default, configured system wide by the admin, or
>    the modified default by the user, with latter overriding former.
>
>    In this step the server memorizes the phone for this user.
>
> (b) If the phone is a "flat mode" phone, the user will notice that  
> (s)he is
>    missing events/contacts/tasks. When looking into the web interface,
>    there is a help item "What to do if some items are missing?" that
>    explains flat mode and guides the user through activation.
>
> If the phone is a phone that supports multiple folders, step (b)  
> falls away.
>
> Best regards,
> Georg
>
> -- 
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Z?rich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From alex at ap-consulting.co.uk  Sat Mar 27 16:29:36 2010
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Sat, 27 Mar 2010 15:29:36 +0000
Subject: [Kolab-devel] CVS build failures
In-Reply-To: <200912221025.01859.alex@ap-consulting.co.uk>
References: <s7wws0l5ykz.fsf@intevation.de>
	<20091222092916.308399655.thomas@intevation.de>
	<200912221025.01859.alex@ap-consulting.co.uk>
Message-ID: <201003271529.37061.alex@ap-consulting.co.uk>

While building from CVS according to the excellent directions given at
http://wiki.kolab.org/index.php/Kolab2_Beta_testing, except for using sources 
for 2.2.3, the following commands failed:

	make -e -C pear/PEAR-Auth_SASL dist
		Resolved: see 
			http://fuji.ap-consulting.co.uk/~alexp/kolab/cvs-pear-helper.patch

	make -e -C php-kolab/Kolab_Filter dist
		The build system seems somewhat confused as to the names of the files
		it's currently processing. I've been unable to work out what's going
		on here.

Should I create issues for either of these failures?

Log extracts are shown below.

Regards

Alex

--------------------------------------------------------------------------------------------------

make -e -C pear/PEAR-Auth_SASL dist
make[1]: Entering directory `/opt/koldev/CVS/server/pear/PEAR-Auth_SASL'
source ./package.info &&                               \
          cat ../../pear/pear.spec.template |                  \
          sed -e "s#[@]pear_pkgdir[@]#${pear_pkgdir}#g"       \
              -e "s#[@]pear_package[@]#${pear_package}#g"     \
              -e "s#[@]package[@]#${package}#g"               \
              -e "s#[@]package_url[@]#${package_url}#g"       \
              -e "s#[@]package_origin[@]#${package_origin}#g" \
              -e "s#[@]repo_commit[@]#${repo_commit}#g"       \
              -e "s#[@]repo_release[@]#${repo_release}#g"     \
              -e "s#[@]version[@]#${version}#g"               \
              -e "s#[@]release[@]#${release}#g"               \
              -e "s#[@]sourceurl[@]#${sourceurl}#g"           \
              -e "s#[@]php_lib_loc[@]#${php_lib_loc}#g"       \
              -e "s#[@]www_loc[@]#${www_loc}#g"               \
              -e "s#[@]summary[@]#${summary}#g"               \
              -e "s#[@]license[@]#${license}#g"               \
              -e "s#[@]buildprereq[@]#${buildprereq}#g"       \
              -e "s#[@]prereq[@]#${prereq}#g"                 \
              -e "s#[@]description[@]#${description}#g"       \
              -e "s#[@]with_chroot[@]#no#g" >      \
          PEAR-Auth_SASL.spec
/bin/sh: source: not found
make[1]: *** [PEAR-Auth_SASL.spec] Error 127
make[1]: Leaving directory `/opt/koldev/CVS/server/pear/PEAR-Auth_SASL'
make: *** [dist-pear/PEAR-Auth_SASL] Error 2

--------------------------------------------------------------------------------------------------

Full log at 
http://fuji.ap-consulting.co.uk/~alexp/kolab/install.logs/koldev-make-cvs.log

make -e -C php-kolab/Kolab_Filter dist

[snipped]

rpmtool:files: pass 1 (preparation and syntactical expansions)
rpmtool:files: pass 2 (filesystem-based expansions)
rpmtool:files: pass 3 (duplication removal and cleanup)
+ exit 0
Processing files: Kolab_Filter-0.1.8-20100122
Provides: Kolab_Filter::with_chroot = no php-kolab = 2.2.1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 
rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 
3.0.3-1
Requires: /koldev/bin/php
Obsoletes: php-kolab < 2.2.1 PEAR-Net_IMAP kolab-filter
Wrote: /koldev/RPM/PKG/Kolab_Filter-0.1.8-20100122.src.rpm
Wrote: /koldev/RPM/PKG/Kolab_Filter-0.1.8-20100122.ix86-ubuntu9.10-koldev.rpm
Executing(%clean): env -i /koldev/lib/openpkg/bash --norc --noprofile --posix -
e /koldev/RPM/TMP/rpm-tmp.97725
+ cd /koldev/RPM/TMP
+ cd Kolab_Filter-0.1.8
+ rm -rf /koldev/RPM/TMP/Kolab_Filter-0.1.8-root
+ exit 0
cd /koldev/RPM/SRC/Kolab_Filter && /koldev/bin/openpkg rpm -bs 
Kolab_Filter.spec
error: Macro %V_pear_pkgdir has empty body
error: Macro %V_repo_commit has empty body
error: Macro %V_repo_release has empty body
error: Macro %V_www_loc has empty body
Wrote: /koldev/RPM/PKG/Kolab_Filter-0.1.8-20100122.src.rpm
cp /koldev/RPM/PKG/Kolab_Filter-0.1.8-20100325.src.rpm .
cp: cannot stat `/koldev/RPM/PKG/Kolab_Filter-0.1.8-20100325.src.rpm': No such 
file or directory
make[1]: *** [Kolab_Filter-0.1.8-20100325.src.rpm] Error 1
make[1]: Leaving directory `/opt/koldev/CVS/server/php-kolab/Kolab_Filter'
make: *** [dist-php-kolab/Kolab_Filter] Error 2
[2]+  Killed


From alain.abbas at libertech.fr  Sat Mar 27 18:47:52 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Sat, 27 Mar 2010 18:47:52 +0100
Subject: [Kolab-devel] z-push milestone 1
Message-ID: <4BAE44C8.4050701@libertech.fr>

hi
SVN rev 28 is avaible for Milestone 1 for tests

Regards
Alain


From issues at kolab.org  Mon Mar 29 11:05:17 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 29 Mar 2010 09:05:17 +0000
Subject: [Kolab-devel] [issue4272] Sometimes it is not possible to delete a
	folder.
In-Reply-To: <1269853517.28.0.48156150082.issue4272@kolab.org>
Message-ID: <1269853517.28.0.48156150082.issue4272@kolab.org>


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

tested with Kontact e35 kdepim 20100326.1107649-kk1 

Sometimes it is not possible to delete a folder.

Test:
1. Create a new folder.
2. Change the name of the folder.
3. Sync.
=> The user cannot delete the folder,because the option is grayed out. 
I didn't expct this.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 24499
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Sometimes it is not possible to delete a folder.

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


From issues at kolab.org  Mon Mar 29 15:05:50 2010
From: issues at kolab.org (Martin Zapfl)
Date: Mon, 29 Mar 2010 13:05:50 +0000
Subject: [Kolab-devel] [issue4273] ISP patches: Adding a 'customer' feature
In-Reply-To: <1269867950.85.0.279230376208.issue4273@kolab.org>
Message-ID: <1269867950.85.0.279230376208.issue4273@kolab.org>


New submission from Martin Zapfl <mailinglists at tbits.net>:

In reference to issue #3463, these are the current patches for our ISP
extensions to Kolab. Notably, this adds the concept of a 'customer' which can be
used to manage other entities (domains, users, etc.) by.

As requested, these patch against the CVS HEAD, rather than a specific release.
The problem with this is that the HEAD is (as advertised in the Wiki) unstable
right now. Therefore, the modifications are only known to work when applied to
our installation (a release with the files concered merged into it from CVS).
Building a setup from scratch using only the files from CVS and incorporating
our changes into it, might or might not work, this is largely untested.

The patches are separated by CVS subtree (rather than by "partial feature").
This is because the modifications only make sense when applied as a whole.

For more details, see the README file enclosed within.

----------
files: kolab-isp-patches-2010-03-29.tar.bz2
messages: 24510
nosy: tbitsnet
priority: feature
status: chatting
title: ISP patches: Adding a 'customer' feature

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4273>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab-isp-patches-2010-03-29.tar.bz2
Type: application/x-bzip2
Size: 36526 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100329/b851fa31/kolab-isp-patches-2010-03-29.tar-0001.bin

From issues at kolab.org  Mon Mar 29 17:30:25 2010
From: issues at kolab.org (Gavin McCullagh)
Date: Mon, 29 Mar 2010 15:30:25 +0000
Subject: [Kolab-devel] [issue4274] multi-domain vhosts for kolab/horde work,
	but not without changes
In-Reply-To: <1269876625.01.0.692745401013.issue4274@kolab.org>
Message-ID: <1269876625.01.0.692745401013.issue4274@kolab.org>


New submission from Gavin McCullagh <gavin.mccullagh at gcd.ie>:

We have a number of mail domains running in kolab.

For consistency, we want to be able to send people to 
  https://mail.their.domain

In order to do so, we've created vhosts in
/kolab/etc/kolab/templates/httpd.local.template like that below for each extra
domain.

This doesn't quite work.  In order to get it to work, you need to also change 

  $conf['cookie']['domain'] = $_SERVER['SERVER_NAME'];

in /kolab/etc/kolab/templates/webclient-kolab-conf.template.

After that it seems to work fine.  It would be nice also if the webmail path
weren't hard coded:

   $conf['cookie']['path'] = '/client';

as I'd prefer to run the webmail on the root of the domain in this case.  This
is less important to us though.

Gavin

NameVirtualHost 10.1.40.173:443
<VirtualHost 172.20.1.173:443 10.1.40.173:443>
  ServerName mail.their.domain
  DocumentRoot /kolab/var/kolab/www
  ErrorLog /kolab/var/apache/log/mail.their.domain/apache-error.log
  CustomLog /kolab/var/apache/log/mail.their.domain/apache-access.log common
  SSLEngine               on  
  SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
  SSLCertificateFile     
/kolab/etc/kolab/ssl/mail.their.domain/mail.their.domain.cert
  SSLCertificateKeyFile  
/kolab/etc/kolab/ssl/mail.their.domain/mail.their.domain.key

  RewriteEngine On
  RewriteOptions inherit

  <Files ~ "\.(cgi|shtml|phtml|php4|php3?)$">
    SSLOptions +StdEnvVars
  </Files>

  <Location "/">
    ErrorDocument 403 https://mail.their.domain/client
    SSLRequireSSL
  </Location>
  <Location "/fbview">
    ErrorDocument 403 https://mail.their.domain/fbview/
    SSLRequireSSL
  </Location>
  <Location "/admin">
    SSLRequireSSL
  </Location>

  RewriteEngine On
  RewriteOptions inherit

  <Files ~ "\.(cgi|shtml|phtml|php4|php3?)$">
     SSLOptions +StdEnvVars
  </Files>

  <Directory "/kolab/var/kolab/www/cgi-bin">
     SSLOptions +StdEnvVars
  </Directory>
  
</VirtualHost>

----------
messages: 24522
nosy: gavinmc
status: unread
title: multi-domain vhosts for kolab/horde work, but not without changes

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


From issues at kolab.org  Tue Mar 30 04:36:49 2010
From: issues at kolab.org (Steffen Hansen)
Date: Tue, 30 Mar 2010 02:36:49 +0000
Subject: [Kolab-devel] [issue4275] LDAP.pm quota error
In-Reply-To: <1269916609.47.0.760941256249.issue4275@kolab.org>
Message-ID: <1269916609.47.0.760941256249.issue4275@kolab.org>


New submission from Steffen Hansen <steffen at klaralvdalens-datakonsult.se>:

I found a little typo in LDAP.pm in perl-kolab-2.2.3-20091217. Patch to fix:

--- LDAP.pm.orig        2010-03-30 04:28:50.000000000 +0200
+++ LDAP.pm     2010-03-30 04:29:17.000000000 +0200
@@ -576,7 +576,7 @@ sub createObject
     if( $quota != $oldquota ) {
         Kolab::Cyrus::setQuota($cyrus, $uid, $quota*1024, ($p eq 'sf' ? 1 : 0));
         if( $quota == 0 ) {
-            quotaDelete{$guid};
+            quotaDelete($guid);
         } else {
             quotaStore($guid, $quota);
         }

----------
keyword: server
messages: 24532
nosy: steffen
priority: bug
status: unread
title: LDAP.pm quota error

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


From issues at kolab.org  Tue Mar 30 08:47:34 2010
From: issues at kolab.org (Gunnar Wrobel)
Date: Tue, 30 Mar 2010 06:47:34 +0000
Subject: [Kolab-devel] [issue4276] Cyrus Imapd revives annotations from
	deleted folders
In-Reply-To: <1269931654.46.0.0173872908902.issue4276@kolab.org>
Message-ID: <1269931654.46.0.0173872908902.issue4276@kolab.org>


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

While testing HEAD I observed a strange effect (that misled me during testing of
kolab/issue4237).

Using the cyradm do:

cm user/foo at example.com
cm user/foo/Kalender at example.com
mboxcfg user/foo/Kalender at example.com /vendor/kolab/folder-type event.default
sam user/foo/Kalender at example.com calendar at example.com lrswipkxtecda

Now create user "foo" via the webadmin and subsequently delete the user again.

Finally go back to cyradm and issue:

cm user/foo at example.com
cm user/foo/Kalender at example.com
info user/foo/Kalender at example.com

{user/foo/Kalender at example.com}:
  condstore: false
  duplicatedeliver: false
  lastpop:  
  lastupdate: 30-Mar-2010 08:35:49 +0200
  partition: default
  pop3newuidl: true
  sharedseen: false
  size: 0
  folder-type: event.default
  ^ 
  I did not expect the "folder-type" annotation to be set. It seems to be
recreated from the state the folder had before deleting it.

This might be a problem of the annotation patch or it is something new that
crept in when the patch got merged into Cyrus Imap HEAD.

Or do I misunderstand something and this is to be expected?

I did not yet test this on 2.2.3.

----------
assignedto: thomas
keyword: server
messages: 24534
nosy: martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Cyrus Imapd revives annotations from deleted folders

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


From math.parent at gmail.com  Tue Mar 30 09:20:11 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Tue, 30 Mar 2010 09:20:11 +0200
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <3889C6B4-69B5-47D0-95CC-09045C726A28@libertech.fr>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251851.09086.greve@kolabsys.com>
	<201003262118.46927.bernhard@intevation.de>
	<201003262253.56427.greve@kolabsys.com>
	<3889C6B4-69B5-47D0-95CC-09045C726A28@libertech.fr>
Message-ID: <960738411003300020i3ab28d66vdbdd7a14cf7a5256@mail.gmail.com>

Hi,

You probably already know this, but Horde4 will include ActiveSync
support (using z-push). See http://theupstairsroom.com/100 and
http://wiki.horde.org/Project/ActiveSync

The discussion of this current thread may be related.

Regards

Mathieu Parent


From alex at ap-consulting.co.uk  Tue Mar 30 11:06:33 2010
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Tue, 30 Mar 2010 10:06:33 +0100
Subject: [Kolab-devel] Cannot create a source distribution. Was Re: CVS
	build failures
In-Reply-To: <201003271529.37061.alex@ap-consulting.co.uk>
References: <s7wws0l5ykz.fsf@intevation.de>
	<200912221025.01859.alex@ap-consulting.co.uk>
	<201003271529.37061.alex@ap-consulting.co.uk>
Message-ID: <201003301006.34083.alex@ap-consulting.co.uk>

On Saturday 27 Mar 2010 15:29:36 Alex Potter wrote:
> While building from CVS according to the excellent directions given at
> http://wiki.kolab.org/index.php/Kolab2_Beta_testing, except for using
> sources for 2.2.3, the following commands failed:
> 
> 	make -e -C pear/PEAR-Auth_SASL dist
> 		Resolved: see
> 			http://fuji.ap-consulting.co.uk/~alexp/kolab/cvs-pear-helper.patch
> 
> 	make -e -C php-kolab/Kolab_Filter dist
> 		The build system seems somewhat confused as to the names of the files
> 		it's currently processing. I've been unable to work out what's going
> 		on here.
> 
> Should I create issues for either of these failures?
> 
> Log extracts are shown below.
> 

After a `cvs update` in the early hours of this morning, the build completed 
successfully, after I'd patched pear.mk.

However, when attempting to create a source distribution using the new 
packages, according to the instructions at  
<http://wiki.kolab.org/index.php/Kolab2_Beta_testing#Creating_the_source_distribution>, 
the command `cd /kolabbuild/original && ./install-kolab.sh -S -t koldev` it  
failed with the following error: "Illegal option -S"

Has the procedure changed since the wiki was last edited?

Regards

Alex





From wrobel at pardus.de  Tue Mar 30 13:08:23 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 30 Mar 2010 13:08:23 +0200
Subject: [Kolab-devel] Cannot create a source distribution. Was Re:
	CVS	build failures
In-Reply-To: <201003301006.34083.alex@ap-consulting.co.uk>
References: <s7wws0l5ykz.fsf@intevation.de>
	<200912221025.01859.alex@ap-consulting.co.uk>
	<201003271529.37061.alex@ap-consulting.co.uk>
	<201003301006.34083.alex@ap-consulting.co.uk>
Message-ID: <20100330130823.268851dwzbwnjs00@webmail.pardus.de>

Hi,

Quoting Alex Potter <alex at ap-consulting.co.uk>:

> On Saturday 27 Mar 2010 15:29:36 Alex Potter wrote:
>> While building from CVS according to the excellent directions given at
>> http://wiki.kolab.org/index.php/Kolab2_Beta_testing, except for using
>> sources for 2.2.3, the following commands failed:
>>
>> 	make -e -C pear/PEAR-Auth_SASL dist
>> 		Resolved: see
>> 			http://fuji.ap-consulting.co.uk/~alexp/kolab/cvs-pear-helper.patch
>>
>> 	make -e -C php-kolab/Kolab_Filter dist
>> 		The build system seems somewhat confused as to the names of the files
>> 		it's currently processing. I've been unable to work out what's going
>> 		on here.
>>
>> Should I create issues for either of these failures?
>>
>> Log extracts are shown below.
>>
>
> After a `cvs update` in the early hours of this morning, the build completed
> successfully, after I'd patched pear.mk.
>
> However, when attempting to create a source distribution using the new
> packages, according to the instructions at
> <http://wiki.kolab.org/index.php/Kolab2_Beta_testing#Creating_the_source_distribution>,
> the command `cd /kolabbuild/original && ./install-kolab.sh -S -t koldev` it
> failed with the following error: "Illegal option -S"
>
> Has the procedure changed since the wiki was last edited?

Yes. In fact I should update the wiki page. I don't know if I'll get  
to this during this week though.

We tried to simplify the setup now to use a single installation  
(rather than three). Usually that should be sufficient.

Cheers,

Gunnar

>
> Regards
>
> Alex
>
>
>
>
> _______________________________________________
> 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/20100330/f8520123/attachment.bin

From wrobel at pardus.de  Tue Mar 30 13:26:16 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 30 Mar 2010 13:26:16 +0200
Subject: [Kolab-devel] zpush: name of the annotation
In-Reply-To: <960738411003300020i3ab28d66vdbdd7a14cf7a5256@mail.gmail.com>
References: <201003170904.36553.greve@kolabsys.com>
	<201003251851.09086.greve@kolabsys.com>
	<201003262118.46927.bernhard@intevation.de>
	<201003262253.56427.greve@kolabsys.com>
	<3889C6B4-69B5-47D0-95CC-09045C726A28@libertech.fr>
	<960738411003300020i3ab28d66vdbdd7a14cf7a5256@mail.gmail.com>
Message-ID: <20100330132616.12896q3ydjhrxt0k@webmail.pardus.de>

Quoting Mathieu Parent <math.parent at gmail.com>:

> Hi,
>
> You probably already know this, but Horde4 will include ActiveSync
> support (using z-push). See http://theupstairsroom.com/100 and
> http://wiki.horde.org/Project/ActiveSync
>
> The discussion of this current thread may be related.

I would say only in part. For the Kolab Server the implementation  
Alain is working on will definitely be the first implementation  
available.

If we will use the Horde 4 variant at some point is still open.

Maybe I should provide some background information:

The Z-Push code base from Zarafa is not exactly clean PHP code. It is  
better than our Kolab web admin code, it is worse than Horde code and  
it is horrible in comparison to how current PHP code can look like.  
But you can safely put that aside and simply say one thing: It works.  
And that is what counts right now.

The Horde ActiveSync project was something Micheal started during  
christmas holidays last year. He simply wanted to sync his phone,  
looked at the Z-Push code, said "oh no" and started refactoring away  
to integrate the code into Horde.

At some point I started communicating with both the guys from Zarafa  
and Michael to see if it would not be possible to find some common  
ground. Because the refactoring done by Micheal is bound to loose  
knowledge from the code build by Zarafa. While Zarafa might be able to  
benefit from the code quality improvements. This was however a dead  
end and while both sides had some interest nothing happened in the end.

The Horde_ActiveSync branch has recently been merged to the Horde  
master branch and will probably see some testing by the community in  
the future. But I assume it still takes some time until that reaches  
production quality.

So I would currently postpone any thoughts about how to deal with  
Horde_ActiveSync to a later point in time.

Cheers,

Gunnar

>
> Regards
>
> Mathieu Parent
>
> _______________________________________________
> 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/20100330/70e25013/attachment.bin

From alex at ap-consulting.co.uk  Tue Mar 30 14:11:54 2010
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Tue, 30 Mar 2010 13:11:54 +0100
Subject: [Kolab-devel]
 =?iso-8859-15?q?Cannot_create_a_source_distribution?=
 =?iso-8859-15?q?=2E_Was_Re=3A_CVS=09build_failures?=
In-Reply-To: <20100330130823.268851dwzbwnjs00@webmail.pardus.de>
References: <s7wws0l5ykz.fsf@intevation.de>
	<201003301006.34083.alex@ap-consulting.co.uk>
	<20100330130823.268851dwzbwnjs00@webmail.pardus.de>
Message-ID: <201003301311.55166.alex@ap-consulting.co.uk>

Hi Gunnar,

On Tuesday 30 Mar 2010 12:08:23 you wrote:
> We tried to simplify the setup now to use a single installation  
> (rather than three). Usually that should be sufficient.

Thanks for that. A quick ls -l in /koldev/bin confirmed that the cvs build had 
indeed updated  the installation in /koldev.

Am I correct in thinking that the initial build and the cvs build may now all 
be performed under /kolab?

Can I update the wiki, or does it have to be you?

Regards

Alex


From issues at kolab.org  Tue Mar 30 14:13:47 2010
From: issues at kolab.org (Steffen Hansen)
Date: Tue, 30 Mar 2010 12:13:47 +0000
Subject: [Kolab-devel] [issue4277] Webgui: Allow users to browse groups
In-Reply-To: <1269951227.79.0.0769504612648.issue4277@kolab.org>
Message-ID: <1269951227.79.0.0769504612648.issue4277@kolab.org>


New submission from Steffen Hansen <steffen at klaralvdalens-datakonsult.se>:

Currently there seems to be no good way for users to browse groups/distribution lists. Neither the webclient
nor kontact addressbook clients support this.

The web admin interface allows administrators to browse groups, but not regular users. Maybe this option
can be added for regular users too. Either so they can browse all groups, or at least the ones they are
member of themselves.

----------
keyword: server, web admin
messages: 24553
nosy: steffen
priority: wish
status: unread
title: Webgui: Allow users to browse groups

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


From issues at kolab.org  Tue Mar 30 14:16:59 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 30 Mar 2010 12:16:59 +0000
Subject: [Kolab-devel] [issue4278] Wish: Action to decrypt an encrypted mail
	and copy it in	the mail folder.(rt#6095)
In-Reply-To: <1269951419.8.0.486339511344.issue4278@kolab.org>
Message-ID: <1269951419.8.0.486339511344.issue4278@kolab.org>


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

tested with Kontact e35 kdepim 20100326.1107649-kk1

An action in the context menu to decrypt a mail should exists. This action
decrypts the selected mail(s) and copy it to the same mailfolder.

Test:
1. Switch to the mail component.
2. Select a encrypted mail in the mail list.
3. RMB->Decrypt and copy
4. Enter password
=> in the same folder is a copy of the mail - decrypted.

Please estimate first

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24554
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Action to decrypt an encrypted mail and copy it in the mail folder.(rt#6095)

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


From issues at kolab.org  Tue Mar 30 14:33:29 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 30 Mar 2010 12:33:29 +0000
Subject: [Kolab-devel] [issue4279] Wish: OpenPGP encrypted attachments (pgp,
	asc, gpg format) should be decrypted from the mail. (rt#6097)
In-Reply-To: <1269952409.94.0.175219213546.issue4279@kolab.org>
Message-ID: <1269952409.94.0.175219213546.issue4279@kolab.org>


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

A customer wishs for this feature:
It should be possible to encrypt an OpenPGP attachment (pgp, asc, gpg) of a mail
and open it.

Test:
1. Switch to the mail component.
2. Select a mail with gpg attachment.
3. Click on the attachment.
=> A dialog how to handle the attachment appears,
4. Choose Decrypt.
5. Enter password.
=> A dialog how to handle the decrypted attachment appears.
6. Choose Open with...(e.g. openoffice...)

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24555
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: OpenPGP encrypted attachments (pgp, asc, gpg format) should be decrypted from the mail. (rt#6097)

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


From issues at kolab.org  Tue Mar 30 14:42:33 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Tue, 30 Mar 2010 12:42:33 +0000
Subject: [Kolab-devel] [issue4280] Due time "00:00" is set for no time
	associated todos if	todo resource disabled+enabled (rt#6096)
In-Reply-To: <1269952953.67.0.408247677523.issue4280@kolab.org>
Message-ID: <1269952953.67.0.408247677523.issue4280@kolab.org>


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

Tested with enterprise35 20100326.1107649:

- activate todo resource
- create new todo (set due date only, no due time -> option "time associated" =
false)
-> todo is visible in calendar (placed in all day area)
- deactivate and activate again the todo resource
=> todo gets a new due time "00:00" (option "time associated" = true), todo is
now placed in the agenda view of previous day at 23:30-00:00h

Expected: todo shouldn't change if resource deactivate/activate

Critical for our customer.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24556
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: critical
status: unread
title: Due time "00:00" is set for no time associated todos if todo resource disabled+enabled (rt#6096)

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


From issues at kolab.org  Tue Mar 30 14:59:46 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 30 Mar 2010 12:59:46 +0000
Subject: [Kolab-devel] [issue4281] Composer: create distlist,
	for every entry a resource chooser appears.(rt#6098)
In-Reply-To: <1269953986.61.0.328549812175.issue4281@kolab.org>
Message-ID: <1269953986.61.0.328549812175.issue4281@kolab.org>


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

tested with Kontact e35 kdepim 20100326.1107649-kk1

Test:
Req: Two contacts resource folders.
1. Open a composer.
2. Enter three to: mail addresses.
3. Tools->Create distribution list.
=> For every mail address a resource chooser dialog pops up.
The customer expects just one resource chooser to appear and the contacts and
the dist list should be created in this resource folder.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24557
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: bug
status: unread
title: Composer: create distlist, for every entry a resource chooser appears.(rt#6098)

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


From issues at kolab.org  Tue Mar 30 18:06:52 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Tue, 30 Mar 2010 16:06:52 +0000
Subject: [Kolab-devel] [issue4282] Adding a new event from an invitation
	update mail shows	unnecssary message dialog 'store/throw away'
In-Reply-To: <1269965212.36.0.0916903880117.issue4282@kolab.org>
Message-ID: <1269965212.36.0.0916903880117.issue4282@kolab.org>


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

Tested with enterprise35 20100326.1107649:
- User A creates a new event, adds user B and blocks the invitation mail 
- A updates event (e.g. changes time) and send invitation update mail now to B
- B gets the update mail and clicks "Accept"

=> a message dialog comes up [see attached screenshot]
- B clicks "Store" to add event to his calendar.

This dialog is unnecessary in this case because the event isn't in B's calendar.
So, please prevent this dialog.

In all other cases: please set the default to "Store" instead of "Throw away"
(security issue).

----------
assignedto: allen
files: discard-this-update.png
keyword: enterprise35, kde client, kkc
messages: 24566
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Adding a new event from an invitation update mail shows unnecssary message dialog 'store/throw away'

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4282>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: discard-this-update.png
Type: image/png
Size: 27005 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100330/b2c1987f/discard-this-update-0001.png

From issues at kolab.org  Wed Mar 31 11:38:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 31 Mar 2010 09:38:40 +0000
Subject: [Kolab-devel] [issue4283] Reminder dialog: Task should be marked as
	solved with one	click.(rt#6102)
In-Reply-To: <1270028320.01.0.935522281388.issue4283@kolab.org>
Message-ID: <1270028320.01.0.935522281388.issue4283@kolab.org>


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

One frequent use case is to mark task as solved, when they appear in the
reminder/alarm dialog. This should be possible with just one or two clicks.

Is it possible to change the reminder dialog that todos are displayed with a
checkbox? Clicking on this checkbox should solve the todo.

Test:
1. Create a new todo with alarm.
2. Wait for the alarm.
=> The reminder dialog with the todo appear.
3. Click on the checkbox left from the todo in the reminder dialog.
=> The todo becomes solved/100%.
4. Change to the todo component and check this.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24581
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Reminder dialog: Task should be marked as solved with one click.(rt#6102)

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


From issues at kolab.org  Wed Mar 31 11:45:20 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 31 Mar 2010 09:45:20 +0000
Subject: [Kolab-devel] [issue4284] Journal: Link Add Journal entry in the
	week view is not	working (rt#6103)
In-Reply-To: <1270028720.33.0.849998406154.issue4284@kolab.org>
Message-ID: <1270028720.33.0.849998406154.issue4284@kolab.org>


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

tested with Kontact e35 kdepim 20100326.1107649-kk1

Test:
1. Select the journal component.
2. Click on a link "Add journal entry" in the week view on the right side.
=> Nothing happens. I expect a journal edit dialog to pop up.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24582
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Journal: Link Add Journal entry in the week view is not working (rt#6103)

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


From issues at kolab.org  Wed Mar 31 11:57:46 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 31 Mar 2010 09:57:46 +0000
Subject: [Kolab-devel] [issue4285] The default size of the reminder should
	be larger.	(rt#6104)
In-Reply-To: <1270029466.14.0.470621906791.issue4285@kolab.org>
Message-ID: <1270029466.14.0.470621906791.issue4285@kolab.org>


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

The reminder default size should be larger, so that no horizontal scrollbar is
displayed with events or tasks with long names.

Test:
1. Create a new event with a long name (25-40 letters) and alarm.
2. Wait for the alarm.
=> The reminder pops up.
I expect that the reminder hasn't got a horizontal scrollbar.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 24583
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: minor bug
status: unread
title: The default size of the reminder should be larger. (rt#6104)

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


From alain.abbas at libertech.fr  Wed Mar 31 12:40:14 2010
From: alain.abbas at libertech.fr (Alain Abbas)
Date: Wed, 31 Mar 2010 12:40:14 +0200
Subject: [Kolab-devel] zpush: name of the annotation Senario Proposal
In-Reply-To: <201003262253.56427.greve@kolabsys.com>
References: <201003170904.36553.greve@kolabsys.com>	<201003251851.09086.greve@kolabsys.com>	<201003262118.46927.bernhard@intevation.de>
	<201003262253.56427.greve@kolabsys.com>
Message-ID: <4BB3268E.6080806@libertech.fr>

hi

> And how is this scenario better than:
>
>  (a) User enters details in phone, hits sync, gets default data, which is
> 	either the Kolab default, configured system wide by the admin, or
> 	the modified default by the user, with latter overriding former.
>
> 	In this step the server memorizes the phone for this user.
>
>  (b) If the phone is a "flat mode" phone, the user will notice that (s)he is
> 	missing events/contacts/tasks. When looking into the web interface,
> 	there is a help item "What to do if some items are missing?" that
> 	explains flat mode and guides the user through activation.
>
> If the phone is a phone that supports multiple folders, step (b) falls away.
>
>   
The Senario that i propose to resolve the User setting
1) The User configure his phone for the synchronization and make a first 
synchro

2) the backend detect that is a new phone and maintain a list of 
SerialNumber/Device type int the INBOX annotation (Root)
in this step the USer have in his phone INBOX/* in flat or folder ( the 
backend has detected the devicetype and switched automaticly in the 
right type

3) The user if he needs something more connect on the (admin or horde ) 
interface
    the interface has the list of phones by the Annotation INBOX and the 
user could easly select it
    he could select if he want to force the mode (only for the device 
who accept the 2 modes) ( the others have no sense)
    he could define by folder (in INBOX) by exclusion and  in USER/ and 
SHARED by inclusion that he want .
    at this time the Interface put the annotation for the folder in needed

for that we need only:
an annotation in INBOX and one in the folders that except to the rule

for the format i think the better is to use the function serialize
we push a Array by serialize php function in the Activesync Annotatoion 
(or other like an LDAP attribute )
the format could be :
a php Hash with
type -> the type of the metadata (SYNC =For sync folder, SERIAL for 
store the device list , MODE = to store the mode , others ...)
Exemple  for a folder:
$meta=array();
$meta["SYNC"]["APPLX456796"]=1;
$meta["SYNC"]["ANDRO930038"]=0:
$annotation = serialize($meta);

Exemple for INBOX:
$meta["SERIAL"][0]="APPLX456796";
$meta["SERIAL"][1]="ANDRO930038";
$meta["TYPE"][0]="iphone";
$meta["TYPE"][1]="android";
$meta["MODE"]=0;

and push with serialize() php function the data in the annotation and 
read it with unserialize() function , that make the code very simple and 
extensible.
We could imagine a Class stored in the horde pear to encapsulate  these 
things

Class ActiveSyncData
public function  mode() return -1|0|1|
public function phoneList() return the array of phones
public function  folderSync($serial) return 0|1
public load($serializedString);
public getSerialized() return serialized string
....


Alain


From issues at kolab.org  Wed Mar 31 17:09:13 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Wed, 31 Mar 2010 15:09:13 +0000
Subject: [Kolab-devel] [issue4286] Agenda view shows mix of long and short
	date format	(rt#6105)
In-Reply-To: <1270048153.71.0.259586134683.issue4286@kolab.org>
Message-ID: <1270048153.71.0.259586134683.issue4286@kolab.org>


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

Tested with enterprise35 20100326.1107649:

- switch to calendar with agenda view
- select e.g. the work week
- change window width
-> date line shows mix of long and short date format - dependent  on the
selected windows width and count of selected days.
(see screenshot - here the "wednesday 14 april 2010" is to long for this window
size. Kontact shows "Wed 14" only.)

Expected: No mix. Either long or short format for all selected days.

----------
assignedto: allen
files: kontact-work-week.png
keyword: enterprise35, kde client, kkc
messages: 24597
nosy: allen, emanuel, laurent, ludwig, sergio, till, tmcguire, vkrause
priority: urgent
status: unread
title: Agenda view shows mix of long and short date format (rt#6105)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4286>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-work-week.png
Type: image/png
Size: 115688 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100331/675ecc71/kontact-work-week-0001.png

From bogus@does.not.exist.com  Thu Mar 25 17:28:28 2010
From: bogus@does.not.exist.com ()
Date: Thu, 25 Mar 2010 16:28:28 -0000
Subject: No subject
Message-ID: <mailman.8.1322660688.2136.kolab-devel@kolab.org>

importance and the storage is exchangebale.
If you think of a file storage maybe its also possible to use the current 
Kolab server file storage in Cyrus and adapt it so that both (Cyrus and your 
solution) work on the same files and you can offer the current Kolab IMAP 
thing to connect existing Kolan clients.

  </pre>
  <blockquote type="cite">
    <pre wrap="">- CardDAV / CalDAV to reach many clients
    </pre>
  </blockquote>
  <pre wrap=""><!---->
also a good idea IMO

Good luck :-)

Hendrik


[1] <a class="moz-txt-link-freetext" href="https://evolvis.org/projects/kolab-ws/">https://evolvis.org/projects/kolab-ws/</a>

  </pre>
  <blockquote type="cite">
    <pre wrap="">I'd appreciate any comments on the IMAP subject or my "restful groupware"
vision. Thank you!

[1] <a class="moz-txt-link-freetext" href="https://github.com/thkoch2001/bachelor-thesis">https://github.com/thkoch2001/bachelor-thesis</a>
[2] this link may change: <a class="moz-txt-link-freetext" href="http://thkoch2001.github.com/bachelor">http://thkoch2001.github.com/bachelor</a>-
thesis/multi/restful_groupwarese2.html
[3] <a class="moz-txt-link-freetext" href="http://code.google.com/apis/calendar/v3">http://code.google.com/apis/calendar/v3</a>

Regards,

Thomas Koch, <a class="moz-txt-link-freetext" href="http://www.koch.ro">http://www.koch.ro</a>

_______________________________________________
Kolab-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kolab-devel at kolab.org">Kolab-devel at kolab.org</a>
<a class="moz-txt-link-freetext" href="https://kolab.org/mailman/listinfo/kolab-devel">https://kolab.org/mailman/listinfo/kolab-devel</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
_______________________________________________
Kolab-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kolab-devel at kolab.org">Kolab-devel at kolab.org</a>
<a class="moz-txt-link-freetext" href="https://kolab.org/mailman/listinfo/kolab-devel">https://kolab.org/mailman/listinfo/kolab-devel</a>
  </pre>
</blockquote>
<br>
</body>
</html>