[turba] Re: Re: ldap driver editObject method and changing the "key"

[Edward Rudd]

On Tue, 17 Jun 2003 08:58:27 -0400, Chuck Hagenbuch wrote:

> Quoting Edward Rudd <eddie at omegaware.com>:
> 
>> turba 1.2 does not have this var.. Plus wounldn't I want to reset this
>> in the driver NOT the application? or should we have the application
>> research the key for the name if the name changes??? Since this is a
>> driver dependent action, which currently only the ldap will have to deal
>> with.
> 
> Ah, I assume HEAD unless people bother telling us otherwise (and don't
> assume that because you mentioned your version before that we'll remember
> - we get a *lot* of mail). Changes should be against HEAD, not the release
> version; if you send us a patch against 1.2 it'll probably be incorporated
> eventually, but it'll take us longer.
> 
NOTED.. I'll pull down the CVS and patch that as well..
> And no, the driver shouldn't be worrying about variables that the UI uses.
> 
OK.. here, maybe I should explain further what my patch is doing..
I have an entry like this...
DN: cn=Jane Doe, ou=Address Book,o=MyOrg,c=US
objectClass: top
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jane Doe
sn: Doe
mail: jane at example.com

now in Turba I'm going to rename the entry to Jane Smith. This is what the
current release of Turba does (both 1.2 AND CVS)

DN: cn=Jane Doe, ou=Address Book,o=MyOrg,c=US
objectClass: top
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jane Smith
sn: Doe
mail: jane at example.com

They rename the CN attribute.. now this works fine on OpenLDAP 2.0.x.
but on 2.1.x you have to have a CN attribute that is the SAME as the cn in
the DN:.  So what happens on 2.1.x is the name never gets changed

What my patch does is uses ldap_rename to rename the DN so it's like this.
(the rename also modifies the cn attribute)

DN: cn=Jane Smith, ou=Address Book,o=MyOrg,c=US
objectClass: top
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Jane Smith
sn: Doe
mail: jane at example.com

This is done in the setObject function of the driver.
the other turba backends (prefs, and mysql) use a unique ID as the key
which doesn't change or need to be changed when you modify the name of the
entry. Now if I put in code in the editobject.php (CVS) or
editobjectaction.php (1.2) then I would be generating a new DN for the key
if the CN changes, which I wouldn't know in there, unless I fetch info
from the ldap. And I'd be having to create a driver specific key in the
generic application interface..

would it be better to return the "new" key if it changes along the
function call path?? (store() calls setObject in source which call
setObject in driver)

or have setObject in the driver return a string if the Key changes? or
return the key through the object_id parameter, which can be changed to a
reference???

I'll post up my current patch on bugzilla (on my NEW account since my old one
still refuses to login)

> -chuck
> 
> --
> Charles Hagenbuch, <chuck at horde.org>
> The alligators were there, too, in a bathtub inside the house.