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: Maat
Subject: Re: [phpGroupWare-developers] linking items across applications
Date: Sun, 28 Oct 2007 10:10:47 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

Dave Hall a écrit :
> 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.  
>
> 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
>
> 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()
> ),
>   

nice start

a few things at first reading :

'app1_name' => name
'app2_app' =>  app !? (little typo ?)


'app1_id' => array('type' => 'int','precision' => '4','nullable' => False),
'app2_id' => array('type' => 'int','precision' => '4','nullable' => False),

=> what if targeted object id is a string or something more complex ?

perhaps we need also :

-- something to make link inactive without deleting it
-- something to define a date when the link becomes active... and a date when 
the link stops being active
-- something to define the "type" of the link

i wonder if 'is_private' approach  will be enough  for acl control on links

maat

-- 
In a world without walls or fences, there would be no need for windows or 
gates...





reply via email to

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