[Top][All Lists]

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

Re: [Phpgroupware-developers] integration of admin-addressbook-calendar-

From: Brian Johnson
Subject: Re: [Phpgroupware-developers] integration of admin-addressbook-calendar-HR
Date: Tue, 17 Jun 2003 04:56:36 +0000

I took a look at:
and couldn't understand how a company gets referenced to a person

Also, although I like the fact that you allow muliple emails, phones, etc per
person, wouldn't it be cleaner to combine those tables and have only one "type"
table and one table for those values?

Lastly, is it necessary to have creation & modification time stamps for every 
bit of

Michael Dean (address@hidden) wrote:
>On Mon, 2003-06-16 at 12:41, Alex (LEX) Borges wrote:
>> I think this is good too, i also dont see the posibility to have a
>> many-one relationship on that one. The point is, the account's backend
>> is something you may not want to go and change that lightly since it can
>> be LDAP, IMAP-SQL, SQL ... i dont know, it sounds like your position is
>> the straightforwardest, but not necesarily the simplest to implement.
>Simplest and most correct to implement in SQL to be sure.  About LDAP
>and other forms of storage, I haven't reviewed how phpGW handles those
>issues.  At least for LDAP, you should only need to be able to construct
>a DN to arrive at the user's contact info.
>> In any case, i think this is a critical feature, i think it can open so
>> many posibilities for all apps, at last, a central repository for user
>> data -all of the users data!, GROUPWARE user data, such as department,
>> phones...etc.- AND it will simplify the entry of phpgw to other's suites
>> markets that use this feature as their gratest leverage. I mean, the #1
>> bitching i get is that when MSCE Admin #1 added a user to their
>> exchange, that data was organizational and automatically deployed to all
>> apps (that is, outlook, samba access, proxy, accesible in word....etc.).
>> The simplest thing, like having the addition of users tied into putting
>> in all their organizational data (also deleting when the user is
>> deleted...etc.), will shut them up.
>The way it should be!
>> Another goal that jarg is trying to achieve is the org-person separation
>> as is in the DCL schema and as proposed in bjonsohn's entry in the
>> wikii. Im not shure weve compared them but id be delighted if bjonsohn
>> took a look into the DCL schema and tell us if it works for him.We all
>> should!
>The DCL schema link is posted in the wiki, btw - along with bjohnson's
>notes.  We have added things to the DCL schema that we identified as
>necessary for our respective companies, but also provide benefits to
>others (such as company aliases).
>> So, we are killing all birds from one shot, we just need a little bit
>> more involvement. Jarg is here to implement this features, he has the
>> time and good experience in professional development, u guys please help
>> him out.
>What's great here is the ability to share a similar schema between all
>of these different systems.  If GNUe, DCL, and phpGW can stay somewhat
>in sync (not n-sync), it will provide greater leverage for
>enterprise-level integration in the future.
>Phpgroupware-developers mailing list

Brian Johnson
* This is where my witty signature line would be if I bothered to edit this 
line :) *

reply via email to

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