Re: [Phpgroupware-developers] addressbook model and integration with accounts

[Dave Hall]

Brian Johnson <address@hidden> wrote:

> I see we've thrown both the dcl schema and the addbook schema out 
> the window
> 

Well kinda, i started thinking about the model a lot.  I saw bits i like
from several sources, including phpgw contacts, dcl, addbook, irc
discussions, and my own thoughts.  This model is designed to be a group
contacts system, which includes and addressbook, some crm functions, the
ability to incorporate better communication from within phpgw.

> Should the table names start with something like phpgw_ab_ so they 
> are all grouped
> together in a table listing of the db?

This is a valid point - I am not in favour of using ab, I think contact
or contacts would be better and the person related tables are called
phpgw_contact_person_* and orgs phpgw_contact_org_* and the general
phpgw_contact_*.  A few more key strokes when coding, but acheives the
same end.

> 
> if org_id in phpgw_org and person_id in phpgw_person where non-
> sequential primary
> keys, they could be linked directly to contact_id in 
> phpgw_contacts and then the
> other tables could be linked directly to phpgw_org and 
> phpgw_person.  This is what
> addbook does and allows your SQL selects to often omit querying 
> the phpgw_contacts
> table entirely.
> 
> what is contact_type_id in phpgw_contacts and it's related table?  
> it looks like a
> second category system

This is how we differentiate person, org and system user records apart.
  This also allows future record types to be added - I have no idea what
these would be ... be allows such expansion later. 

> 
> if we're looking at a phpgw only schema, then should we omit the 
> notes tables and
> just have links to infolog records?

Yes, I never liked the notes table, but it was kept cos there was some
support for it, I am happy to see it go.  Maybe keeping a single TEXT
field would allow basic notes to be attached to a record, for those who
do not use infolog.

> 
> please realize that this type of category linking will not be the 
> standard that all
> other apps use

All apps should use a 1:n (single field) relationship or a n:n (2 table)
relationship.  Serialising keys into a varchar field is bad practice.

> 
> don't forget to show the relationships to phpgw_links as used by
> infolog/inc/class.solink.inc.php

I think Ralf is working on a API proposal for this.  If this happens
then it should be included.  If not then it is outside of the API and so
I don't think should be shown in this model.  For example many apps use
the current contacts data, these are not shown in the model.

> 
> could someone explain to me the comm system again?  I still don't 
> understand why we
> need three tables there.  Shouldn't two tables be sufficient?
> 

Ok, here goes.

phpgw_contacts_comm
holds the actual communication data:
phone#, 
fax#, 
mobile#, 
email address, 
url/uri,
pager#, 
IM info, 
etc etc
includes some future proofing
For each comm_type_descr_id a preferred could be set where there are
multiple entries - such home email or whatever

phpgw_contacts_comm_descr
holds the actual descriptions of that communication type:
Work Phone
Home Phone
Mobile/Cell Phone
Fax
Work Email
Home Email
Pager
Jabber
AIM
Website
etc

phpgw_contacts_comm_type
holds the information about each type of communication technology
initially I see these including:
Landline Phone
Mobile Phone (because of sms)
Fax
Email
URI
IM

The class field is for some new contacts_comm_* classes.  These classes
would hold several methods:
validate($val) - used for validating the input
can_send() - returns bool 
return_uri($comm_type_id) - for making links from data ie mailto: or
linking to phpgw apps/tools for handling these types.
send($comm_type_id, $msg)

Note different phone types would extend a base phone class.

These classes would be configured in an admin option - communication. 
Setting basic info about the servers - ie email servers, sms gateway,
fax, jabber info and if someone develops something to allow php to talk
to Bayonne (http://www.gnu.org/software/bayonne/index.html) we can use
that too.  There would also be user prefs to support these changes too.
 This data could then be used by the alarm management tool in calendar
or the brute force protection notification.

The active flag is so a system admin can allow or disallow these
communication types from being entered.

I hope I have explained this clearly.  This is concept which is still
buzzing around my head.  I hope to have something on the communication
concept on the wiki in the next week.  This is part of my holiday coding
activity.

Cheers

Dave

> 
> Jonathan Rivera (address@hidden) wrote:
> >
> >hi guys,
> >
> >finally between skwashd and i finished the model for the 
> integration of
> >admin with addressbook, here can see it .
> >
> >
> >http://co.com.mx/~jar
> >
> >
> >regards.
> >
> >
> >
> >
> >_______________________________________________
> >Phpgroupware-developers mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> >
> 
> --
> Brian Johnson
> * This is where my witty signature line would be if I bothered to 
> edit this line :) *
> 
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>