From koffice-devel Wed Sep 26 12:10:38 2007 From: Dag Andersen Date: Wed, 26 Sep 2007 12:10:38 +0000 To: koffice-devel Subject: Re: Task control/Document control in kplato Message-Id: <200709261410.39049.danders () get2net ! dk> X-MARC-Message: https://marc.info/?l=koffice-devel&m=119080868101247 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