[turba] Re: Contact Management

[Chuck Hagenbuch]

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.