create new tag
, view all tags
-- AndyGlew - 29 Dec 2003


Does anyone have code for twiki that allows

  • a search to be done over a group of pages, creating a nicely formatted report
  • where the report may itself be centrally editable - itself a form where some of the fields can be written
  • with an action for this form that takes the edits, and modifies the original pages from which the report was made.

There are issues with atomicity, rtc., which, if anyone has already solved, I would love to use the code for.

Failing that, it doesn't seem too hard to punt on some of these issues, and make this search pages -> editable form -> modify pages approach work.

Please Email

I'd appreciate it if you could email me responses, instead of just posting them here.


I've just been talking with a guy using the TWiki I've set up at my company, who is interested in setting up an IssueTracking or WorkFlow system.

We had a fairly long discussion of IssueTracking and WorkFlow, and talked about commercial tools I have used in the past, such as

  • Commercial
    • Quintus, a prolog based tracking system I introduced to Intel, that tracked issues, bugs, tests, and which enforced workflow
    • SAP - WorkFlow on sterois - NOT lightweight
  • Freeware

Of course, we talked about whether our existing TWiki could be used for such a tool. We looked at how TWiki tracks bugs, etc.

Loosely speaking, many such tools, including twiki, work by creating an object that is the issue or bug that is to be tracked, and then create a report using some sort of search command to find the objects and extract appropriate fields into a table.

For TWiki, the object is a TWiki page; a TWiki form may be used to create the page; the page itself may have a TWiki form associated with it, to make certain searches easier; and the reports are TWiki searches, etc., that may query stylized text and/or forms.


  • many objects
  • reports

In database terminolgy, the report is a "view" of the database.

It became apparent in my conversation with the user who wants to set up the IssueTracking or WorkFlow system, that he is reasonably happy with the TWiki approach, except for one thing: the report/view is read-only.

In some such systems (e.g. in SAP) the view can be edited in trivial ways.

For example, you may have an IssueTracking system with potentially lots of text per issue. Too much to simply see all issues together.

But you can create a table which just lists possibly the issue title, submitter name, number, priority, and completion status. TWiki can do that.

What we want is the ability to be able to perform simple edits, in that centralized table. E.g. to be able to correct typos in the submitter name, and/or mark an issue complete.

We want to be able to edit in the centralized view, and not have to open the pages one by one.

Conceptually, this is pretty easy. Write wiki code that does the search, but which formats the data returned by the search into a form itself. Allow the user to edit this form. Hit something like a GO button, and have the code/script handling the form go and make the changes to the individual wiki pages from which the data was extracted.

There are minor issues, such as atomicity, etc. But it should be doable.

My question, of course, is whether anyone has already done this? Can I find code that I can cribe from?

Failing that, I invite comments as to how it might most easily be done. E.g. what would a generic approach to this be? E.g. such editability might be easier to provide for forms data.

-- AndyGlew - 29 Dec 2003

Have a look at: http://wikix.ilog.fr/wiki/bin/view/Koalaskin_tasklist/WebHome We have done this (a task list) in pure wiki. The trick is to have each issue be a separate topic, so that to edit it you just go to it first, then click edit.

This is not what you requested, but this tasklist was done for an user that had exactly the same requirements as yours (be able to edit the status of a task in the summary view), but ended up totally satisfied with the current solution as in real use you never have to change status of lots of tasks at a time.

-- ColasNahaboo - 30 Dec 2003

A combination of a formatted search controlled by an URLPARAM (or better PARAM) and direct save from view would do this. (The changes to allow direct save from view are fairly trivial)

Essentially the technique could be to build a separate form for each row in the view which performs a direct save when updated.

A nicer approach of course is to edit the table as a whole & then save - fanning out the results to the affected topics. Locking would ideally be performed after the search. This would simplify modifying the data associated with all slices through topics. (The nice this is this would be more flexible than edittable standard database views I suspect - but a simpler case to deal with since standard database views also cover joins)

-- MS - 30 Dec 2003

I have just added a small enhancement: a direct "edit" icon in the summary view. Combined with the KoalaSkin "direct save", this makes a quite confortable setting

-- ColasNahaboo - 31 Dec 2003

Colas, I love your tasklist and I stole it shamelessly, including the little star graphics needed to make it look as nice as yours. One thing I can't work out though, how did you do the 'date' fields in the form? I don't seem to have that field type available, and it's the feature that makes the tasklist really nice to use.

-- SueBlake - 05 Mar 2004

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2004-03-05 - AndreUlrich
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.