phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [phpGroupWare-developers] linking items across applications


From: Sigurd Nes
Subject: Re: [phpGroupWare-developers] linking items across applications
Date: Sun, 28 Oct 2007 11:00:37 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

Dave Hall wrote:
> Hi Sigurd,
> 
> On Sat, 2007-10-27 at 10:53 +0200, Sigurd Nes wrote:
>> Hi all,
>>
>> As Dave already has announced - there is a project hosted in Norway to
>> develop phpGroupWare into a Facilities Management System. A lot of work
>> has been focused on the application "property".
>> At this stage we are looking into possibilities of linking items across
>> applications - some sort of "interlink" (there might be a better word
>> for it).
>> As an example - it would be nice to be able to link in projects from the
>> application "projects" as work performed with internal employees - as
>> opposed to work order from external vendors (which already is implemented).
>>
>> I have used a similar approach within the app "property" - linking items
>> from the helpdesk with reports/requirements/orders.
>>
>> So - is there a interest in the community to have this as a general
>> feature within the API?
>>
>> My proposal (as it is used in property) is as follows:
>> The idea is to link from a location (the acl-location) within an
>> application as origin - to a corresponding destination.
>>
>> origin <--> destination
>>
>> For this I think we need a table "phpgw_interlink" (see attachment) to
>> hold the relations - and a new column in the table "phpgw_acl_location"
>> - let's call it "baselink"
>>
>> phpgw_acl_location.baselink can hold the information on where to point
>> the link.
>>
>> example:
>> The baselink for tts (the helpdesk) within property would be "uitts.view"
>>
>> Any thoughts or better ideas ?
> 
> I don't think storing this information in the ACL table is appropriate.
> The ACL table should store data for access control, not data links.  

It's not the ACL table - it's the acl_location-table (anyway - it would
probably be more convenient to store this in a hook )
> 
> The ACL table proposal doesn't sllow for edit links.  Once data is
> linked we need a system to ensure that dangling links aren't left behind
> when users delete a record.
> 
> I think any linking system must allow for the following functionality:
> 
> * get a list of links with summaries
>       - summaries should be "[module] summary"
>       - ACLs need to be enforced
>       - where user doesn't have read rights they should receive a messge like
> "[type] summary unavailable (owner: XXX YYY)"
> 
> * display edit link if user had the appropriate rights
> 
> * display "delete link" link subject to ACLs
> 
> * check that there is no linked records before deleting a record
>       - if records exist give user a choice of actions - subject to ACLs
> 
> * links should be 2 way and displayed to users in both contexts
> 
> * allow administrators to manage links

Good idea
> 
> I think the follow schema allows for all of the above
> 
> 'phpgw_interlink' => array(
>         'fd' => array(
>                       'interlink_id'  => array('type' => 'int', 'precision' 
> => 4, nullable => False),
>                 'app1_name' => array('type' => 'varchar','precision' => 
> '25','nullable' => False),
>                 'app1_class' => array('type' => 'varchar','precision' => 
> '12','nullable' => False),
>                 'app1_id' => array('type' => 'int','precision' => 
> '4','nullable' => False),
>                 'app2_app' => array('type' => 'varchar','precision' => 
> '25','nullable' => False),
>                 'app2_class' => array('type' => 'varchar','precision' => 
> '12','nullable' => False),
>                 'app2_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)
>         ),
>         'pk' => array('interlink_id'),
>         'fk' => array(),
>         'ix' => array('app1_name', 'app1_class', 'app1_id', 'app2_name', 
> 'app2_class', 'app2_id', 'is_private', 'account_id'),
>         'uc' => array()
> ),
> 

I think it's better to use app1_location (the acl_location) than
app1_class - because one can have several locations within a class that
is subject to linking.

> (I am unsure if we should define another table to locations do joins,
> and apps can register in that table)
> 
> The app?_class will list a class - it should be a bo class.  The class
> would need to implement the following method
> 
>       /**
>       * Get the summary of a record
>       *
>       * @param int $id the record id
>       * @return array the summary data
>       */ 
>       public function summary($id);
>       {
>               return array
>               (
>                       'text' => 'the text summary',
>                       'view' => 'menuaction.used4.viewing_record', //null if 
> not permitted by ACLs
>                       'edit' => 'menuaction.used4.editing_record' //null if 
> not permitted by ACLs
>               );
>       }
>       
> I have notes on how the linking class itself should work.  I am happy to
> post a stubbed class if people think it is worthwhile :)
> 
> Cheers
> 
> Dave

Please - let's have a look at it


Regards

Sigurd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]