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
_______________________________________________
phpGroupWare-developers mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
