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

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

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