[turba] Re: Contact Management

[James Tavares]

Yikes. Sorry about the multiple messages. My email client barfed....
Everytime I clicked 'Send' it would send a message AND keep the send window
open.

-James

---------------------------------------------------------
James Tavares <jtavares@loa.com>
Sr. Data Network Engineer
Log On America, Inc.

Ph: 1-401-459-6294
Fax: 1-401-459-6580
Web: http://www.loa.com/
----- Original Message -----
From: "James Tavares" <jtavares@loa.com>
To: <turba@lists.horde.org>
Sent: Thursday, April 19, 2001 10:13 AM
Subject: Re: [turba] Re: Contact Management


> I had another idea about groups in SQL (my original notion for groups in
> LDAP is still unmodfied)...
>
> Turba_RelationshipMap (
>  Parent_ID
>  Child_ID
> )
>
> Turba_Objects (
>    ...existing object table...
> )
>
> It's not unlikly that a group could need similar information as to what is
> stored in a regular object. For example, if a group represents everyone a
> local organization:
>
> Group: thatBusiness, NO TITLE, Coporate Headquarters, 300 Park Drive,
> Woonsocket, RI 02222, NO EMAIL
> Group: thatBusinessVicePresidents, NO TITLE, The VP Building, 400 Park
> Drive, Woonsocket, RI , NO EMAIL
> Contact: Jim, President of thatBusiness, 300 Park Drive (Or home address?)
> jim@thatbusiness
> Contact: Joe, Vice-President of Down Market Lay-offs etc...
> joe@thatbusiness
> Contact: Terrance, Vice-President of Some other Thing...
> terrance@thatbusiness
> Contact: Jane, COO etc...  jane@thatbusiness
>
> They do share alot of the same type of information.... Except for like
TITLE
> and EMAIL...
>
> In the relationshipMap we would see:
> ParentID    ChildID
> thatBus    Jim
> thatBvp    Joe
> thatBvp    Terrance
> thatBus    Jane
> thatBus    thatBvp
>
> Such that, mail to each individual contact will is a normal expansion.
Email
> to "thatBusinessVp" will go to JOE and TERRANCE, that VPs, and
> "thatBusiness" will go to JIM, JANE, and the group "thatBusinessVP" which
> contains JOE and TERRANCE.
>
> Of course, the table would be based on the ID and not their names, but,
you
> get the idea.
>
> I guess there is no reason why a group couldn't have its own email address
> either. It would just be included in the list of email addresses that the
> group name expands too. Groups have phone numbers, fax numbers, addresses,
> and notes... Just like people do.
>
> It's all just an idea... This all would fit just fine with my LDAP
> definitions in my previous email as well, since there was only one tree
> (cn=OBJECTID, ou=username@domain, o=myOrg  --OR--  cn=OBJECTID,
ou=objects,
> o=myOrg with an ownerID: attribute in each entry) for all objects.. An
> object that is currently a contact could at any time be turned into a
group
> as well.
>
> Let me know.
> -James
>
> ----- Original Message -----
> From: "Chuck Hagenbuch" <chuck@horde.org>
> To: <turba@lists.horde.org>
> Sent: Wednesday, April 18, 2001 5:32 PM
> Subject: Re: [turba] Re: Contact Management
>
>
> > Quoting James Tavares <jtavares@loa.com>:
> >
> > > I'd like to move progess along on turba's group support. It's
important
> to
> > > me (I hacked it into 2.2.4 in the worst way.)
> >
> > Great! :)
> >
> > > I'd like to make one suggestion...If I'm to code this, I'd like to add
a
> > > table so as I could support Groups within Groups.. Basically:
> > >
> > > CREATE TABLE Turba_Groups_Groups (
> > >     parent_grID varchar(32) NOT NULL,
> > >     child_grID varchar(32) NOT NULL
> > > );
> >
> > Sure - or we could just add a object_type field to Turba_Groups, so:
> >
> > Turba_Groups {
> >   group_id,
> >   owner_id,
> >   object_id,
> >   object_type
> > }
> >
> > (groups _are_ objects, after all).
> >
> > > What is the contents of object_ID and owner_ID?
> >
> > object_ID is just a unique identifier - it's the "key" field for the
> object
> > (like DN is in LDAP). owner_ID is the Horde username of the person who
> owns
> > that object.
> >
> > > Do you guys have any reservations about using Auto Increment columns?
> > > Personally, I think they would make perfect _ID's to link all these
> > > tables.....
> >
> > Yes: they are rather specific to mysql. We can use PEAR's sequences if
> > necessary. Also, try not to think too specifically to sql; LDAP isn't a
> clear
> > fit for groups, but it should be possible to have dbm-based groups, for
> example.
> >
> > Speaking of which, it seems like it might make sense to have a seperate
> > Turba_GroupDriver:: hierarchy, since there's no particular reason to say
> that
> > they have to be stored in the same place as the actual contacts (and
since
> LDAP
> > groups seem a bit hairy, it'd be nice to let people make groups of LDAP
> > contacts). So that gets us to:
> >
> > Turba_Groups {
> >   group_ID,
> >   owner_ID,
> >   object_ID,
> >   object_Type,
> >   object_Source
> > }
> >
> > ... for SQL, anyway.
> >
> > -chuck
> >
> > --
> > Charles Hagenbuch, <chuck@horde.org>
> >
> > Taurus:
> > You will receive an urgent transmission from the Martian government
> informing
> > you that Mars does not, in fact, need women, so please stop sending
them.
> >
> > --
> > Turba mailing list: http://horde.org/turba/
> > Frequently Asked Questions: http://horde.org/faq/
> > To unsubscribe, mail: turba-unsubscribe@lists.horde.org
> >
> >
>
>
> --
> Turba mailing list: http://horde.org/turba/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: turba-unsubscribe@lists.horde.org
>
>