Issue 10276 - LDAP datasource cannot handle local schema extensions
Summary: LDAP datasource cannot handle local schema extensions
Status: CLOSED DUPLICATE of issue 10274
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 1.0.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Frank Schönheit
QA Contact: issues@dba
URL: n/a
Keywords:
Depends on:
Blocks: 10275
  Show dependency tree
 
Reported: 2002-12-22 18:50 UTC by miko11
Modified: 2006-05-31 14:29 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description miko11 2002-12-22 18:50:52 UTC 
In many cases, the basic LDAP objects, e. g., inetOrgPerson are extended to fit
local needs. As of today, it's not possible to use such attributes in the LDAP
datasource, and thus not in listings from LDAP sources.

This issue really ranges from the sinple, common case of extending inetOrgPerson
with a few new attributes to using completely other objects, possibly
standardised, stored in LDAP databases.
Comment 1 Frank Schönheit 2003-01-06 09:55:25 UTC 
Michael, can we agree that this is a duplicate of issue 10274? Both
bugs talk about OOo not being able to access other attributes than a
fixed set, so I really think they talk about the same problem - the
difference between "standard" inetOrgPerson attributes and attributes
which are non-standard and part of a local extension is negligible, IMO.
Comment 2 miko11 2003-01-06 17:13:32 UTC 
I have really no opinion if this this should DUP'ed with 10274. The
reason I splitted this into two bugs was that I (possibly wrong) saw a
possible strategy to first handle inetOrgPerson completely, and later
on a more full-fledged solution. This was just my idea, take it or
leave  it :-)
Comment 3 Frank Schönheit 2003-01-06 18:00:36 UTC 
> I have really no opinion if this this should DUP'ed with 10274

Okay, then I'll rely on my opinion :). Duping, 'cause I think that
solving 10274 would be 99% of solving this one here.

*** This issue has been marked as a duplicate of 10274 ***
Comment 4 michael.bemmer 2003-03-11 17:24:35 UTC 
As mentioned on the qa dev list on March 5th I will close all resolved duplicate
issues. Please see this posting for details. First step in IssueZilla is
unfortunately to set them to verified.
Comment 5 michael.bemmer 2003-03-11 17:54:46 UTC 
As mentioned on the qa dev list on March 5th I will close all resolved duplicate
issues. Please see this posting for details.
Comment 6 hans_werner67 2004-02-02 12:48:34 UTC 
change subcomponent to 'none'