Re: [phpGroupWare-developers] linking items across applications

[Dave Hall]

On Sun, 2007-10-28 at 15:17 +0100, Sigurd Nes wrote:  
> Here is my (revised) proposal for schema:
> 'phpgw_interlink' => array(
>     'fd' => array(
>         'interlink_id' => array('type' => 'int', 'precision' => 4, nullable 
> => false),
>         'origin_app' => array('type' => 'varchar','precision' => 
> '25','nullable' => false),
>         'origin_location' => array('type' => 'varchar','precision' => 
> '12','nullable' => false),
>         'origin_id' => array('type' => 'int','precision' => '4','nullable' => 
> false),
>         'destination_app' => array('type' => 'varchar','precision' => 
> '25','nullable' => false),
>         'destination_location' => array('type' => 'varchar','precision' => 
> '12','nullable' => false),
>         'destination_id' => array('type' => 'int','precision' => 
> '4','nullable' => false),
>         'is_private' => array('type' => 'int', 'precision' => '2','nullable' 
> => false),
>         'account_id' => array('type' => 'int','precision' => '4','nullable' 
> => false,
>         'entry_date' => array('type' => 'int','precision' => '4','nullable' 
> => false),
>         'start_date' => array('type' => 'int','precision' => '4','nullable' 
> => true),
>         'end_date' => array('type' => 'int','precision' => '4','nullable' => 
> true),
>
>     ),
>     'pk' => array('interlink_id'),
>     'fk' => array(),
>     'ix' => array(),
>     'uc' => 
> array('origin_app','origin_location','origin_id','destination_app','destination_location','destination_id')
> ),
> 
> I think the link should be unique (could possible conflict if
> different user should be able to make the same relation - hidden from
> each other).

This is why having such a unique constraint isn't a good idea.  If a
user can't see the link they should be free to create their own version
of the link.  There may be good reasons why a user decides to make a
link private.

If we do go with the constraint, should't it be
    'uc' =>
array(array('origin_app','origin_location','origin_id','destination_app','destination_location','destination_id'))
 ? :)

<snip />


> I prefer to use origin and destination over app1 and app2.

The use of origin/destination suggests the links are 1 way, they need to
be 2 way and the naming should reflect that.


> As for origin/destination_location - the class entity in the app
> property handles a wide variety of items
> (could be several hundreds when a set of IFC-entities is loaded) - so
> classnames would be useless.

Classes make a lot of sense.  They allow us to have easy to use methods
for handling the linking, each link type implements a class which
handles the linking for that type within a module.  ExecMethod can then
be used and everything is consistent.

Your suggestion to use location with a app.class.method (which doesn't
belong in the ACL location table) would only provide a view option for
the linked data.  What happens when a user is viewing a project and has
a related contact linked to it and they want to edit the linked contact?
Should they go project -> open popup in view mode -> click edit -> edit
contact save -> close window?  Skipping the view step makes a lot of
sense to me - subject to ACLs.  Adding another column to acl_location
seems like a hack to me.

Also what happens when code is refactored and the old app.class.method
no longer makes sense?  Do we need need to run UPDATEs on a core table
as part of the module upgrade?

Cheers

Dave