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 _______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
