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: Sat, 27 Oct 2007 16:23:23 +0200
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

Maat wrote:
> Sigurd Nes a écrit
>> 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).
>>   
> 
> yeah. really great idea !
> 
>> 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?
>>   
> 
> for me yes !
> 
>> 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'm not sure but i'm working on a client/server relation between phpgw
> apps approach and the need seems rather close
> 
> i've started to work on a complete workflow (core part just finished...
> admin ui still to be written) system and my document management module
> behaves as a "plugged" client for the flow system.
> 
> => flow system manages versions of documents without knowing exactly
> what they are and it triggers ged flow dedicated methods  (in
> ged:class.flow_client.inc.php)
> to perform operations on ged objects.
> 
> later this approach should allow to trigger documents status change from
> a task/project manager module.
> 
> the problem for the task manager will be to know, for a given task,
> which douments are linked but also in what manner they are linked.
> 
> some documents will be "help documents" (no actions on them) or
> "instruction documents" (no actions either on them) and some others will
> be "targeted documents" (actions planned on them)
> 
> if the task is to control a document the task manager should provide a
> link to ged object (element_id plus version_id) to allow to dowload/view
> it without switching to ged interface and forms elements to close the
> task and flag the document "ok" or "not ok" at the same time (and
> trigger if needed the creation of an other task to rewrite the document)
> 
> If the task is to write a new version for the document the task manager
> should provide a form (picked from ged ?)  to  insert  the document...
> and once in ged the document is tagged "ok", ged should have all the
> data needed to close the task (trigger) in task manager
> 
> so i wonder if a simple link is enough...
> 
> maat
> 

Thanks for your great response.

Seems like you are bit more advanced than me - but your angle seems very
interesting in the perspective of workflow - which definitely also would
benefit our project.

But you still need the basic link - right?

I'm thinking that to meet your needs - the information of the baselink
could me extended with information of methods covering the aspects of
actions, types -and whatever...

Due to the potentially extent and complexity this meta-information - it
could be wise to store this as a hook.

It is also an appealing idea to link in documents from ged to projects
of construction/maintenance

What do you think - is it possible to combine our needs?

Regards

Sigurd




reply via email to

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