Re: [Phpgroupware-developers] integration of admin-addressbook-calendar-HR

[Brian Johnson]

I personally prefer the record linking system currently provided by infolog 
(and I
think is referenced in the wiki discussion about these topics but I haven't gone
back to check).  It essentially provides a relationship between any two records 
in
any two apps (which I guess is a many to many to many type relationship)

Although a one to one relationship is desired for this purpose (and can be used 
as
such anyway), the use of this inter-app record linking as a standard method 
allows
other apps to use it as well so any app can link a record to an addressbook 
record
and addressbook will be smart enough to check for those links before allowing a
record to be deleted (for example).  This would work for the calendar example 
listed
below as well as it would work for linking projects to contacts in projects or
timetrack (I'm sure other apps could be developed that could benefit from 
sharing data)

It certainly wouldn't hurt to check the DCL db layout too since it might be a
workable solution.

In any event, I'd prefer that a rearrangement of the db layout for the 
addressbook
(in particular) not happen in such a way to impose other limitations on the use 
of
phpgw that might require further db changes in the forseeable future.  Maybe 
someone
will come up with a use for phpgw that does logically require multiple contacts 
in
addressbook to be assigned to one account or vice versa.  If the table 
structure for
addressbook is changed to separate orgs and people, maybe someone will want to 
link
mutiple accounts directly to orgs (or vice versa) instead of just people
(individuals) .. this is just used as an off the top of my head example to show 
that
we needn't predict every future use of the data, nor limit that use, if we 
provide a
flexible enough structure


Michael Dean (address@hidden) wrote:
>
>Perhaps I'm misunderstanding you, but I believe you should achieve the
>relationship by placing a reference to the contact record on the user
>account record (i.e., user has a contact record).  In doing that, you
>guarantee a user has only one contact record.  Going the other way, a
>user could have multiple contact records, which is not desired.
>
>Also, I have posted a link to the DCL contact schema that is used by GNU
>Enterprise and will be supported by DCL in version 1.0.  I believe the
>FSF is using tools created by GNUe developers that rely on the schema as
>a base for their contact management as well.
>
>I think it really needs serious consideration by phpGW for adoption as
>we can share the same base schema across all of these wundebar projects.
>
>On Thu, 2003-06-12 at 23:51, Jonathan Rivera wrote:
>> Hello guys,
>>
>> talking with lex, i have been thought that we can have a good system of
>> handling of users, who allows us to integrate the users of the system to
>> addressbook and that also it allows us to use those same contacts in
>> calendar.
>>
>> For example, it would be very useful to be able to say in calendar,
>> invites to this event to the members of this group and that included all
>> the members or can to do that same one in the mail,
>>
>> I believe that if we modified a little the API of PHPGW this would
>> facilitate much the things.
>>
>> What I have thought to do is:
>>
>> 1.Add a new field to the table of addressbook
>>
>> - account_id: would be the same of phpgw_accounts, in order to  be able
>> to relate the contact information to its user of the    system, you go of
>> phpgw_addressbook would continue being the key  in that used table and
>> this would be one for when a contact is         not a user of the system.
>>
>> 2.Add a new table with two fields,
>>
>> - id: would be the same of phpgw_accounts
>> - id_addbook_entry: would be the same of phpgw_addressbook this table
>> would use it to be able to define and to personalize who I want that
>> they appear like my contacts, and of being able to relate easily
>> when it wants to use the groups.
>>
>> 3.Modify the code so that it is possible to have this integration, this
>> would imply to modify the API, so that all this works in calendar,
>> addressbook and the module of admin that it registers to the system
>> users.
>>
>> 4.Modify the part of addressbook, i could implement the suggestions that
>> are in wiki on separating the table of phpgw_addressbook.
>>
>> The advantages that I see are that really we would have a system of
>> users and contacts, and the HR application would be only a front end of
>> these tables.
>>
>> I think also to make the support for LDAP, but in this moment i only think
>> on the database module, any suggestion are welcome.
>
>
>
>
>_______________________________________________
>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 :) *