Timo Sirainen writes:
> On Thu, 2009-01-15 at 17:48 +0100, Sascha Wilde wrote:
>> > But should it just internally convert "owner" to "username" when
>> > replying?
>>
>> From our experience this would be a very good idea. Many clients
>> recognize the username and handle those ACLs differently i
On Thu, 2009-01-15 at 17:48 +0100, Sascha Wilde wrote:
> > But should it just internally convert "owner" to "username" when
> > replying?
>
> From our experience this would be a very good idea. Many clients
> recognize the username and handle those ACLs differently in there UI
> (for example they
Robert Schetterer writes:
> Sascha Wilde schrieb:
>> Robert Schetterer writes:
>>> Bernhard Herzog schrieb:
On 15.01.2009, Sascha Wilde wrote:
>> But should it just internally convert "owner" to "username" when
>> replying?
> From our experience this would be a very good idea. M
Hi Sascha,
Sascha Wilde schrieb:
> Robert Schetterer writes:
>> Bernhard Herzog schrieb:
>>> On 15.01.2009, Sascha Wilde wrote:
> But should it just internally convert "owner" to "username" when
> replying?
From our experience this would be a very good idea. Many clients
recogn
Robert Schetterer writes:
> Bernhard Herzog schrieb:
>> On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when
replying?
>>> From our experience this would be a very good idea. Many clients
>>> recognize the username and handle those ACLs dif
Bernhard Herzog schrieb:
> Hi all,
>
> On 15.01.2009, Sascha Wilde wrote:
>>> But should it just internally convert "owner" to "username" when
>>> replying?
>> From our experience this would be a very good idea. Many clients
>> recognize the username and handle those ACLs differently in there UI
Hi all,
On 15.01.2009, Sascha Wilde wrote:
> > But should it just internally convert "owner" to "username" when
> > replying?
>
> From our experience this would be a very good idea. Many clients
> recognize the username and handle those ACLs differently in there UI
> (for example they don't offer
Hi Timo,
Hi List,
It's been a while since our last post (talking for "the Kolab guys"
here). Sorry for that but we were very busy on various subjects -- and
Christmas, New-year and all that exhausting holidays ... ;-)
I'm very happy to see all the features needed by Kolab integrated in
1.2. Un
This is awesome Timo!
Now I guess I'll need to set up a test box to play with it some...
--
Best regards,
Charles
On Sun, 2008-11-16 at 05:09 +0200, Timo Sirainen wrote:
> BTW. Listing shared mailboxes still doesn't work. I guess we'll see
> tomorrow if I still have energy to get that done.
Initial implementation done. It still could use optimizations though.
Also it may incorrectly list users who look like t
On Nov 16, 2008, at 5:09 AM, Timo Sirainen wrote:
Any thoughts?
1. How to handle "anyone" and "authenticated"? It might be nice to let
users share mailboxes, but if they'll start spamming their mailboxes
visible to everyone it'll get really annoying and fast. So I'm
thinking about a sett
On Nov 16, 2008, at 5:09 AM, Timo Sirainen wrote:
Any thoughts?
Also: Users probably shouldn't be able to remove administrator access
from themselves in their own mailboxes? A global ACL would be able to
do that, but if there are no global ACLs I'm thinking that the admin
access would be
I just committed code for IMAP ACL support based on the code from Kolab
people. I did quite large changes though.
I also changed how global ACLs are handled. Previously local ACLs could
override global ACLs, but now that users are able to modify the ACLs I
think it should be the other way around.
13 matches
Mail list logo
