- 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
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
We had a fairly long discussion of IssueTracking
and talked about commercial tools I have used in the past,
- 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
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.
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
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
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.
- 29 Dec 2003
Have a look at:
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.
- 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
- 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.
- 05 Mar 2004