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

[Brian Johnson]

Dave Hall (address@hidden) wrote:
>
>Brian Johnson <address@hidden> wrote:
>
>>
>> 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.
>

Many apps use the current contact data?  I think many apps DON'T use the current
contacts data because the contacts data does not check to see if anything links 
to
it before deleting a record.

Splitting the people and orgs is only one half of the goal of this revision.
Providing a method for other apps to link to contacts data without fear of some 
user
deleting it is the second half of the (or at least my) goal.  Without both 
halfs,
why bother doing the first half?



>>
>> 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.
>

I suspect this will need to be simplified prior to it's implementation (likely 
get
rid of the phpgw_contacts_comm_type table).  It seems like extra complication 
that
is unneccesary since it seems like the function associated with these items 
could be
directly associated with the types in phpgw_contacts_comm_descr

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