[horde] Turba LDAP Contact Lists

[Simon Wilson]

Quoting Craig White <craigwhite at azapple.com>:

> On Fri, 2009-04-24 at 19:35 +1000, Simon Wilson wrote:
>> Quoting Craig White <craigwhite at azapple.com>:
>>
>> > sorry...meant to send to list.
>> >
>> > On Fri, 2009-04-24 at 07:01 +1000, Simon Wilson wrote:
>> >
>> >> Thanks Craig... I actually have those lines at the head of
>> sources.php
>> >> (the bit I quoted was just the Shared Address Book component),
and
>> the
>> >> Contacts functionality works a treat. The problem occurs when
>> trying
>> >> to create a Contact List in LDAP as Turba doesn't present
enough
>> >> information for the requested Object Classes' mandatory
attributes
>> to
>> >> be satisfied with the config as it is - I get an objectClass
>> Violation
>> >> message.
>> > ----
>> > that of course would have much to do with your LDAP setup as it
is
>> the
>> > schema you use that has required attributes.
>> >
>> > In your case, you gave...
>> >           'objectclass' => array('top',
>> >                                  'person',
>> >                                  'organizationalPerson',
>> >                                  'inetOrgPerson',
>> >                                 'turbaContact'),
>> >
>> > and I don't use turbaContact but I know that my implementation
of
>> > OpenLDAP and 'person' states...
>> >
>> > objectclass ( 2.5.6.6 NAME 'person'
>> >         DESC 'RFC2256: a person'
>> >         SUP top STRUCTURAL
>> >         MUST ( sn $ cn )
>> >
>> > So each entry MUST have a last name and common name. As I said,
I
>> don't
>> > know your setup so I wouldn't know the requirements of top,
person,
>> > organizationalPerson, inetOrgPerson or turbaContact in your
system.
>> >
>> > YMMV
>> >
>> > Craig
>
>> My setup of OpenLDAP when it comes to schema is vanilla plus the
>> horde.schema and rfc2739.schema from Horde, and samba.schema for
samba
>> account setup.
>>
>> As you say, I am using an objectclass array of top, person,
>> organizationalperson, inetorgperson, and turbacontact. Person (and
>> organizationalperson and inetorgperson which are dependent on
Person)
>> requires cn / sn as you say.
>>
>> Sounds like my setup is functionally the same as yours, i.e. when
we
>> create a new Turba contact, LDAP *requires* sn and cn. No problems
-
>> provide those and it works fine. Got that bit working a treat.
>>
>>  From what I can see however, a Turba Contact List is
*uncreatable*
>       * with an LDAP backend in that scenario, as the Person
>         Objectclass'
>> mandatory attributes cannot be realised with the standard Contact
List
>> creation method. If you are creating Contact Lists with that array
of
>> ObjectClasses, then I'd love to know how...
>>
>> My OpenLDAP schema are standard and unmodififed, the Turba
sources.php
>> LDAP section is basically just uncommented from .dist (with the
>> TurbaContact attribute added as I am using the Horde schema
>> extensions). So I am as close to "standard" LDAP that you can get
for
>> Turba.
>>
>> Yet from what I can see it will not work in this setup. Again,
unless
>> I'm missing something obvious.
>>
>> If it's not capable of doing this in this setup, no problems, this
is
>> free software that is hugely capable, well written and easy to use
>> (and I love it), but from what I've been told when commenting it
would
>> appear to be non-operational in this setup "Of course it is, as
long
>> as both require the same set of object classes". So it would
appear
>> that I must be missing something.
>>
>> Yet I can't see how it's possible to share the same set of object
>> classes for contacts and contact lists whilst still retaining a
>> reasonable set of attributes for a Contact (i.e. Person, etc) but
>> allowing only a single name attribute for a Contact List.
>>
>> Unless there is some way to automate placing the Contact list name
in
>> BOTH cn and sn when you create a list to allow it to create? I'm
not a
>> developer, or I'd have a go... anyone offer any tips?
>>
>> Should I log an enhancement request, or am I going to crash and
burn? :)
> ----
> My thinking would be to...
>
> create another ou in LDAP for 'groups' and set up another 'source'
for
> turba that is this new groups ou and use cn for the name/memberuid
for
> their e-mail addresses. No drag and drop but should be fully
functional.
>
> Craig
>
>
Hmmm.. not a bad idea. Will give it a whirl and see how I go with  
that. Thanks Craig.


-- 
Simon Wilson
www.simonandkate.net