[Tickets #5960] Re: Automatic creation of default shares leads to creation of unwanted personal address books.

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://dev.horde.org/horde/whups/ticket/?id=5960
-----------------------------------------------------------------------
 Ticket             | 5960
 Updated By         | Michael Rubinsky <mrubinsk at horde.org>
 Summary            | Automatic creation of default shares leads to creation of unwanted
                    | personal address books.
 Queue              | Turba
 Version            | 2.2-RC1
 Type               | Bug
 State              | Feedback
 Priority           | 2. Medium
 Owners             | Michael Rubinsky
-----------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2007-12-06 07:18) wrote:

> With your respect, I do not think that the goal of the code is to 
> create useless and redundant address books 

They may be useless and redundant on *your* installation...

> but I understand that it 
> is essential to create a personal address book for each user on one 
> (and I think only one) shared source when the administrator did not 
> define a not shared source.

Just because there is a "not shared" source doesn't necessarily mean that
it should be treated as the user's one and only personal, address book.

>> Why not use the same source for all the address books?  Each user will
>> have his/her own personal address book, and the admins can still
create
>> additional address books as they do now.
>
> I am not favorable to this solution for several reasons
>
> I think that the personal address books, containing private data,  
> should not be shared nor even shareable.

Well, that's your prerogative and is certainly reasonable.  FYI, Horde 3.2
and Turba 2.2 will allow you to disallow users from setting permissions on
their shares.

> This solution makes unusable the not shared source, since a shared 
> source exists, and requires to use a script to transform the address 
> books of all the users existing on the not shared source into address 
> books on the shared source (I do not think that this script - who 
> would however be essential for this handling - already exists).

I don't see why you shouldn't be able to just copy the records from one
table to the other without any problems, assuming both tables have the same
structure. Otherwise, yea, your right, you would need a script to map the
fields of one to the other.

>
> I prefer to maintain the address book of the company which is 
> generated automatically on a distinct table corresponding to a 
> distinct shared  source on which the users cannot create address book

That's reasonable. 

> To lock this parameter would be a degraded solution because I wish 
> nevertheless to allow the users to create shared address books

Any address book that is created either automatically, or by the user,
will automatically be appended to this pref.  It is up to the user to
remove it if he/she desires.

...but this leads me to another question.  You say above that you want
your users to be *able* to create and share address books, yet you set the
backend that contains the users' address books to *not* use shares...and
you stated that you don't want the users to be able to create any address
books in the same table as the company address book - which is the one you
enabled shares on. So, my question is - where are the users going to create
the new address books?  After you decide which source will contain them,
you must put that value into the $conf['shares']['source'] setting.  If you
decide to put them in 'localsql' then they will also be able to share the
"default" personal address book as well.

Another option would have been for you to create the company address book
as not share enabled and use the permission system to make it public or
whatever.