[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Task control/Document control in kplato
From:       Thomas Zander <zander () kde ! org>
Date:       2007-09-26 11:50:49
Message-ID: 200709261350.52250.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 26 September 2007 13:30:47 Dag Andersen wrote:
> Yes, what I had in mind with my solution also :)
> Example of workflow would be:
> 1. PM emails project members mails with workpackage attached.
> 2. Member opens the workpackage with the new app (wph).
> The work package is (automatically) saved by wph to a projects dir in
> $KDEHOME/...
> The wph looks a bit like the todo dialogue in kdepim with clickable entries
> for all the documents in the workpackage.
> 3. When the user opens a document he wants to edit, it is extracted (by
> wph) from the store to a temp file and given to apropriate app for
> processing. 4. When the user closes the app, wph retreives the temp file
> and stores it in the work package.
> 5. When closing wph, the status/progress dialog pops up. If changed, info
> is mailed back to PM.

Sounds like an excellent way forward :)

> --------
> For integration with pim (on the member side), 2 options:
> 1. Make a kresource (or is it service now?) in kdepim that can read info
> from the projects dir.
> 2. Have wph (automatically or manually) mail a VTODO to the member.

You can also communicate directly with akanodi and use that as a resource.


> > > > the best long term strategy. Working better with them by actually
> > > > implementing support in the apps (much like my initial suggestion doc
> > > > outlines) may be a better long term solution.
> > >
> > > For kplato in general I need more than document control.
> > > As I see it, the "report status/progress" dialog would be the same (or
> > > very similar) wether it's called from a koffice app or from my "work
> > > package" app, and I'd think the solutions can coexist. Providing both
> > > would mean some extra legwork in kplato, though.
> >
> > Right,
> > one of the ideas I heard was to work with big players in the enterprise
> > content management market.  These ECM packages tend to provide document
> > workflow with things like routing a document to different people.  Much
> > like I suggested in my PDF.
> > Based on that already existing functionality you may be able to talk to
> > the ECM vendors and get a web-service api to which you can upload the
> > document after you show your dialog inside the application.
> > Not sure how best to provide the dialog inside apps, though. As there
> > certainly is work required in the application to do so. Which we can do
> > in KOffice, but I have troubles seeing that done in your "work package"
> > app (I'd love to be proved wrong there, naturally)
>
> Hmm, I have the feeling we misunderstand each other, or more likely I
> misundertand you...
Sorry, my bad. I see my answer doesn't connect to your question very well :)

> My "work package" app is a new app that needs to be writen, so I don't see
> why it can't provide a dialog?

Oh, it surely can. You are right.
After I wrote the PDF the idea of integrating with already existing 
(commercial) ECM solutions was proposed and I wanted to put that forward as 
an alternative 'way forward'. Reading your proposal I agree its the best way 
to act right now. So ignore my long rant on Enterprice Content Management 
systems :)

-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]