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

Sigurd Nes a écrit :
> Maat wrote:
>
>> perhaps we need also :
>>
>> -- something to make link inactive without deleting it
>>   
> It could be Inactive when end_date expires.


ok then you cannot disable a link during its active period check
something the re-active it 2 days later.
perhaps this case will not appear :/


>> -- 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?

yeah.

example : for a given type of task ( in tts, in task manager) you'll
have to link to documents you need to change but also to documents like
instructions or guides for the said task.

=> you'll have to make a difference : offer upload forms somewhere in
the page for the documents you need to change

=> show in a "help" zone the documents linked "for information"
>>
> 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')
> ),
>
>   

ok but the "location" thing is not really clear for me

> 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.
>
>   
dunno but you'll have link from object you are entitled to play with to
objects you aren't

what if a change on the object triggers actions on the linked objects ?

are the triggers considered to be launched with admin rights ?

if not, the denial on the actions are likely to produce data inconsistencies







-- 
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]