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

List:       koffice-devel
Subject:    Re: Task control/Document control in kplato
From:       Dag Andersen <danders () get2net ! dk>
Date:       2007-09-26 12:10:38
Message-ID: 200709261410.39049.danders () get2net ! dk
[Download RAW message or body]

Onsdag 26 september 2007 13:50 skrev Thomas Zander:
> 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 :)
Ok, I'll explore this avenue further.
>
> > --------
> > 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
> :)
Ahh, good, I was afraid I was totally lost :)
>
> > 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 :)
Yes, I wouldn't like to *depend* ECM, but as an option, in the future...
-- 
Mvh
Dag Andersen
_______________________________________________
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]