Re: [phpGroupWare-developers] linking items across applications

[Sigurd Nes]

Dave Hall wrote:
> 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.
> 
>
It is 2 way - but is also a part of a tracking - allowing to trace the
origin of some end product (let say an invoice) via all sorts of entities.

I stick to origin <-> target.

As for your comment of location field and appnames - we could move to
app_id and have an integer for acl_location_id and rename the current
phpgwacl_acl_location.id to  phpgwacl_acl_location.name

Applied to interlink (along with class_name) it would spell as:

'phpgw_interlink' => array(
    'fd' => array(
        'interlink_id' => array('type' => 'int'
        'origin_app_id' => array('type' => 'int'
        'origin_class' => array('type' => 'varchar'
        'origin_location_id' => array('type' => 'int'
        'origin_id' => array('type' => 'int'
        'target_app_id' => array('type' => 'int'
        'target_class' => array('type' => 'varchar'
        'target_location_id' => array('type' => 'int'
        'target_id' => array('type' => 'int',
        'is_private' => array('type' => 'int'
        'account_id' => array('type' => 'int'
        'entry_date' => array('type' => 'int'
        'start_date' => array('type' => 'int'
        'end_date' => array('type' => 'int'
    ),

Not sure about the link_type mentioned by maat.

As for the acl-table (phpgw_acl) itself -  it need some thinking 'cause
'acl_appname' also handles groups - and if the acl_appname is a group -
then the acl_lcation is a group_id.

>> 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.
> 
But you need to point to a method within the class - right?

> 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
> 
I think we are getting closer to something good here.


Regards

Sigurd