Re: [Phpgroupware-developers] integration addbook-accounts

[Brian Johnson]

Geez, a lot of action and I'm not part of it

Here's some comment:

I think there is some real benefit to sharing a db structure with that used by 
dcl.
 From what I understand, the dcl system is slated to become part of the fsf
groupware platform currently under development.  Sharing the db structure should
lead to wider adoption and faster development since more people will be working 
on
it at a time.  It does however mean that there are more people with multiple
objectives to please and if we keep this in mind, we should be able to develop a
really good system, potentially suitable for a "standard" (and that is currently
really lacking).

I think jarg, skwashd, and mdean all agree with this concept.

We should be aware of that and be careful to add anything that is specifically 
phpgw
related as an additional table so as not to "pollute" the standard contacts 
data db
structure


Dave Hall (address@hidden) wrote:
>
>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)
>
Michael Dean (address@hidden) wrote:
>
>We do have separate tables for phone, email, snail mail.  This should
>just be an extension of these to allow easy expansion.

I agree with that.

skwashd, what additional/different tables and fields would that require?

The tables are split up more than they need to be from a simplicity viewpoint 
(which
increases complexity) but are arranged to attempt to group similar types of 
data to
speed SQL statements in large systems.  It's a move to ease future 
expandability.


Michael Dean (address@hidden) wrote:
>
>> >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.
>
>This is the relationship that establishes the owner of the contact
>records.
>
>> 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
>
>created by is just a reference as to who created the contact record,
>modified is who last updated it.  It's for quick auditing purposes.
>

skwashd and mdean: you guys understand the phpgw system better than I do.

Is having multiple owners for a record going to screw up the ACL?  The example 
from
jarg shows this as being used for that purpose.

Can phpgw use the created_by field as the owner (even if other systems choose 
not to
do the same)?

If not, should the records be limited to linking to one account?  Also, the 
link to
accounts should also be for orgs

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

>Type should be an integer, so that makes this a little tricky to
>implement. What value do you see in marking a record as a user if you
>already have that info on the account record?

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

In the conversations, I'm confused between talking about linking of a phpgw 
user to
addressbook entries that they own/created (perhaps multiple owners) and the 
linking
a phpgw user account to their (ie their personal info) contact info in 
addressbook.
 What IS the intent of the phpgw_addbook_entries tables?

The previous section concerns the former, this part concerns the latter.

In the spirit of db use by multiple systems, the link should NOT be an entry in 
the
contacts tables (so perhaps an entry in the account table IS good).

If the user is the owner of their own record, then can't both that user and the
admin edit the info with the current ACL system?

I don't have a better solution than the above, but when reviewing this please 
remember:
1. that not all accounts would have contact info (ie guest accounts)
2. that a user's record should be able to be deleted, but a method to re-link
another contact should be provided

Since we expect to make addressbook "linkable" in an infolog link sense, is 
there a
way to make that code do double duty and serve this purpose as well?

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

This seems to be a minor point, if they're possible in phpgw, let's use a 
combined
field primary key.  From a db standpoint it is more efficient

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

Bad db design yes, but it also is the standard for all apps in phpgw that use
categories.

Skwashd and mdean: is this a good time to change the phpgw category system and 
force
all apps to follow suit or is there a way to chnage the category system for just
this app?

We're looking at enough changes that I think this one we should NOT change 
right now

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

This is really two separate points:

1. add an "other" table for both contacts and orgs to store anything not already
grouped into the other tables

2. the use of a "notes" table or infolog.  To me, infolog is great, but is 
phpgw.
The standard db structure requires a notes table but perhaps phpgw need not use 
it.
 The feasibility of using infolog as a notes storage system for contacts to me 
is
one of usability.  The gui should not require a page reload to add a note or any
other type of contact data (screen reload is okay if adding more than 
note/data) but
this requirement of mine is independant of how that data is stored



>Sure it could be an integer (or char).  It will add another table.  This
>would even allow organisations to be stored in the same table.  For example:
>type_id - INT autoincrement
>type_descr - VARCHAR(50)
>active - TINYINT
>
>and the default records could be
>1, "System User", 1
>2, "Person Contact", 1
>3, "Organisation Contact", 1
>
>> What value do you see in marking a record as a user if you
>> already have that info on the account record?
>
>The main reason for this is to allow filtering out the data that is not
>needed (such as only display users).  For exmaple you could filter by
>the 3 types listed above.  Saves a query or 2 :)
>

This touches on some of the above items.  The system users, persons, and
oganizations COULD be in one combined table but SHOULD NOT BE for the same 
reason
phone and emails have different tables .. speed in large data sets

BTW addbook uses a meta data table for something similar.  All people and orgs 
are
listed there with their cretaion dates and this table creates a relationship to 
the
people and orgs tables that contains the more specific data

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