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

[Dave Hall]

Ralf Becker <address@hidden> wrote:

> Jonathan Rivera schrieb:
> > hi guys,
> > 
> > finally between skwashd and i finished the model for the 
> integration of
> > admin with addressbook, here can see it .
> 
> Good work, looks realy nice.

thanks

> 
> I would like to move these docs / proposals to the wiki and would 
> propose to give jarg write-rights to the wiki.

I have created an account for him.  I will leave jarg to add it into the
existing discussions on there.  I am happy to help with some of the
descriptive text to go with the model.

> 
> > http://co.com.mx/~jar
> 
> I have some remarks:
> 
> 1) I would recommend to use InfoLog for a variable number of notes 
> and 
> not build this into the addressbook (with an extra table). A 
> single note 
> field is needed for backward compatibility.

I agree with this.  The table was left in as some people liked it in the
past.  I think a single notes field in required, for compatiability (and
those user's who don't use/like infoLog).

> 
> 2) I'm not sure if the phpgw_contact_cat table with primary key 
> (and 
> only columns) contact_id and cat_id is better to hancle as the 
> comma-separated field in addressbook now.

I think it is better db design to do it this way.  Especially as we are
proposing to use readonly replication for LDAP.  I also don't think
there is a need for a autoincrement primary key in this case - as
contact_id+cat_id == unique_id.

> 
> 3) I still miss the custom fields, but this is easy to add with a 
> table 
> phpgw_contact_customfields with columns contact_id, 
> custumfield_name and 
> value.
> 

Yes this is possible.  Or 2 additional tables:
phpgw_contact_custom_fields
custom_field_id
custom_descr

phpgw_contact_custom_values
custom_val_id
contact_id
custom_field_id
custom_value

> 4) This might be a question to mdean: Does all supported DB's 
> allow (in 
> a single syntax) to join all this tables together?
> 

I would see there would be several key queries.  A list query (maybe 2
one for person and for orgs), one for each type of summary (person, org,
and user).  The full details query, which would be 3 or 4 queries
executed in sucession - which would give full record data.

> 5) I personly dislike schemas with so many linked tables, but this 
> might 
> be just a question of taste. The content of the *_type tables 
> (which 
> will be only a view rows), might go into the phpgw_config table as 
> an 
> serialized array.

This is the cost of 3NF more tables, more complex queries.  For this
reason I think the contacts classes should offer all a dev needs for
accessing/manipulating records - they don't even need to know how to do
a SQL join.

What *_type tables are you referring to, there are several which perform
different tasks.

> 
> 6) An other concern: I see advantage of haveing modified_* cols 
> for each 
> single table for resolveing conflikts while syncing the data. Do 
> all 
> tables need created_* columns, as most of them will get created 
> with the 
> creation of the contact itself? Do we need a modified column for 
> the 
> contact itself (not its parts) to be updated and whatever update 
> of one 
> of its parts and to show to the user as the last-update date (dont 
> think 
> you want to show 10 different modified dates / modifiers to the 
> user in 
> the UI).

The mod/created fields are good for syncing, but they are good for other
things too.  They also help with simple user auditing - for example the
data keeps on going screwy - check the db - ah it looks like Ralf is
stuffing it up ;)

I think some way of the contacts class determining the last mod time
stamp to display to the user would be a good work around.

> 
> I hope this "critisism" does not sound to negative, I'm quite 
> happy 
> someone is working on the contacts schema.

I don't see it as negative at all.  The model is there for public
discussion.  What I (and others) have been trying to do is build a model
which will work well for our developers and our users.  Jarg has been
great at taking suggestions and reworking the model.  I hope that the
schema we are working on does not make life too difficult for him to code.

> 
> I would voluntier building a nice tab'ed UI with eTemplate for the 
> new 
> addressbook.

That can be discussed also.  I would like to see it up an running asap -
but the model must first be agreed.  I would like to see it done in xslt
in head as that is the agreed core app tpl engine. /me waits for the flame.

> 
> Ralf
> -- 
> -------------------------------------------------------------------
> ---
> Ralf Becker
> OUTDOOR UNLIMITED Training GmbH                Telefon 0631 / 
> 31657-0
> Leibnizstraße 17                               Telefax 0631 / 
> 31657-26
> D-67663 Kaiserslautern            EMail address@hidden
> 
> 
> 
> _______________________________________________
> 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>