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

[Jan Schneider]

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

Agreed for folders permissions. Recpient/timelimit permissions still  
make sense as global permissions, they are mainly for spammer  
protection and not really tied to backends.

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

Agreed.

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

This is from a time where we didn't reflect ACLs in the UI yet. It  
makes sense to remove it in favor of ACLs in the next version.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/