[dev] [commits] Horde branch imp_6_1 updated. 06761a35f94bd0b9fc605c5cb2409875a3a5381e

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> f2fd2d8 [mms] Move folder disabling configuration into backends.php.
>>>
>>> This should be a Permission instead.
>>
>> No it shouldn't.  That is something completely different.  This is  
>> for disabling folders per *backend* (i.e. allow users to connect to  
>> only their Gmail INBOX via a Horde installation), not per *user*.
>
> We could add them as sub-permissions of backend permissions. Those  
> are missing anyway, we allow in most other multi-backend  
> applications to disable backend via permissions.

Ahh... I see what you did there.  Sort of forgot how we did this in  
other apps.  In this case -- yes, this is where we should put this  
(actually... we already have a display folder permission.  But it is  
global, not per backend, so that should be changed).

A question would be what to do about the max  
recipients/folders/timelimit permissions.  These should also probably  
be backend specific.  But this would probably be a fairly involved  
upgrade to current permissions and/or require backend changes to SQL  
storage.  (Although thinking about it... it should actually be fairly  
trivial to copy the old permissions into new backend-specific perms  
via an upgrade task.  So maybe this is not that big of a deal).

Other things that should probably be converted to permissions:

* spam reporting
   - Difficulty here would be that the spam reporting mechanism could  
potentially be different per backend.  So this backend setup should  
live in backends.php instead, which means a permission doesn't make  
much sense (configuration of features in two different locations  
doesn't seem very admin-friendly).

* fixed_folders
   - This setting never made any sense to me.  This *is* nothing more  
than removing certain ACL rights from a mailbox.  In other words, this  
is nothing more than a compatibility layer for people not running IMAP  
ACLs.  The more proper solution will be to implement a hook that  
allows manipulation of IMAP ACLs instead.  This has the benefit of 1)  
allowing any ACL right to be changed (not just rename/create) and 2)  
is just the more proper way of implementing this.  ACL syntax is more  
complicated, but we can easily provide sample code in the hook example  
to clearly indicate the basic restrictions.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]