Re: [Phpgroupware-developers] integration addbook-accounts

[Dave Hall]

Brian Johnson <address@hidden> wrote:

> Jonathan Rivera (address@hidden) wrote:
> >
> >Brian Johnson said:
> >> Response is brief due to time constraints:
> >>
> >>
> >> Jonathan Rivera (address@hidden) wrote:
> >>>
> >>>Hi guys,
> >>>
> >>>i send the db diagram which skwashd and i discussed, here an
> >>> explanation.
> >>>
> >>>This based on the dcl schema, as you can see the tables are the 
> same,>>> but we add 4 tables (contacts_comm, contacts_comm_descr,
> >>> contacts_comm_type, contact_types) for managment of others
> >>> communications medias.
> >>
> >> Could you explain this more please?
> >>
> >
> >ok, i explanin on skwashd words:
> >
> >contacts comm stores all communication info (except snail mail)
> >then it has a descr_id field which is linked to a type
> >so then we can have the contacts class handling sending to those
> >via a send method ... which uses other classes
> >ie ... jabber ... sms etc
> >oh and of couse email
> >
> 
> I'll try to find out what this is intended to do from skwashd.  He 
> may not have
> known about the other tables that hold phone numbers, email 
> addresses, notes, and urls


The plan is to have a set of send classes ... contact_email,
contact_jabber, contact_sms, contact_voice (maybe one day) etc.  There
classes are stored against each communication type.  These classes can
be used for validation of data entry, sending messages, what ever else
people can think of.  In the case of email, it will wrap the api send
email object, and have some extra functionality.

I see the following methods as being used for each contact_* class
send($to, $msg)
validate($data)
compose($to)

> 
> 
> >>
> >>>In this picture
> >>> (http://co.com.mx/~jarg/integration_addbook_accounts.jpg) you 
> can see
> >>> the db diagram.
> >>
> >> What's an org_alias?
> >>
> >> phpgw_org_contact should have a sequential index (an "id" 
> field) in
> >> order to allow n -to-n links between orgs and contacts 
> (individuals)>
> >in the mdean model this is a composed key, but if you consider is 
> better>have a secuential index i don't see any problem.
> >
> 
> I don't know if phpgw supports combined field keys, I haven't seen 
> them in other apps

Calendar uses them.  I think in the case of the proposed contacts schema
auto increment keys are generally best.

> 
> 
> >>
> >> None of the "type" tables are diagramed and should be
> >
> >yes i forget draw this, but i already consider this.
> >
> >>
> >> Don't forget categories for both contacts and orgs
> >
> >oh, yes, i will draw this on next diagram
> 
> follow the phpgw style of category linking.  Each record gets a 
> string field that
> contains a cat_id number or a comma delimited list of cat_id 
> numbers if multiple
> categories are assigned (addressbook currently does this)

That is bad db design ... if there is a n:n relationship it should be in
a seperate table.


> 
> >
> >>
> >> mdean and I discussed adding a "others" table and an 
> "others_type" table
> >> to pick up methods of contact other than phone, email, etc.  
> They should
> >> be added to the diagram.
> >>
> >
> >this is not like that skwashd proposed??
> 
> I'm talking about two tables just like phpgw_org_note but 
> phpgw_org_other and
> phpgw_org_note_types but phpgw_org_other_types

This should be possible either through infolog or some other data
linking mechanism.  Notes really don't belong in contacts ... imho

> 
> >
> >>
> >>>
> >>>
> >>>additionaly i explain my idea about control contacts for each user
> >>> system:
> >>>
> >>>phpgw_addbook_entries: this table would be new, and this allow 
> us to
> >>> have a relation between one system user and all his contacts in
> >>> addressbook.
> >>>
> >>
> >> Could you explain this a bit more?
> >>
> >> Since you can query phpgw_contact by the created_by field, I 
> assume this
> >> is so you can have multiple users own the same contact record.  
> I don't
> >> understand the need for such a system
> >>
> >> If you do need this, shouldn't it also link to phpgw_org?
> >>
> >
> >i think use this for something as :
> >
> >usersystem    contact_id
> >1               2
> >1               4
> >1               9
> >1              10
> >2               3
> >2               7
> >2               9
> >3               4
> >3               5
> >3               8
> >3              10

I personally think this should be a 1:1 relationship with the id in the
accounts table.  There should also be a flag in the contacts table to
indicate the contact is a system user.  There is currently a
contact_tpye (or something) field - this should be set to "u" for user
or something.


> >
> >so, i think use this for make groups and share contacts between 
> users,>really i don't know if this is useful, actually i think 
> more about this,
> >any commentary or suggestion are welcome.
> >
> 
> So you're setting up a system where multiple users can own a 
> contact record.  This
> is the part of the whole thing that causes ACL problems.
> 
> How do you intend to handle read/write access to other users and 
> groups?

I think the current ACL system works quite well, there just needs to be
some extra rules added for system user contacts.  For example, a user
can edit their own contact data, but the sysadmin or someone else can
edit all.  This should be an admin option.  Also some consideration
needs to be given to where you have groups which can't see each other,
are their user contact details visible?  Admin option for turning this
on/off??


> 
> >>
> >>>i think use the new table (phpgw_addbook_entries) for control 
> entries>>> of each system user and make groups for use in calendar 
> and email ap.
> >>> the problem that lex see is that this violates the acl mechanism.

I think there are some better ways for handling sending to system user
groups, see my comments on the wiki regarding the proposal for email.  I
think this provides a far more flexible system.

> >>>
> >>>comments??

Great work, btw this is not my concept it is Jarg's with some input from
me.  Hopefully we can get this sorted out and have it agreed and coded
asap :)


> >>>
> >>>
> >>
> >> I think you're going in the right direction, just needs some slight
> >> adjustments
> >>

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