[Kolab-devel] Thunderbird - SyncKolab 2.0.0 - Looking for Testers

[Niko Berger]

Quoting Geoff Nordli <geoffn at gnaa.net>:

> On 12-05-22 03:58 PM, Niko Berger wrote:
>> Hi,
>>
>> I wanted to announce a major release of the thunderbird extension that
>> sync contacts and lightning (calendar/todo) with kolab.
>>
>> I refactored most of the addon (especially configuration, but also
>> other things).
>>
>> It would be a huge help if some people could do a test with the
>> current nightly (found on
>> http://www.gargan.org/en/Mozilla_Extensions/SyncKolab/CVS_Nightly/ ).
>> I was able to fix all issues which popped up until now, but would like
>> to have more thorough testing. If you find anything please report on
>> http://synckolab.mozdev.org/bugs.html so I can fix it.
>>
>> Thanks
>>
>> Niko
>>
>> Ps.: to be on the safe side you should make a backup or select
>> non-critical folders. It seems to be stable - but you never know :)
>>
>> __
>
> Hi Niko.
>
> Everything checked out here OK.
>
> One question, in the 2.0 version do you need to create a separate
> profile for the calendar, tasks and contacts?
>
> I seem to remember in previous versions a single profile covered all of
> the different components.
>
> thanks for your efforts on this.  It is great option to be able to use
> Thunderbird as client for Kolab.
>
> Geoff
>
>
>

Hi Geoff,

Very good to hear some positive responses :)

About the config: yes, in 2.0 I changed the configuration layout  
around. This was mainly due to the requirement that you often have one  
email account but multiple address books, and i.e. only one todo.  
Until now to accomplish this configuration you had to create loads of  
extra configs, but in each disable parts of it. It basically was a  
little hard to manage.

With the new way, I don't need the wizard any more and the  
configuration is easier to handle.


This is from an email I received:

Typically, people have

         <n> Kolab servers, on each of which they have
                 <m>        Calendars
                 <i>                Address books
                 <j>                Task lists

In professional scenarios, <n> can easily be 3 or more.

Most times, <n> may be one, but in any case it is very unusual that

<m> == <i> == <j>

so people will often have

         3 Calendars
         4 Address books
         5 Task lists

where the shared objects will have little to no correlation with each other,
e.g.

         My own calendar
         The event calendar of the company
         The calendar of my colleague

         My own address book
         The address book for customers
         The address book for sales
         The address book for partners

         My own task list
         The task list of SSL certificates that need renewing
         The task list of customer X
         The task list of customer Y
         The task list of customer Z

These are not easily logically associated across categories, so one would be
adding 12 "configurations", one for each case/type, where typically the Kolab
concept sees this as one configuration for this server, with 3 calendars, 4
address books, 5 task lists.