Boy, its time I start digging a little deeper into Horde Permissions.   
I had _no_ idea that you could configure permissions on a source by 
source basis.  I didn't even know that a Sources option was available 
for Turba under the Permissions.    That essentially lets me create a 
small workgroup address book and just assign show/read/edit/delete to 
a few individuals or to a group.  Thats huge and I thought you had 
said in the past it couldn't be done..

The answer to that is to not give yourself (or anyone) PERMS_EDIT on 
addressbooks that aren't actually editable.

Ok - thats also much simpler and cleaner to configure - all the 
options were getting confusing - do this, but don't do that, except if 
you want to do this and two wrongs will make a right :)



I probably should have logged it as a separate issue, because I don't 
know if permissions can handle it or not.  But I still have the 
problem that if I have access to 23 address books, and all but one of 
them are "readonly" (not in the sense of the old sources.php.dist 
configuration but in the sense that I'm doing an anonymous bind, for 
example), and I try to add a New Contact, I'm still shown all 23 
addressbooks, even though I can only physically write to one.



Kind of like being handed a whole stack of floppies - all but one has 
the tab clicked so you can't write to them.  And users, being users, 
will insert each floppy and try to save their work, until they find 
the one that doesn't have the write tab moved.  I'm not sure if I'm 
being clear or not, what the remaining issue is.

I finally gave up looking at this and just removed the admin array and 
the readonly setting. Everything is done through the permissions 
system and ui now, exept for public, which is just used to say if a 
source holds one address book or many address books.

Issue 1 is that for addressbooks which are marked readonly are still 
showing up in lists where they shouldn't (i.e. New Contact).  Users 
should never see lists of addressbooks to add to that are readonly.



Issue 2 is that I misunderstood readonly and thought that it dealt 
with the state of an addressbook (i.e. a readonly LDAP directory) 
versus PERM_EDIT.  So even if you have permissions to edit, its 
physically not possible.  The Auth::isAdmin check deals only with 
permissions and doesn't take into account whether you physically can 
edit the source and I was assuming that readonly meant the latter.  So 
as the documentation stands in prefs.php.dist, its a non-issue.

I keep reading this and I can't find two distinct problems. You're 
testing this as an admin? What's the bug?

Whoops - I just read the documentation for readonly in prefs.php and 
it clearly states there that readonly means readonly, except for 
admins.  I was assuming readonly meant it was physically not possible 
to write to that addressbook (as would be the case with a LDAP 
directory addressbook which only allowed anonymous bind access, for 
searching only).



So the second issue is not a bug, at least as prefs.php spells out how 
readonly works.  The initial logging of the ticket still is an issue 
though.

Actually, I missed the return call to permissionsFilter, so I'm pretty 
sure the issue lies there.



There's a bug there too (I think):



             if (Auth::isAdmin()) {

                 return $in;

             }



should not return $in if the source is read-only (at least for a 
permission case of PERM_EDIT).

When you add a new contact to an addressbook, Turba::getAddressBooks 
is called with PERM_EDIT parameter.  However, that permission seems to 
be ignored, because the list of addressbooks you can add to that is 
returned is equal to whatever you have set for 'addressbooks'.  This 
means that one or more read-only addressbooks are being returned.   
Turba correctly returns an error when you try to save a contact in the 
read-only addressbooks but they should never be displayed as an option 
in the first place.