Re: [phpGroupWare-developers] linking items across applications

[Sigurd Nes]

Dave Hall wrote:
> On Mon, 2007-10-29 at 09:35 +0100, Sigurd Nes wrote:
>> Dave Hall wrote:
>>> On Sun, 2007-10-28 at 15:17 +0100, Sigurd Nes wrote:
>>>
>>>> I prefer to use origin and destination over app1 and app2.
>>> The use of origin/destination suggests the links are 1 way, they need to
>>> be 2 way and the naming should reflect that.
>>>
>>>
>> It is 2 way - but is also a part of a tracking - allowing to trace the
>> origin of some end product (let say an invoice) via all sorts of entities.
>>
>> I stick to origin <-> target.
>
> The way apps handle that is up to them.  I think that we should make it
> clear in the schema and the class that handles it, that it is 2 way -
> origin/target does not give this sense, app1/2 isn't ideal but is closer
> to what is needed.
>
>> As for your comment of location field and appnames - we could move to
>> app_id and have an integer for acl_location_id and rename the current
>> phpgwacl_acl_location.id to  phpgwacl_acl_location.name
>>
>> Applied to interlink (along with class_name) it would spell as:
>>
>> 'phpgw_interlink' => array(
>>     'fd' => array(
>>         'interlink_id' => array('type' => 'int'
>>         'origin_app_id' => array('type' => 'int'
>>       'origin_class' => array('type' => 'varchar'
>>         'origin_location_id' => array('type' => 'int'
>>         'origin_id' => array('type' => 'int'
>>         'target_app_id' => array('type' => 'int'
>>       'target_class' => array('type' => 'varchar'
>>         'target_location_id' => array('type' => 'int'
>>         'target_id' => array('type' => 'int',
>>         'is_private' => array('type' => 'int'
>>         'account_id' => array('type' => 'int'
>>         'entry_date' => array('type' => 'int'
>>         'start_date' => array('type' => 'int'
>>         'end_date' => array('type' => 'int'
>>     ),
>
>
> I think this is getting close, but I think that location_id can be
> stored in phpgw_locations
>
> location_id - int - auto - pk
> appid - int
> location - varchar(50) ?
> handler_class - varchar(50)
> is_active - int 0/1
>
> Sorry I couldn't be bothered do it in a phpgw schema snippet :)
>
> Then we can just have location1_id location2_id.  The data can then also
> be used in other places.

Clever!
it would reduce interlink to:

'phpgw_interlink' => array(
    'fd' => array(
        'interlink_id' => array('type' => 'int'
        'origin_location_id' => array('type' => 'int'
        'origin_id' => array('type' => 'int'
        'target_location_id' => array('type' => 'int'
        'target_id' => array('type' => 'int',
        'is_private' => array('type' => 'int'
        'account_id' => array('type' => 'int'
        'entry_date' => array('type' => 'int'
        'start_date' => array('type' => 'int'
        'end_date' => array('type' => 'int'
    ),

> I am happy to add the custom field/functions
> columns to the above.
>
Feel free...

>> Not sure about the link_type mentioned by maat.
>
> Neither am I, let see what he comes up with today.
>
>> As for the acl-table (phpgw_acl) itself -  it need some thinking 'cause
>> 'acl_appname' also handles groups - and if the acl_appname is a group -
>> then the acl_lcation is a group_id.
>
> Each group could be a location in phpgw_location and we define an app
> phpgw_group with an id of -1 to indicate that it is special?
>
>

That would do - will have to join the location table when altering rights
to keep the inheritance functionality.

>>>> 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.
>>> Classes make a lot of sense.  They allow us to have easy to use methods
>>> for handling the linking, each link type implements a class which
>>> handles the linking for that type within a module.  ExecMethod can then
>>> be used and everything is consistent.
>>>
>> But you need to point to a method within the class - right?
>
> it would be hard coded, summary() - see my earlier email.  We could also
> define additional methods in the class for search interfaces etc etc.
>
>
>> I think we are getting closer to something good here.
>
> I agree :)
>
> Cheers
>
> Dave
>

Regards

Sigurd