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 15:17:00 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

Maat wrote:
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 ?
  
It is preferable to have the id of origin/destination as integer - this table would easily exceed hundreds of thousands of records.
perhaps we need also :

-- something to make link inactive without deleting it
  
It could be Inactive when end_date expires.
-- something to define a date when the link becomes active... and a date when the link stops being active
  
See revised schema
-- something to define the "type" of the link

  
Ok - that is possibel - can you explain what you mean by "type" - and how it should be used?
i wonder if 'is_private' approach  will be enough  for acl control on links

maat

  
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).
It also holds the validation data requested by maat, making link inactive without deleting it.
I prefer to use origin and destination over app1 and app2.
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.

Do you really think it is necessary with a full blown acl controll of the relation between items - I think the acl control of the items itself should suffice.

Regards

Sigurd

reply via email to

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