Re: [Evolution-hackers] LDAP write support (was: Old thoughts on the "self" contact)

[Chris Toshok <toshok ximian com>]

On Sat, 2004-02-28 at 22:10, Craig Ringer wrote:
> On Sun, 2004-02-29 at 03:06, Chris Toshok wrote:
> > On Sat, 2004-02-28 at 03:53, Craig Ringer wrote:
> > > On Sun, 2004-02-22 at 08:22, Chris Toshok wrote:
> > > 
> > > > You can still rm the file/directory, but e-d-s shouldn't allow the
> > > > deletion of the calendar/addressbook.  I mean, why would you ever want
> > > > to?
> > > 
> > > If you used contacts stored server-side, such as a read/write LDAP
> > > directory. Evolution doesn't support writing to LDAP at present.
> > 
> > sure it does.  It has for...  almost 4 years.
> 
> Indeed. Sure enough, it works a treat. Unfortunately, I've _never_ heard
> the feature mentioned, and the documentation explicitly denies it's
> existence (at least in 1.4.5 on FC1): 
> 
> >From the help menu, under "Getting Started with Ximian Evolution" ->
> "Working with your Contacts":
> ---
> 5.4. LDAP: Shared Addressbooks on a Network
> [...]
> You cannot add, delete, or alter cards on the LDAP server. If you need
> to change information there, you will need to speak to your system
> administrator 
> ---
> Perhaps this could use updating. I saw several bugs in bugzilla reported
> by people who didn't realise that LDAP write was supported.

Ugh, yeah that's not good.

> Also, I have noticed one issue with the LDAP writes support that I
> thought worth mentioning (though I haven't yet tested with 1.5.x).
> 
> When adding a contact to the LDAP directory, if the contact does not
> meet the schema requirements (eg no sn for inetOrgPerson because the
> contact has only one word in the name), evolution reports the error:
> "Error adding card: Other error". If I look at a tcpdump of the
> communication with the LDAP server, the LDAP server has reported:
> 	object class 'person' requires attribute 'sn'
> ... but evolution does not pass that information on to the user in
> either a raw form or a translated form like "Sorry, you need to include
> a surname".
>
> Hmm... a bugzilla search turned up these bugs:
> http://bugzilla.ximian.com/show_bug.cgi?id=45565
> covers the issue to some extent, as well as the extremely clear:
> http://bugzilla.ximian.com/show_bug.cgi?id=31021
> 
> so I guess that's covered already. 

Unfortunately it's not this easy..  We can always hardcode those two (cn
and sn) attributes and check for their absence explicitly (as is
mentioned in one of the bug reports) and return a better status message,
but LDAP admins are free to make other requirements of their entries..

A more flexible and IMO more correct solution would be to communicate to
the front end the fields that are required before a contact can be
stored by a particular backend.  We already have an idl call
"getSupportedFields" which returns the fields that backend supports at
all (so we can gray out entries in the contact editor.)  We could
augment (and rename) it so that it returns both the list of supported
fields as well as the list of required fields.

Then the contact editor could take care of everything for us.  It would
also allow us to do things like force an addressbook to be read-only if
a server-required attribute doesn't map to an evolution-supported
attribute.

In any event, a plan that never seems to make it to fruition is to add a
message arg to the listener idl methods so they can communicate more
information back to the front end.

> This of course, begs the question of how "company" contacts should be
> handled, where there may be no "contact person". Think "MyISP Technical
> Support". A company name can't really be broken up into first and last
> names - especially when it's a one-word name. That aside, I'd consider
> it undesirable to see "Network Solutions Inc" come out as "Inc, Network
> Solutions" in the address book anyway. I don't have a clue what the
> answer to that one is, but thought I'd bring it up as something that'll
> probably need addressing sooner or later.

If you've installed the evolutionperson.schema, you'll have write access
to the "File As" field, and can set it to be whatever you want.

Chris