phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] HEAD setup app


From: Ralf Becker
Subject: Re: [Phpgroupware-developers] HEAD setup app
Date: Fri, 21 Feb 2003 10:31:03 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.0.0) Gecko/20020530

Alex Borges (lex) schrieb:
not sure, that's not much detail :)

I really have no idea what would make a good contact management system, and all 
i
have are the specs for this project which are not very demanding.  I just like
making use of exsisting code whenever i can, reinventing the wheel is never any 
fun.



Well.... the only real requirement that i can gather from users so far
are:
1.- Companies -> Individuals relationship is a must
2.- True LDAP compatibility is a must.

The first meaning i should be able to browse through all the contacts of
a given organization be it through filtering...etc. That i probably
should have acl right to the contacts pertaining to a particular
organization before i can edit/delete/view contacts.
The second meaning i should be able to plug phpgw into any existing ldap
directory with person, orgperson, inetorgparson entries and to search
using phpgw as a frontend and everything should be transparent and
exactly the same as if the contacts where on sql. I should also be able
to sync with an existing ldap directory and trun its entries into phpgw
contacts.

So we can NOT change the field or the db-format of one entry containing the company as well as the personal data, as we would violate the existing LDAP-schemas. That means an approach as addbook uses, to split the company and the individual entry (normalize the db) would not work (at least not for LDAP).

As far as I see, we had to duplicate the company entries in each individual entry and change them all, if someone edits the company data of one of the entries. This is not realy a good concept, but might work if the changes are ONLY made from within phpgw and we should use this approach only in the LDAP-contacts-class and not in the SQL version.

None of that would influence the display of the contacts as many individuals belonging to one organization (as eg. addbook does it), as this can be done internaly with a query.

Maybe someone the more LDAP knowhow (knecke, ...) can comment on that.


Those are really my only priorities right now... so, this also calls for
discussion with other contact backend developers like ralph and knschke (sigh, will i ever get it right)

Lex




_______________________________________________
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]