Re: [phpGroupWare-developers] linking items across applications

[Dave Hall]

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.  I am happy to add the custom field/functions
columns to the above.

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


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