[dev] [PATCH] for Ticket #2: Postal Address Format Schema
Edward Rudd
eddie at omegaware.com
Wed Feb 9 15:45:48 PST 2005
I would like to open some discussion on this patch and work out any
details that need to be finished so it can be merged into the CVS HEAD.
Currently the lastest patch (posted 1/14/05) checks the
$GLOBALS['attributes'] config array for the element to be saved and checks
if it is an address type. If it is, it correctly converts all new line
characters to a '$' for storing into the backend LDAP directory. This
solution will work so long as users only specify attributes to be
addresses which are addresses in the backend LDAP.
What I currently am not doing in the patch is using the code added in
turba/lib/Drivers/ldap.php rev 1.50 which is the support to use the
Net_LDAP class from PEAR. I have several reasons for not adding it in
there currently.. One, is Net_LDAP is still beta quality and is not
officially released. Two, is the mechanism for searching the OIDs is
disabled by default in the turba configuration and has to be explicitly
enabled (the checkRequired attribute), And three, you can't trust
(unfortunately) that an LDAP server will provide SCHEMA information..
Now, I do have an _isPostalAddress that will check that schema data, I
just haven't tracked through of how to get horde to initialize it yet, and
the current fix works. Once I finish the schema checking I will post a
patch up here, but the current solution should still be added in as a
failback in case the user does not have the 3 requiredments to use the
schema checking (Beta Net_LDAP installed, the checkRequired enabled, and
an LDAP server that properly publishes the SCHEMA).
Any comments, or corrections on anything above please to reply back. I've
been carrying this patch for Turba since summer of 2003 (Turba 1.2
days: Subject multilin entry patch on turba list) trying to get it
committed and would like to see a fix get into the Turba.
Regards,
Edward Rudd
More information about the dev
mailing list