[turba] Contact in this list that is not viewable to you - related.

Tue Apr 20 11:05:10 UTC 2010

Zitat von ANANT S ATHAVALE <asa at isac.gov.in>:

> ----- Message from jan at horde.org ---------
>     Date: Sun, 18 Apr 2010 14:14:17 +0200
>     From: Jan Schneider <jan at horde.org>
>  Subject: Re: [turba] Contact in this list that is not viewable to  
> you - related.
>       To: turba at lists.horde.org
>
>
>> Zitat von ANANT S ATHAVALE <asa at isac.gov.in>:
>>
>>> ----- Message from jan at horde.org ---------
>>>  Date: Tue, 13 Apr 2010 14:20:33 +0200
>>>  From: Jan Schneider <jan at horde.org>
>>> Subject: Re: [turba] Contact in this list that is not viewable to  
>>> you - related.
>>>    To: turba at lists.horde.org
>>>
>>>
>>>> Zitat von ANANT S ATHAVALE <asa at isac.gov.in>:
>>>>
>>>>> ----- Message from jan at horde.org ---------
>>>>> Date: Tue, 13 Apr 2010 12:21:24 +0200
>>>>> From: Jan Schneider <jan at horde.org>
>>>>> Subject: Re: [turba] Contact in this list that is not viewable  
>>>>> to  you - related.
>>>>>  To: turba at lists.horde.org
>>>>>
>>>>>
>>>>>> Zitat von ANANT S ATHAVALE <asa at isac.gov.in>:
>>>>>>
>>>>>>> ----- Message from jan at horde.org ---------
>>>>>>> Date: Tue, 13 Apr 2010 11:37:46 +0200
>>>>>>> From: Jan Schneider <jan at horde.org>
>>>>>>> Subject: Re: [turba] Contact in this list that is not viewable  
>>>>>>> to  you - related.
>>>>>>> To: turba at lists.horde.org
>>>>>>>
>>>>>>>
>>>>>>>> Zitat von ANANT S ATHAVALE <asa at isac.gov.in>:
>>>>>>>>
>>>>>>>>> Dear List,
>>>>>>>>>
>>>>>>>>> My users were complaining of the problem as mentioned in the subject.
>>>>>>>>>
>>>>>>>>> We have set up a global address book with LDAP.  I was  
>>>>>>>>> advising  users to create contact lists of their own by  
>>>>>>>>> searching for  persons from LDAP address book and adding to  
>>>>>>>>> their contact lists.   And most of the users are using this  
>>>>>>>>> feature.
>>>>>>>>>
>>>>>>>>> Now, users started complaining that for many lists which  
>>>>>>>>> they  created, they get the message "There is/are xx contact  
>>>>>>>>> in this  list that is not viewable to you".
>>>>>>>>>
>>>>>>>>> Now, I tried to debug the problem and now I know the problem.
>>>>>>>>>
>>>>>>>>> Whenever a user searches from LDAP address book and adds the  
>>>>>>>>>  person to his contact list, the address book  
>>>>>>>>> "turba_objects"  instead of adding just the name and email  
>>>>>>>>> id of the searched  person, also stores the LDAP hierarchy  
>>>>>>>>> "ou, ou", etc of that  person.  Everything is OK till the  
>>>>>>>>> hierarchy of that person  remains the same.  If the person's  
>>>>>>>>>  hierarchy in LDAP gets  changed,   the users are getting  
>>>>>>>>> the above error/warning.
>>>>>>>>>
>>>>>>>>> How to come out of this problem?
>>>>>>>>
>>>>>>>> If the users are the owners of the list, any contacts of this  
>>>>>>>> list  that can't be found anymore are deleted automatically.
>>>>>>>
>>>>>>> Users are owners of the list.  The contacts remain in LDAP,  
>>>>>>> but not  at the same hierarchy.  Ie. The hierarchy which  
>>>>>>> existed at the time  of creation of contact list is now  
>>>>>>> different.
>>>>>>
>>>>>> This doesn't make a difference for the code. The contact can't  
>>>>>> be  found anymore, so it's being removed.
>>>>>>
>>>>>>>> If the user does not have write permissions on the list, they  
>>>>>>>> will  get this error message, until the list was opened by  
>>>>>>>> the admin.
>>>>>>>
>>>>>>> User has write permission on the list.
>>>>>>>
>>>>>>> Is it required that, when storing a contact after a search  
>>>>>>> from  LDAP directory, to also to store the LDAP hierarchy?   
>>>>>>> Can it not be  done without storing hierarchy?  In our  
>>>>>>> organisational setup, we  have frequent changes in Hierarchy  
>>>>>>> of a person which get reflected  in LDAP.
>>>>>>
>>>>>> Completely depends on how you set up Turba. But with the  
>>>>>> default  LDAP setup, you use the DN for the contact key, which  
>>>>>> contains the  full hierarchy.
>>>>>
>>>>> OK.  We were using the DN for the contact key, which is the  
>>>>> default  one.  Now, I have in my setup of LDAP, attribute named   
>>>>> 'mailacceptinggeneralid' gives the unique output.  I am  
>>>>> attaching the  current ldap related entries in sources.php.  I  
>>>>> tried changing __key  alone to 'mailacceptinggeneralid'. With  
>>>>> this change, contacts are not  getting shown in contact list,  
>>>>> though it says it added.
>>>>>
>>>>> Any more changes required?
>>>>
>>>> No, that's sufficient. Of course it would only work with new lists.
>>>
>>> I tried again.  Changing __key alone to 'mailacceptinggeneralid',  
>>> and creating new contact list with contacts, it says added. But  
>>> does not show up when I try to see the members of a list.
>>>
>>> Another problem is, after changing the __key, the old lists  
>>> created do not show up the contacts.  I am ready to accept this.   
>>> But, at least new lists I should be able to create with  
>>> 'mailacceptinggeneralid' as the attribute of LDAP assigned to __key.
>>>
>>> Any more pointers?
>>
>> Check your logs.
>
> 1. I have enabled debug_level to E_ALL and logging level to PEAR_LOG_DEBUG
> 2. No error while adding contact to a contact list.  But  
> object_members of turba_objects is stored with null value.
> 3. But, listing contents of a list, gives the following error in php.err.log
>
> PHP Notice:  unserialize() [<a  
> href='function.unserialize'>function.unserialize</a>]: Argument is  
> not a string in /home/horde/turba/lib/Object/Group.php on line 169
>
> I think, this is because, the object_members has NULL value stored.
>
> So, still I am unable to use __key with 'mailacceptinggeneralid' as  
> the LDAP attribute.
>
> Just want to know, are the following lines in sources.php w.r.t.  
> LDAP are related and what way I need to change them to make use of  
> 'mailacceptinggeneralid' an attribute defined in LDAP as the key.
>
> 1. 'dn' => array('cn'),  (under params)
> 2. '__key' => 'dn', (under maps)
> 3.     'strict' => array(
>         'dn',
>
> These are the three places where dn is referred.

Looks good to me. Someone else, who is actually using the LDAP driver  
with groups should chime in here.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/