[Top][All Lists]
[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
- [phpGroupWare-developers] linking items across applications, Sigurd Nes, 2007/10/27
- Re: [phpGroupWare-developers] linking items across applications, Dave Hall, 2007/10/28
- Re: [phpGroupWare-developers] linking items across applications, Dave Hall, 2007/10/28
- Re: [phpGroupWare-developers] linking items across applications, Sigurd Nes, 2007/10/29
- Re: [phpGroupWare-developers] linking items across applications, Dave Hall, 2007/10/29
- Re: [phpGroupWare-developers] linking items across applications, Sigurd Nes, 2007/10/29
- Re: [phpGroupWare-developers] linking items across applications, Dave Hall, 2007/10/29