Re: [Phpgroupware-developers] Addbook vs addressbook

[Ralf Becker]

Brian Johnson schrieb:
> I understand that one potential complication of separating the companies from 
> the
> individuals in the table format is that it makes the addressbook app harder to 
> work
> with those using LDAP
>
> I understand that the current LDAP design in addressbook is made to match a LDAP
> standard for the storage of contact information
>
> In my thinking, we have three options:
> 1. stick with what is done (in which case I'll continue work on addbook)
> 2. try to get a new LDAP contact standard adopted and wait until that's done 
> (see
> next paragraph)
> 3. create a system that utilizes a different database structure than the LDAP
> structure and have the code adjust for the different formats
>
> I think 2. would be a huge delay - trying to get 100s or 1000s of people to 
> agree
> on a new format.  Also, in my limited understanding of LDAP, it is not a 
> relational
> structure and it might be impossible to separate the companies from the people 
> and
> maintain a relationship between the data (which would of course prevent the
> adoption of a LDAP contact standard format to do this)

I have the same Opinion on that.

The only accepted schema for now is the inetOrgPerson and only that is 
visible in stock LDAP clients like e.g. the mozilla addressbook. 
inetOrgPerson is basicly the data of a Person including *one* address, 
phone, fax, mobile, private phone, email, url and a companyname.

What I already suggested is in line with your next proposition:
I propose to use in LDAP:
- a schema based on the inetOrgPerson (that means all that fields plus 
some own)
- two inetOrgPerson record/node for each person in an organisation:
1) with its private data linked to the other one by its cn (common 
name), uid (user-id) or an other id outside the inetOrgPerson schema.
2) with its org-data linked to it's organisation by the organisations 
name. That record dublicates/mirrors the company address, and the 
persons names (readonly from stock LDAP clients). It's only genuine data 
is phone, fax, mobile, email, url.
- the cn of the privat address should include a '(privat)', so u see the 
difference between the two in a stock LDAP client
- we use an other inetOrgPerson (or other schema) record/node for the 
organisation itself, includeing its address, central phone, fax.
- the linking of this 3 is done by unique org- and person-id's. These 
id's are either readonly or outside the inetOrgPerson schema (in an own 
schema, which includes / is based on the inetOrgPerson schema). I would 
prefer the last, as this would allow read/write access for other clients.

Why would we need up to 2 inetOrgPerson for one person?
- else your are not able to select private AND buisness mail, phone, 
fax, address in a stock client

The phpgw GUI / addressbook (and the (new) api-contacts-class) will mix 
these speparate nodes and display them in a way addbook does it today:
1) org's containing several persons
2) persons contained in zero or one org
3) the contacts-id (which is needed from the api contacts class, is 
either the org-id or the person-id, which both together have to be unique.

The database/table-structure could be the one of addbook, maybe with 
some modifications: inetOrgPerson has some more fields we dont use at 
the moment, which might be interesting to have eg. secretary and manager

Like brian said: what do you think about that proposition?

Ralf

> I suggest we proceed with the concept of modifying the addressbook database
> structure to better normalize the data including separating the companies and 
> the
> people into separate tables.
>
> So what do you guys think?  Can we start talking about a new database structure 
> for
> the addressbook and the corresponding changes to the web forms?
>
>
> Dr. Michael Meskes (address@hidden) wrote:
>
> > On Mon, Mar 03, 2003 at 09:00:27PM +0000, Brian Johnson wrote:
> >
> > > > field-structur like the addressbook has it know and only change the UI
> > > > to keep the org-fields in sync with the org-fields of the other persons
> > > > in that org. That is not the cleanest approach (Michael Meskes would say
> > > > the db is not normalized) but it is far better than the other ideas
> > Hey, and what shall I say now? :-)
> >
> > Fact is you have several advantages by normalizing the data. But you
> > can, of course, reimplement the logic inside the GUI. If it was only for
> > the database I wouldn't do that, but I do not have enough ldap knowledge
> > to say if we could get this going with normalized data.
> >
> >
> > > time entries for testing purposes but I need to create better filtering and
> > > searching abilities in addbook before other switch to it (and I add our 3000+-
> >
> > I agree completely.
> >
> > Michael
> >
> > P.S.: Also CCed to Carsten who takes care of our phpgw installation,
> > although he's on vacation right now.
> > Email: address@hidden
> >
> >
> > _______________________________________________
> > Phpgroupware-developers mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>
>
>
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers



--
----------------------------------------------------------------------
Ralf Becker
OUTDOOR UNLIMITED Training GmbH                Telefon 0631 / 31657-0
Leibnizstraße 17                               Telefax 0631 / 31657-26
D-67663 Kaiserslautern            EMail address@hidden