Tags:
create new tag
, view all tags

Archive of discussion on ActionTrackerPluginDev - many thanks to all who contributed!

-- CrawfordCurrie - 10 May 2003


We have need of an action tracker that can be used to record the results of meetings and send out reminders. What would be really nice would be to be able to enter actions into any TWiki page - specifically, the TWiki page used to record the minutes of the meeting where the action was raised. For example:
%ACTION{who=Main.GenghisKhan,due=5th Aug 1236,priority=low,state=open}% Genghis to unite the Mongol peoples
might appear in text as

ACTION for GenghisKhan: Genghis to unite the Mongol peoples, by 5th Aug 1236

Searches could be used to build lists of open actions for individuals.

notify would be extended, or an alternative notify script provided, to send out those irritating action reminders against open actions. This could be done on a cycle based on how long until the action has to be closed e.g. more than one week to go, send out reminders weekly, less than one week send daily, late and send every time notify runs.

Taking this approach would have a double benefit for me; first, actions could be entered at the same time and in the same tool as minutes, and second, the page history means that a full traceable record is kept of changes to action statii.

Opinions, ideas, comments?

-- CrawfordCurrie - 03 Jan 2002

I like the idea very much! While I don't currently have a need for it, it certainly would have been helpful in the past. As to any detailed comments or suggestions, I can't think of any offhand. Would like to see you implement it and then it can be tested in the real world for possible improvements.

-- RandyKramer - 03 Jan 2002

Challenge accepted. See ActionTrackerPlugin. And please test!

-- CrawfordCurrie - 04 Jan 2002

Very cool. I'll try it on Monday when I get into the office.

Two things. At the top of this page you had ActionTrackerAddon I assume you meant ActionTrackerPlugin so it would link to the page with the Plugin. I have made the change. Also shouldn't this page be named ActionTrackerPluginDev?

One thing I see as a possible issue. Have you thought about an easy way to change the status of the action item from OPEN to CLOSED? Having to edit the page and find the action somewhere in the middle is kind of a pain. Maybe a button or link on the view page that can invoke a closeme cgi that will automatically change the item to closed? If the closeme cgi requires authentication before it can be run, it could even annotate the action with the twiki name of the closer and the date on which it was closed.

Also what does ACTIONSEARCH return? The action text? A link to the topic? A link to the source location of the action?

Also the
% ACTIONSEARCH{who=Genghis.Khan@mongol.empire.org,open,within=7}%
example doesn't quote the values for the parameters. This seems contrary to the usual form (E.G. TWikiVariables#Predefined_Variables).

-- JohnRouillard - 04 Jan 2002

Nice idea. A small feedback, it would be more consistent to put parameter values in double quotes, i.e. %ACTION{who="TWikiGuest" due="2 Jan 2004" status="open"}%.

This can be parsed easily with TWiki::Func::extractNameValuePair().

Also, each plugin should have at least the SHORTDESCRIPTION setting so that it will be listed in the TextFormattingRules topic. See more in TWikiPlugins.

-- PeterThoeny - 04 Jan 2002

I just uploaded a bugfix version; I discovered that searches for "who=me" weren't working properly. I've also extended the test suite quite a bit.

  1. I haven't got an easy way of changing action statii. I fiddled with a CGI program to do it, but lost interest. Essentials are:
    • Correct locking
    • Correct revision control of the changed topic
  2. ACTIONSEARCH returns a link to the topic. A link to the actual action is do-able, but requires thought.
  3. I use a small module wot I wrote to parse attributes; it's a lot more functional than extractNameValuePair. It handles attribute values either quoted or unquoted.
  4. I will add a SHORTDESCRIPTION setting the next time I upload - thanks for the heads-up!

-- CrawfordCurrie - 05 Jan 2002

The tracker now includes an action editor; click on the 'edit' link in the action tables. I'm not happy with the 'TWikiness' of the implementation - I had to derive new scripts from edit and preview - but that can be cleaned up over time. I have also fixed a problem with the mailer failing to find correct e-mail addresses, found when testing on Solaris.

-- CrawfordCurrie - 07 Jan 2002

It would be nice if there was a working example on the ActionTrackerPlugin page. I just spent an hour thinking the example was broken. I expected the ACTION entry below (spaces added before % to stop var expansion):

   * Add ==Plugins.% TOPIC%== to the ==INSTALLEDPLUGINS== variable in %  TWIKIWEB%.TWikiPreferences (or any WebPreferences topic).
   * You can test if the plugin is installed correctly by entering an example action in a topic. For example:
   %ACTION<nop>{who=TWikiGuest,due="1 Jan 2003",open}% Example action
to expand into a working entry. Once I figured out that it was intentionally non-operative (after putting debug statements into the .pm file), I added the following:
   %ACTION<nop>{who=TWikiGuest,due="1 Jan 2003",open}% Example action
   generates:
   %ACTION{who=TWikiGuest,due="1 Jan 2003",open}% Example action
   which looks like this if the plugin works:
AssigneeDue dateDescriptionState
TWikiGuest Wed Jan 1 2003 Example action open

which generated incorrect HTML that looks like:

&lt;ul>
&lt;li> Add &lt;code>&lt;b>Plugins.ActionTrackerPlugin&lt;/b>&lt;/code> to the &lt;code>&lt;b>INSTALLEDPLUGINS&lt;/b>&lt;/code> variable in &lt;a href="/twiki/bin/view/TWiki/TWikiPreferences">TWikiPreferences&lt;/a> (or any &lt;span style='background : #FFFFCE;'>&lt;font color="#0000FF">WebPreferences&lt;/font>&lt;/span>&lt;a href="/twiki/bin/edit/Plugins/WebPreferences?topicparent=Plugins.ActionTrackerPlugin">?&lt;/a> topic).
&lt;/li>
&lt;li> You can test if the plugin is installed correctly by entering an example action in a topic. For example:
   %ACTION{who=TWikiGuest,due="1 Jan 2003",open}% Example action
   generates:
   &lt;table border=2>&lt;tr>&lt;th>Assignee&lt;/th>&lt;th>Due date&lt;/th>&lt;th>Description&lt;/th>&lt;th>State&lt;/th>&lt;/tr>&lt;tr>&lt;td> &lt;a href="/twiki/bin/view/Main/TWikiGuest">TWikiGuest&lt;/a> &lt;/td>&lt;td> Wed Jan 1 2003 &lt;/td>&lt;td> Example action &lt;/td>&lt;td> open &lt;/td>&lt;/tr>
&lt;/li>
&lt;/ul>
&lt;/table> which looks like this if the plugin works:

note where the </table> is. I'll try to track this down tomorrow, unless you beat me to it, I'm too tired just now. Also is there some reason that this showed up as a table rather than as the example above? Did I miss some setting?

Also does % ACTIONSEARCH{who=TWikiGuest,open}% only search the TWiki web where it is used, or does it search all webs? I have the above ACTIONSEARCH in my TWiki homepage in the Main Web, and the action is defined on the action tracker home page in the plugins web. Should I be seeing something other than the table heading?

Hmm, this looks like it might be a ModPerl'ism. I just managed to get it to work on my home page for only one refresh 8-(.

Also is it required to start on a new line? I can't get it to work on the Action Search Plugin home page without it starting its own line. If I put the % ACTION...% on its own line its fine, but any other non whitespace characters on the same line (e.g. *) causes header only display.

BTW I'll check out your new updated version tomorrow as well.

-- JohnRouillard - 07 Jan 2002

ACTIONSEARCH tags embedded in a page only search the current web. I was thinking of putting an "allwebs" boolean in but I didn't want to make it the default because it degrades the performance too much on very large TWiki's (like the one at work).

I don't know why it doesn't recognise %ACTION in the middle of a line; I'll investigate tonight.

I noticed that I had to restart the server after installing at work. I suspect this is also a modperl issue, but I don't really know modperl well enough to say.

Actions are generated as tables. This was in response to a specific requirement from our development teams, who wanted the printed version of the action to REALLY STAND OUT . It also allows me to use the exact same code for formatting %ACTION and %ACTIONSEARCH. The li ul in the middle of the table is strange; I think I have to revert to generating the html for the table all on one line. After generating the action table the page is still run through TWiki::Func::render which must be where the munging is happening. It's very difficult to work out where in the Plugin lifecycle different types of reformatting are done; the help info in the EmptyPlugin is not very helpful.

I'll put a working example into the ActionTrackerPlugin page when I debug the points you highlight above.

Many thanks for testing!

-- CrawfordCurrie - 08 Jan 2002

How about a webs="weba,webb,webc,webd", or webs="allwebs,hiddenweb1,hiddenweb2" type of option in the ACTIONSEARCH. If you specify the webs the search should apply to, it should reduce the performance hit on the web search.

-- JohnRouillard - 08 Jan 2002

I just uploaded 1.1, which adds the web= and a topic= attribute to the action search. There are also some bugfixes, found after testing on Solaris. I believe I have now eliminated all UNIX dependencies, so it should work on other types of server (I haven't got one to test on).

-- CrawfordCurrie - 11 Jan 2002

I'm trying to use this on cygwin (Win2K). Looks great, but I can't get the web=".*" bit to work in the ACTIONSEARCH. Any ideas? Otherwise a great plugin, I can see everyone going to love me for installing this one wink

-- TomMcMillen - 16 Jan 2002

Possibly; there's a known problem in lib/TWiki/Plugins/ActionTracker.pm in "handleActionSearch". I thought it only affected multi-web searches on the same page but without detail, I can't be sure. Substitute the following for this function:

sub handleActionSearch {
  my $expr = shift;

  # Filter on the search expression
  my $actions = ActionSet::allActionsInWebs( $web, Attrs->new( $expr ));

  return $actions->formatAsTable( "href" );
}
If that cures it, I'll upload the fixed version.

Since you're running on W2K you might also check that the 'egrep' issue noted on the ActionTrackerPlugin page isn't affecting you, or that I haven't unintentionally introduced some other UNIX dependency. I don't have anything other than Solaris and Linux Apache servers to test on.

If this doesn't help, please let me know some more detail..... are there any messages in the Apache log? In twiki/data/error.log or warning.log? Do the test scripts run?

-- CrawfordCurrie - 17 Jan 2002

I checked the egrep, no problems there; changed the handleActionSearch as above and it works fine now, thanks.

-- TomMcMillen - 18 Jan 2002

Known problem: reported by CoreyFruitman

Form contents get lost over invocations of editaction.

Analysis: It appears that the 'preview' script initialises the form contents from the old topic, and then overwrites them with the form data from the new topic text. Since the new topic text in the deriviative script 'previewaction' has no form data, it innocently clears those fields.

Workaround: Edit the script 'previewaction' and comment out the line that reads '&TWiki::Form::fieldVars2Meta( $webName, $query, $meta );'

Is it really correct behaviour that if data for a form field is NOT defined in the new topic text then that field gets cleared? Seems a bit draconian to me....

A fixed version of ActionTrackerPlugin will be available shortly.

-- CrawfordCurrie - 14 Feb 2002

New bug I think. If I declare a non-wiki user email address in a custom group, mail is sent fine. If I try to declare a non-wiki user's email on-the-fly (i.e.: who="someone@somwhere.com"), the script will say "No address found for someone@somewhere.com" when run from the command-line (and works fine if a wiki user or custom group is used at the command line).

Very cool plugin. It would be nice if something similar could be integrated into WebNotify, a third entry on a user-line to pick a pre-defined schedule. We're going to try using this plugin for exactly that reason, to allow people to pick custom schedules.

-- MikeMaurer - 29 Apr '02

I like this plugin. One change I'd like to suggest is to add a column to the results of ACTIONSEARCH to list the web the action was found in. Knowing what project (web) the actions apply to would make them easier to understand.

-- DaveAlsup - 03 May 2002

Got the plugin installed fine and the actions show up perfectly in the page. Having problems when running the actionnotify script though. I run it with the args "open,late" but get the message:

Use of uninitialized value in concatenation (.) at ../lib/TWiki.pm line 1349.
Use of uninitialized value in concatenation (.) at ../lib/TWiki.pm line 1350.
Use of uninitialized value in concatenation (.) at ../lib/TWiki.pm line 1349.
Use of uninitialized value in concatenation (.) at ../lib/TWiki.pm line 1350.

Any ideas on whats going wrong?

-- NathanReeves - 07 May 2002

Dave: if you "hover" your cursor over the "edit" link you can see the web name in the url there. Of course, this requires you to be "url savvy".

Nathan: Twiki generates a lot of these messages; I don't think they are harmful. Is the search returning the expected results? Have you run the tests?

-- CrawfordCurrie - 08 May 2002

Re the concatenation messages - these are just warnings but IMO should be treated as bugs, since they indicate something a bit odd. They could also fill up logs on high volume sites. If anyone sees these, please log a bug on Codev.BugReports and be sure to specify the TWiki version you are using (can't see a concatenation on those lines in Dec 2001 code).

-- RichardDonkin - 09 May 2002

I am getting actions from pages that I have moved into trash. Although this is not a major problem as they can still be closed manually. I was wondering if the plugin could be modified in order to prevent it searching the trash page in the first place.

-- PaulBaron - 30 May 2002

It's not the plugin but the actionnotify script that's causing this. You need to modify the command line to the actionnotify cron so that it doesn't search Trash. actionnotify uses the same attributes as %>nop>ACTIONSEARCH% to control the search. I'm pretty sure that something like:

actionnotify web=\"Trash\",open,late

would work, though I confess I haven't tried it, and my brain can't cope with the required ("not Trash") RE.

-- CrawfordCurrie - 31 May 2002


Proposal for improving notification of state changes in actions

Many actions can be closed silently (i.e. they are aides memoire for the assignee) but other actions require notification of interested parties when the action is closed.

In the past it has been assumed that this is handled by intelligent formulation of the action (i.e. don't just write "Put the dog out", write "Put the dog out and tell your wife that you've done it"). However this has not happened in our environment and there is a perception that automation may be able to help.

My proposal for improving action notification would be to use the attendee list for a meeting. In essence, meeting minutes always have a line starting

  • Attendees:

at the top, with a list of wikinames of people at the meeting. For example,

%ACTION statements would have an optional "notify" field that, when the action state changes, would result in a state change notification message going to the attendees.

%ACTION{who=PeterThoeny,due="25 dec 2002",notify}% Arrange world peace

Note that only people list in the " * Attendees: " line would be notified, but the REAL list of attendees could be formulated as:

* Attendees: Main.PeterThoeny
* And: Main.RichardDonkin, Main.NathanReeves

In this case only Peter would receive state change notifications for this page.

An added wrinkle would be to provide an optional value to the notify; this would ignore the attendees list and notify only the named person(s); for example:

%ACTION{who=Main.CrawfordCurrie,due="16 mar 2003",notify="PeterThoeny,RandyKramer"}% Complete on-site survey of TWiki adoption in the Hawaian Islands smile

(Apologies for the abuse of random names picked from this web...)

A further suggestion is that instead of "Attendees:" only, some other keys could be used for different sets of people:

* Trumpton: HughPugh, BarneyMcGrew, WindyMiller
* Bears: PaddingtonBear,RupertTheBear

%ACTION{who=KikiFrog,due="21 May 2002",notify="@Trumpton,@Bears"}% Kill and stuff JarJarBinks

which of course suggests the extension:

%ACTION{who="@Bears"......

Anyone fancy taking a crack at this?

-- CrawfordCurrie - 21 May 2002

This is a great plugin. I finally took the time to install it at work.

Some suggestions:

  • Make the plugin XHTML conform
  • Change the syntax to the standard TWiki style, e.g. use only name="value" parameters (not empty aka boolean parameters, and not without double quotes, and space instead of colon). Make the plugin understand both, but document only the standard syntax. This is to avoid confusion with the users (no need to learn which plugin accepts what syntax).
  • Changes in syntax: Empty parameters are replaced with a state="" parameter. That is, change:
    • open to state="open"
    • closed to state="closed"
    • late to state="late"
  • Do a lazy loading of required Perl modules to not impact the performance on topics that do not have any actions.
  • Add a query-by-example form to the plugins topic. This requires some code changes to allow parameters with empty values like topic="".

Contribution:

All suggestions are done and included in the attached zip, the diffs are in file diffs.txt. I ZIPed it up in a hurry and forgot the scripts in twiki/bin (but they are in diffs.txt). Crawford, if you have time could you incorporate that back into your code base.

Benchmarks:

  Plugin is:
Topic not installed disabled enabled optimized
WelcomeGuest 2.79 2.90 2.95 2.79
TWikiRegistration 1.25 1.35 1.36 1.27
ActionTrackerPlugin 1.44 1.55 1.58 1.58

There is no measurable performance impact for topics that have no action items.

Query-by-example action search example: (with new syntax; form is included in updated ActionTrackerPlugin topic)

Who:
State:
Within: days
Web:
Topic:
 
%ACTIONSEARCH{ who="" state="" within="" web="" topic="" }%

Code dependencies:

There are core code dependencies other then TWiki::Func. Granted, this is because the plugin API is not sufficient for the functionality of this plugin. You could study the EditTablePlugin, it has forms embedded in regular TWiki topics, that way you would not need the scripts in twiki/bin (except for actionnotify)

Bug:

The action search ignores the NOSEARCHALL web preferences flag, thus it does search all webs. This is a security issue. Ideally the TWiki search should be used / enhanced if not sufficient for the plugin.

-- PeterThoeny - 29 Jun 2002

Phew! Terrific analysis, thanks Peter! Unfortunately time is one commodity I'm very very short of just now; and we've just announced a further 7,000 redundancies which isn't going to help.

It's not hard to make it obey NOSEARCHALL; I'll add this to the (growing) list of updates I have to do.

(As for the attributes, I'd rather have seen you extend the default syntax to the richer superset; the Attrs.pm module is easily re-usable.)

-- CrawfordCurrie - 01 Jul 2002

Regaring attributes, I want to spare my 1000 TWiki users at work from learning a new syntax. That's why I changed the plugin description accordingly and changed the plugin code to accept the original and modified syntax. That way your users and my users should be happy wink

-- PeterThoeny - 02 Jul 2002

Ah, the concept of 1000 happy users is alien to me..... in any sample that big there's always one unhappy one! The reason that I developed Attrs.pm in the first place was that my users were not happy with the attribute syntax. I realised after I wrote my previous comment that of course it is a different model, not just an extension, and Attrs.pm didn't properly support all the existing syntax. Mea culpa; I accept your fix. Of course fixing Attrs.pm will also fix all my other plugins, as the module is shared wink .

On the NOSEARCHALL issue. I'd love to have used the TWiki search engine, but I had real trouble working out how to interface to it cleanly; I certainly couldn't do what i wanted through Func. Anyway, I fixed the NOSEARCHALL issue in the plugin code.

BTW, I am in the process of making a number of (user requested) changes:

  1. (Optional) action edit brought up in a new browser window
  2. Register for notification of an action state change
So your comments are really timely. But how do I make perl modules lazy load (writing these plugins was how I learnt perl; I'm still a long way from being an expert!)

Finally, I'm sorry about the code dependencies, but I couldn't see how to work around them. I've tried hard to minimise them, and replacing with appropriate TWiki::Func calls when available should be trivial. Note that I've been forced to add yet another dependency, on $TWiki::rcsRevCmd, recently. I'd really like a cleaner interface......

-- CrawfordCurrie - 03 Jul 2002

Lazy loading: This is in my code change. It is usually a simple require Some::Lib in an eval statement. There is a complication because TWiki changes the default directory at run time and the path to include TWiki libs are relative, causing lazy loading of TWiki libs to fail under ceratin circumstances. My code change does address this problem.

Preview: Changing actions should be a quick action, it would be nice to eliminate the preview cycle. Check out the EditTablePlugin for a possible solution.

-- PeterThoeny - 03 Jul 2002

I have just installed ActionTrackerPlugin, and am starting to make use of it. It immediately struck me that it would be even more powerful if it were harmonized with the CalendarPlugin. %ACTIONSEARCH{...}% could have an option to return actions as a bulleted list, and in turn the CalendarPlugin would format the list of action items as a calendar of due dates.

There is no need to change the default search format, just provide an option to allow leveraging the CalendarPlugin. Symbiosis between plugins can be a very powerful thing.

-- DaveBoulton - 07 Jul 2002

I made a few fixes compared to the previous one:

  • fixed bug in "late", showed also closed ones
  • fixed a bug of not found lib when editing an action, introduced by my previous changes.
  • allow spaces in actionnotify; changed plugin topic to reflect that
  • fixed warning in TWiki.pm caused by missing parameter in TWiki::Func::expandCommonVariables()
  • many XHTML fixes

ActionTrackerPTh2.zip has the latest files and contains the diffs to Crawford's 14 Feb 2002 version. Please note that this is not the distribution package, it is intended for the plugin author.

-- PeterThoeny - 09 Jul 2002

Idea: A nice little enhancement would be if the Plugin generates TWiki tables instead of hardcoded HTML tables. That way we could sort the tables based on the TablePlugin.

Fix: A small fix to allow an empty who parameter to query for "any person", for example in a query-by-example form. In sub matches of Action.pm:

    if ( defined($a->get("who")) ) {
      my $who = $a->get("who");
      if ( $who ) {
        $who = canonicalName( $who );
        return 0 unless ( $this->{WHO} eq $who );
      }
    }

Diff to my previous ActionTrackerPTh2.zip version:

177,178c177,181
<       my $who = canonicalName( $a->get("who") );
<       return 0 unless ( $this->{WHO} eq $who );
---
>       my $who = $a->get("who");
>       if ( $who ) {
>         $who = canonicalName( $who );
>         return 0 unless ( $this->{WHO} eq $who );
>       }

-- PeterThoeny - 16 Jul 2002

yet some more fixes. Changes compared to the previous ActionTrackerPTh2.zip file:

  • several XHTML fixes
  • allow an empty who parameter to query for "any person"
  • e-mail as Content-Type: multipart/alternative, e.g. is in plain text and HTML format so that non-HTML e-mail clients can read the message and get the URLs.

ActionTrackerPTh3.zip has the latest files and contains the diffs to Crawford's 14 Feb 2002 version. Please note that this is not the distribution package, it is intended for the Plugin author (but could be used to replace the installed file).

-- PeterThoeny - 16 Jul 2002

Srry Ptr, wrk gttng n th wy, n tm t vn typ vwls..... will get there...

-- CrawfordCurrie - 17 Jul 2002

I knw wt y mn, dnt wrry b hppy smile

I am thinking of looking into eliminating the preview cycle, in a similar way like done in the EditTablePlugin. Shall I hold off with that and wait for your next version? In case you have not started with your enhancements I could start doing this.

-- PeterThoeny - 17 Jul 2002

All the changes I've been working on for state change notification are in ActionNotify.pm, Action.pm and the actionnotify script; the only other thing I've touched recently was to add optional JavaScript to Action.pm to bring up the edit in a separate browser window - those changes were small and could easily be repeated. So please, do go ahead and eliminate the preview; I'd love to see that done (as would my users!).

-- CrawfordCurrie - 18 Jul 2002

The latest attachment has Peters changes incorporated and:

  • Updated the test suite (strange; that seemed to missing from the updates ;-))
  • Included some functionality my users have been badgering for:
    • Editing can (optionally) take place in a separate browser window
    • One for all you progam controllers out there! actionnotify can detect changed actions (since some delta time) and notify interested parties of the change. Still untested in a "live" environment, so there may be wrinkles, but comments are very welcome.

-- CrawfordCurrie - 21 Jul 2002

Factored out the discussion of TWikiForRequirementsManagement.

-- ThomasWeigert - 21 Jul 2002

ActionTrackerPlugin uses its own Attrs object. Sadly this conflicts with the creation of the Attrs object in the TocPlugin. This is a basic namespace collision problem. I suggest changing the package declaration at the top of the ActionTrackerPlugin/Attrs.pm file to read:

package ActionTrackerPlugin::Attrs;
Then change the few places:
... Attrs->new()
occurs to read:
... ActionTrackerPlugin::Attrs->new();
This will get around the problem of duplicate namespace. Moral of the story: Make sure you qualify the name of your objects with at least your package name. A better qualification is package Plugins::ActionTrackerPlugin::Attrs;, but that's more to type.

This is cheap insurance against having your plugin get really wierd because some other plugin redefined your objects. (No, of course I have never had this happen to me 8-)).

You can detect this problem because you will get tons of "... redefined at" messages in the web server error logs.

-- JohnRouillard - 27 Aug 2002

Thanks John! I was wondering what was causing those messages. I'll fix it ASAP. (Mummy! Mummy! I don't like perl! Can I have my Java back please! smile )

-- CrawfordCurrie - 28 Aug 2002

One more for you. At line 162 of ActionSet.pm you do a:

    my @weblist = grep !/^\.\.$/, readdir DIR;

I changed this to read:

    my @weblist = grep !/^\./, readdir DIR;
this change elminates any files (.htaccess, .htpasswd) and any directories (.session) from being processed by actionnotify. This eliminates an error of "egrep: *.txt: No such file or directory" from being produced. The .session directory is used by the SessionPlugin.

Since webs don't (shouldn't) start with '.' I consider it a safe change. Also as an optimization you may want to eliminate directories that start with "_", e.g. _default.

Its too bad there isn't a TWiki::Func:getAllWebs to make what you are doing easier. I thought you could use TWiki::Func::webExists(webname) to determine if the web exists and should be scanned, but I am torn about that. I can see somebody not wanting to list the web, and using webExists to hide its existence, yet still want it to be scanned for actions. Then again that may not be an issue. I am not quite sure what goes on under the covers with respect to web types public/private etc.

Also when would you consider moving these test release to the ActionTrackerPlugin page. I think most people would miss the newest ones if they were just checking the main plugin page (like I did. I am still running the original one on my new server not the newer ones on this page :-(, so my issue above may have already been fixed).

-- JohnRouillard - 28 Aug 2002

My release strategy is dictated by my experience; I test using automatic unit tests first, then test on a constrained installation, then on a live installation. I'm in "phase 3" at the moment, but have been forced to concentrate on making money the last few weeks. There is a known bug (relating to the pop-up edit window) I still need to fix before I "release". The issues you highlight above are new to me, many thanks for finding them!

-- CrawfordCurrie - 29 Aug 2002

At long, long last, I have found the time to finish all the updates. A new version is available from ActionTrackerPlugin which incorporates many of the changes discussed above. I haven't completed testing of changedsince, but I hope to in the next couple of days.

-- CrawfordCurrie - 26 Sep 2002

Thanks for incorporating the changes and for enhancing the Plugin. I will install and test it at work when I find time.

Just had a quick look at the code, looks good. The Plugin honors the NOSEARCHALL flag in an action search and ignores it in actionnotify as expected. A small fix for ActionSet.pm, sub allActionsInWebs, changes indicated in red:

    foreach $web ( @weblist ) {
      if ( -d "$dataDir/$web" && $web =~ /^$webs$/ ) {
        $web =~ /(.*)/; # untaint
        $web = $1;
        # Exclude webs flagged as NOSEARCHALL
        my $thisWebNoSearchAll =
          TWiki::Func::getPreferencesValue( "NOSEARCHALL", $web );
        next if ( $thisWebNoSearchAll =~ /on/i );
        my $subacts = allActionsInWeb( $web, $attrs );
        $actions->concat( $subacts );
      }
    }

Suggestion: At work we have people fill in a comma separated list for who="" which does not work. I think this would be a logical enhancement: Assignees can be defined by a group topic (current spec) or by a comma delimited list of users or e-mail addresses (proposed enhancement). The comma delimited list is quicker to type and you have a visual clue who is the assignee.

BTW, this topic is getting long. If someone has time, factor out the solved items to ActionTrackerPluginDevArchive.

-- PeterThoeny - 27 Sep 2002

The comma-separated list should work - certainly the code's there to support it. We actively discourage more than one actionee here; such an action is not SMART - Specific, Measurable, Achievable, Realistic, Timescaled - because the responsibility isn't Specific. Despite this I have seen it used a couple of times.

-- CrawfordCurrie - 30 Sep 2002

The comma-separated list does not work, at least in our ActionTrackerPTh3.zip release. Your SMART argument is good, though I see a comma-separated list as a shortcut to a group. When you have just two people who need to follow up on something it is quicker to specify two names instead of creating a group.

-- PeterThoeny - 24 Oct 2002

I would like to thank Crawford for this great Plugin, we depend more and more on it to follow up on action items. Our meeting minutes templates have sample ACTIONs defined, so the barrier to entry is low.

In addition we are using it also to sign off documents, this is now an integral part of our product release process. A product release notebook has a table with links to attached documents (like an MRD). A small Plugin we did allows us to create a signoff topic for each document that needs a sign-off. The sign-off topic text changes on the state:

  • Not ready (create) : Sign-off topic does not exists yet. The create link allows you to create the topic. The topic name is based on the notebook name and doc type to sign, e.g. RelNotebook999SignOffMRD. The text is based on a sign-off template specifying ACTIONs for managers who need to sign off.
  • Signature pending : Sign-off topic exists but some signatures are pending. Signing a doc means to edit an Action and close it.
  • Complete : All managers have signed off the document.

This approach is soft security, anybody could sign off for a manager. This works though because of the WikiCulture and revision control (you can verify who signed).

-- PeterThoeny - 24 Oct 2002

I got this feedback from an engineering director.

The action tracker would be much more valuable if it supported the following:

  1. Add a results description text field. This should be separate from the action description
  2. Separate field for "creator". Enables possibly sending creator e-mail when state changes.
  3. Add field for Date Closed. If you are trying to look back to see when something was closed relative to when it was due (was it late?). It can be figured out from the topic version history but this is a pain. (less critical enhancement)
  4. Add field for Date Created (less critical enhancement)

Not sure yet, we might put in a resource to do these enhancements (besides the elimination of preview I mentioned before).

-- PeterThoeny - 24 Oct 2002

Great feedback, thanks.

  1. We tend to record results by editing the text of the action. It works pretty well. If we were to split the action text and results, wouldn't it make the syntax of the ACTION tag rather unreadable?
  2. There is already a field "notify=WikiName" that, when used in conjunction with actionnotify, can notify of state & text changes [New]
  3. Date closed; interesting, hadn't heard this one before. Now you come to mention it, I've noticed people putting "close on" dates into the action results, so maybe there's a genuine requirement here.
  4. Date created; same thing. Actually, I think 3 and 4 could be done using the code I wrote for actionnotify, and looking back to find the revision where the action was created and the revision where the state changed.

The problem with maintaining any sort of "action revision history" is that actions aren't only changed through the action editor; they can also be changed by editing the %ACTION{}% tag itself.

I'd love it if someone were to eliminate preview.

-- CrawfordCurrie - 25 Oct 2002

Theres a bug in the ACTIONSEARCH with respect to NOSEARCHALL. Basically, ACTIONSEARCH won't even search the current web if it is set as NOSEARCHALL. The problem is in ActionSet::allActionsInWebs() it does a

        next if ( $thisWebNoSearchAll =~ /on/i);

Before it does the search. Seems like it should add a check to see if $web is $theweb first and do the search if they are equal.

-- DougAlcorn - 27 Oct 2002

Thanks Doug. I'm surprised no-one noticed this before. I'll fix and post a new version, hopefully tonight.

-- CrawfordCurrie - 28 Oct 2002

  1. First, a praise: this is a very useful plugin, and thanking the author for providing it.
  2. Problem: as distributed, the bin/editaction script is non-executable, so after installation, when a user tries to edit an action, s/he would get an internal server error. Could it be because I was unzipping onto a Linux system? Suggestion: please rebuild a new zip with that script set to be executable. And please add a tip for Unix users to chmod that script to executable in case of trouble.
  3. CSPAN dependencies: should add Time::JulianDay, and Time::Timezone
  4. I'd like to second an earlier suggestion to add a Date Closed field.

-- HamNguyen - 07 Dec 2002

Suggested changes to version 26 Sep 2002 for:

  • NOSEARCHALL problem not finding actions in the current web,
  • cleaner taint handling,
  • XHTML fixes

Crawford: I have a question regarding the changedsince parameter in actionnotify. The doc states that "functions of the script, as described above, are disabled". I would like to make use of the new "notify" field which is only valid with the changedsince parameter. I would like to notify all actionees of open items within 8 days and all others who are in the notify field of changes since my last notification (on Mon, Tue and Wed). This without notifying a person twice for the same action. Is that possible?

-- PeterThoeny - 16 Dec 2002

I'm facing some issues with the ActionTracker Plugin,

  1. when I try to edit the action item in the opera browser the hidden form elements pretext & posttext are shown in the browser.
  2. Also the action items on a single topic when it grows in number and lot of people trying to edit their action items has to wait till the other person currently editing the file to release the lock. Can this logic be changed and we maintain action items in separate files?
  3. Should we have an add action item which will show up the edit form using which the users can easily add action items instead of remembering the action tags?

While the first two are issues, the third point is a wish list.

-- HariKrishnamoorthy - 19 Dec 2002

Some permission problems.

I created simple record: %ACTION{ who="Main.LeanidNazdrynau" due="15 Jan 2003" state="open" notify="Main.LeanidNazdrynau" }% Task 1

Now when I click edit in this table I have new page with next error: "You do not have permission to change topic ActionTracker?". (from bin/editaction line 70-74) Bu I can edit this page from TWiki Edit interface. In this new edit page TWiki thinks I am TWikiGuest?, but I am definitly not. So I have opened chnage access to my page to everybody and then I got this edit window. But now when I click "Preview Changes" nothing happens.

Did I miss something? I am using z_auth module for NIS authentification from apache.

-- LeanidNazdrynau - 19 Dec 2002

Leanid: Make sure to put editaction and previewaction under authentication. Simply take the edit section in twiki/bin/.htaccess as a template.

-- PeterThoeny - 21 Dec 2002

Bug Create two %ACTION{ }%'s separated by a blank line. If I edit the second action (via editaction), the Preview shows the second action oddly embedded within the first. The fix requires a trivial patch to previewaction (to insert a newline).

I also made a few changes in editaction to eliminate warnings that popped up in my Apache error_log:

  • "my" variable $tmpl masks earlier declaration in same scope at /var/www/html/net/twiki/bin/editaction line 94
  • Use of uninitialized value in concatenation (.) or string at ../lib/TWiki/Store.pm line 1147
  • Use of uninitialized value in substitution (s///) at /var/www/html/net/twiki/bin/editaction line 157

-- AnthonPang - 31 Dec 2002

I've been remiss in keeping up to date, so here's a bunch of comments/answers all at once.

A dateclosed field shouldn't really be necessary, because if you really want to know you can check the history of the page containing the action (good excuse, eh?). Actually, it shouldn't be too hard to do, but I'm afraid I regard it as low priority because there's a workaround.

Peter, the changedsince search is distinct from the actionsearch, and filtering the way you want would be hard.

I haven't tested with Opera.

No, I'm not going to change the logic to maintain action items in separate files. The way it works is quite deliberate; when you are taking minutes in a meeting, you just whack the action in-line when it arises. To maintain in separate files, or in meta-data, would require some kind of forms interaction which would be unwieldy and slow.

On the plus side, it would make changedsince a heck of a lot easier. It was fairly tough to implement because relating an action in a previous incarnation of a topic to the same action in the current version is quite hard, because if new actions have been added the action numbers change.

Anthon, I'll have a look into your report. I thought I'd caught all the error reports.

-- CrawfordCurrie - 30 Jan 2003

At long last, it's in CVS.

-- CrawfordCurrie - 02 Feb 2003

The Action Tracker plugin is great. I'm finding it very useful. I have a suggestion that might make input of the actions easier for a long list of action items. Would it be possible to have an Action Tracker table -- the table would have columns corresponding to the expected parameters - who, due date, description. Something like:


%ActionTrackerTablePlugin%
| *Action* | *Owner* | *Due* | *State* |
| Implement a plugin | WilliamHertling | 2003-02-27 | open |

The benefit would be smaller, more editable syntax for large lists. And preferably it would take advantage of the table plugin to allow sorting, and/or the edit table plugin for editing.

-- WilliamHertling - 11 Feb 2003

I love the Action Tracker plugin! I think it would be even better if the following features were added:

  • Date closed field
  • Allow multiple owners in action "who" field
  • Allow Wiki name rather than e-mail address in group pseudo-user topic
  • Allow multiple owners in action search "who" field or somehow automatically find groups I am a part of. I want all of my action items in one table.

-- BrianBatchelder - 06 Mar 2003

I'm working on a new version that takes into account some of the comments above. Specifically, I've so far added unique IDs to each action, and creator, date closed and closed by who fields. This has necessitated use of the beforeSaveHandler in the lpugins library so it won't work with earlier than Feb 2003. I've also changed the action editor so you can optionally set it to save without preview. I've also made action appearance programmable, so you can select which of the new fields you want to see. I'm still working on searches using the new fields. Watch this space for the new version.

-- CrawfordCurrie - 15 Mar 2003

I've also encountered the "nested table" effect when 2 actions get placed onto one line. A more important issue however is that if you are using the GnuSkin, it doesn't have a preview button, just save changes directly, so using the edit field to update an action doesn't work (you just stay on the pop-up window. Other than that, this plugin has been very helpful in the last few weeks.

-- ChrisHogan - 21 Mar 2003

At work we took the latest Plugin version and did extensive debugging and changes. One fix was the nested tables; an extension was a new Notify field in the edit form and in view. I will post the changes when I find time.

-- PeterThoeny - 22 Mar 2003

Chris: because I'm switching to using the new plugin hooks, the GnuSkin issue goes away. I alsi fixed the nested table effect. However I'm not making any more changes/fixes until I've seen what Peter has done; no point in duplicating effort.

-- CrawfordCurrie - 24 Mar 2003

OK, attached is ActionTrackerPTh4.zip with our latest changes. It is not a regular package but contains all files. From our internal change request tracker log:

Bug fixes:

  • not all parameters are passed into the actionnotify script
  • several regular expression errors
  • error emailing out Actions when the Assigned To parameter contained more than one person.
  • changedsince variable input error
  • changed email Text appended does not work well if changed text is shorter than original description.

Additional functionality was also added to the plugin.

  • Can search on the notify in an ActionSearch
  • Notfication of change emails and actions email are sent as one
  • Notify field was added to display and edit

Changes done by PaulineCheung

-- PeterThoeny - 29 Mar 2003

Hi there, I'd like three more features:

  1. Ability to add more columns on a per-item basis. e.g. some people want priority, others want something else.
  2. Ability to sort columns on the action search table
  3. Query by search to be inserted using a %ACTIONSEARCH{qbe}%
  4. Ability for action search to be able to show the number of days left!
  5. Ability to arrange columns on the table output by ACTIONSEARCH
  6. I find it a bit wierd that the user data goes on the remainder of the line: after ACTIONSEARCH{...} text goes here ?

Nice plugin though, thanks. M.

-- MartinCleaver - 02 Apr 2003

  1. Already done in development tree
  2. Already done in development tree
  3. Example please?
  4. I'll think about this
  5. There's good reasons for it.

-- CrawfordCurrie - 03 Apr 2003

  1. , 2, 4: Cool, thanks.
  2. It appears that to provide QBE to my users I have to copy the HTML form out of the plugin page. It would be nice if there was a TWikiVariable to make that form appear.
  3. sure, okay.

WRT stuff in the dev tree, are PaulineCheung's changes in as well? If so I will download it from there. We really do need to have a CPAN module installer for TWiki and all the plugins!

-- MartinCleaver - 03 Apr 2003

No, PaulineCheung's changes aren't in yet. I may get a chance this weekend if Real Life doesn't get in the way. J'agree about the module installer. We're crying out for something like that.

-- CrawfordCurrie - 04 Apr 2003

Thought of another feature: add action button (to current table). Ta smile

-- MartinCleaver - 12 Apr 2003

I am in the process of introducing the Plugin to my TWiki installation. I would love to see two other links besides the edit link:

  • add new action in the same topic
  • delete this action in the same topic.
How does that sound?

-- MartinRaabe - 13 Apr 2003

If you want to add or delete actions from a topic, just click on the "Edit" link at the bottom of the page hehe!

-- CrawfordCurrie - 14 Apr 2003

Hello Crawford,

If I have 20 actions in 15 topics I would love to have a delete link to be able to delete this action.

Or if I could press on add link to open a new browser window being able to add another action just underneath the action I used the link from.
This would be cool !

-- MartinRaabe - 15 Apr 2003

The ActionTrackerPlugin is a great feature. However, what limits its usability is the lack of customizability. I have seen many action trackers being developed in our organization, and they all differ basically only by two aspects:

  • What kind of information is kept as part of the action, and
  • What states are being considered.
For example, many action trackers might want to keep data submitted, data closed, resolution, or comments as part of the action record.

This type of customizability would be easy to provide with the ActionTrackerPlugin, if it used a form to represent its information table for editing, rather than the hard-wired template.

A very simple route to get to a more flexible ActionTrackerPlugin is to replace the action storage and editing mechanism by the scheme that is used in SimpleTableEntryUsingForms. Most of what is done in that add-on could be directly used in ActionTrackerPlugin.

Besides the obvious code reuse, the benefits would be

  • User customizable action content
  • User customizable states
  • Action stored in meta-data does not interfere with topic text
  • Adding and deleting of actions without editing the topic

We only would have to constrain the user that certain fields are present (who, due, state, and notify) and that there are at least the values "open" and "closed" in the list of states. But the user could arrange the order of columns in the table and any additional columns as they see fit. We could even adjust the headings of the table via preferences.

Note further that actions tend to come in blocks, so having a table that can conveniently add and delete rows representing the actions is rather convenient.

A transition to such system would mostly involve removing code from the ActionTrackerPlugin and leveraging the meta data API to obtain the table values. (I realize that calling this "API" is quite a stretch as plugins do not have access to meta data, and therefore have to retrieve it from the topic using readTopicAction.)

I realize that a design goal of the ActionTrackerPlugin was to allow in-line recording of actions while minutes are taken, and that is well-supported by the current arrangement. However, there are other styles of working where actions are recorded separately and independent of minutes. The ideal situation would be if there were two kinds of action keywords (e.g., Action and ActionTable) supporting both modes of working. Both modes could be using the same API to the action storage and editing mechanism described above.

-- ThomasWeigert - 18 Apr 2003

I have attached below a new variant of the ActionTrackerPlugin. I have removed the hard-wired assumptions on how the actions are formatted in a table, and what fields an action may have. Instead, this information is taken from a form that can either be given in the plugin topic, or as a web preference.

Each action (actually, each ActionSet) will be rendered in a table with the columns as specified in that form. In edit mode, the field types and possible values can be specified, as in standard TWikiForms. All the features of TWikiForms apply here as well. However, certain fields must be present, namely the fields "who", "notify", "due", and "state", and state must have at least the two values "open" and "closed", albeit it may have more. One can add arbitrary fields to an action (keeping in mind that their names must be legal Perl words, but see the patch mentioned below). For example, an action might have a date it was initiated, a submitter, and a resolution. Or an action might have a comment field. Or one might want to create a dropdown menu for assignees, etc. etc. Columns are shown in the order in which they appear in the defining form (and thus can be arbitrarily ordered); the edit link always appears last.

The keywords used in the % ACTION{...}% clause are the same as the field names in the defining table. (Note that per TWikiForms, multiple words are collapsed into a single word. A usefull addition which makes this form, and others, work even nicer is PeterKlausner's patch to lib/TWiki/Form.pm in DynamicFormOptionDefinitions which allows renaming the field titles if the default titles are not desired, by using the [ [...][...]] syntax.

This version is backwards compatible with the ActionTrackerPlugin modulo any defects that might have escaped testing and the following:

  • The titles in the table have changed unless a patch to lib/Form.pm is applied. This is a consequence of the rule that field names are used as keys. (Warning: To make the titles match the original titles in the ActionTrackerPlugin, the supplied form leverages above patch. It is not needed, but then the names are not as nice.)
  • The background color for the table in the edit mode is the same as the background color for all forms in edit mode (instead of the yellow color now).
  • The EDITBOXWIDTH and EDITBOXHEIGHT preferences have no effect, as this is not supported by form rendering. Instead, the size of the edit box can be given as the size parameter of the corresponding field.

Note that I have reused the function form Form::renderForEdit to render the table in edit mode. I realize that this is technically not a good idea as plugins should not use functions not in Func, but this plugin already used other illegal functions. So I felt reuse is better than reinventing.

Using these modifications, actions can be rendered differently in different webs, and can display different fields in different webs. I'd like to extend this to allow actions to be shown different in the same web, by passing a form parameter with the action. The objective would be to differentiate between, say, issues and action items. Issues might have risks associated, while actions might have a resolution associated.

P.S. I have not tested this with editing in a separate window.

-- ThomasWeigert - 21 Apr 2003

I have extended below by an additional keyword in action searches, "notclosed". The purpose is that if one added extra states in the defining table, such as "postponed", for example, there still is a simple search that finds all action items that are not closed.

-- ThomasWeigert - 21 Apr 2003

Thomas, interesting and useful enhancements. On what version did you base your plugin? Is it the one posed by Crawford or Pauline's version?

-- PeterThoeny - 21 Apr 2003

Sorry, I should have been more explicit. My changes are based on the latest version on this page ActionTrackerPTh4. Note that I have not documented the changes in the plugin topic yet.

I made some further updates (the header color and the colors for late or bad fields are configurable from preferences). I also deleted the text that is printed when a due date is omitted (or ill-formed) as it is taking too much space in the table; the bad color is warning enough. I still want to make the generated tables sortable also, as for large tables one might want to sort on other than the due date.

-- ThomasWeigert - 21 Apr 2003

One comment... with my changes it is possible to view an action showing less than the fields that are present in the definition (by viewing it from a web that has a different form defining the action tracker). It is not a good idea to edit it in that form, as this would eliminate the fields not visible. To alleviate this, I am planning to change this so that the actions will always be edited with the form as defined in the web the actions are in, if there is a form defined for that web.

I am also thinking about adding the ability to define an action form with a search so that one can customize the fields shown in a search, independent from the defining form. Again, for edit one should use the original form.

-- ThomasWeigert - 22 Apr 2003

I just checked in a version that does almost everything described above except ThomasWeigert's forms - I'm still working on that. At the moment it has:

  • Arbitrary fields
  • The ability to search and sort on them
  • Definable formatting for actions, searches and mails
You can get it from CVS.

Thomas, in the course of this I had the problem that I wanted to 'type' fields. I thought you might have the solution, in the forms approach, but forms are missing some types (such as 'date'). Doesn't this present a bit of a problem in using the forms API to edit actions? Or did you find a way to extend it?

-- CrawfordCurrie - 27 Apr 2003

Crawford, does the recent CVS checkin also include the changes made in ActionTrackerPTh4.zip? I ask because we want to do some development on the plugin but I'm not sure what is the best codebase to work from right now. CVS is the obvious answer but if it's a moving target maybe one of these interim zips is best. Thanks.

-- GarethEdwards - 29 Apr 2003

OK, I checked out the CVS because it looks like the attribute support will do what we want.

I had to make some fixes to get the code in CVS running; the diffs are attached in GarethEdwardsDiffs30Apr2003.txt. These fixes are just sticking plasters, I think the final fixes will have to be much more carefully thought out and located, but this should help anyone trying to use the latest and greatest get up and running.

For those who are interested, the major bug is that the code that builds the ActionSet from %ACTIONSEARCH% was trying to match against the "header" and "format" attributes as well as the normal "who", "state" and suchlike. I've hacked in a substitution operation that removes these attributes from the string before the matching operation starts, but maybe that functionality should be in the ActionSet or Action object instead.

When the new Format is formed, I added a dummy zerolength string parameter to the constructor for the $changeFields formal to get the code to run. I don't know if this is valid or not in the context of the handleActionSearch method but it seems to work.

There were a few other typos in variable names that stopped the code operating that are fixed in the diff.

-- GarethEdwards - 30 Apr 2003

I've installed ActionTrackerPTh4. Works well, but one unpleasantness. In field 'who' you can enter wiki names without prefixing it with 'Main.'. In field 'notify' you must apply the prefix.

-- PetricFrank - 6 May 2003

I checked in a whole slew of new code on Sunday, that addresses this among many other things. There's one thing I need to do before releasing, and that is to sort out the e-mail gathering; there have been a number of changes in the wiki core than mean that my method for finding people can be a lot more efficient. I may also investigate hooking in LDAP services. Look for a new release sometime this week or next.

-- CrawfordCurrie - 07 May 2003

It would be good if there was a way of disabling the automatic linking of an action description as displayed in an action search result table back to the original definition of the action.

Automatic linking can be disabled in ordinary tables using the noautolink tag, so a mechanism similar to this or a new action search field to enable/disable the linking would be ideal.

-- RhonaMacDonald - 07 May 2003 (posted by GarethEdwards on her behalf - this topic could use refactoring to get the topic length down)

I'm very much looking forward to the new version, especially getting rid of the horrid preview cycle!

-- MartinCleaver - 08 May 2003

Aaargh! Stop throwing new requirements at me, or I'll never get it done! All the same, good idea Rhona. I'll probably finish up this weekend - as long as everything works - and unlock the codebase so you can contribute the fix hehe!

I'll have a go at refactoring after I release.

-- CrawfordCurrie - 08 May 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip ActionTrackerPTh.zip r1 manage 23.2 K 2002-06-29 - 03:01 PeterThoeny Changes done by Peter Thoeny
Compressed Zip archivezip ActionTrackerPTh2.zip r1 manage 29.8 K 2002-07-09 - 02:18 PeterThoeny Changes done by Peter Thoeny, updated
Compressed Zip archivezip ActionTrackerPTh3.zip r1 manage 31.2 K 2002-07-17 - 01:22 PeterThoeny Changes done by Peter Thoeny, more updates
Compressed Zip archivezip ActionTrackerPTh4.zip r2 r1 manage 36.2 K 2003-03-29 - 01:59 PeterThoeny Changes done by Pauline Cheung, more updates
Compressed Zip archivezip ActionTrackerPlugin.zip r1 manage 36.9 K 2002-07-21 - 15:18 CrawfordCurrie Incoporated Peter's changes, and made a few more..
Compressed Zip archivezip ActionTrackerTW.zip r5 r4 r3 r2 r1 manage 30.5 K 2003-04-22 - 04:22 ThomasWeigert Fields and layout defined by form
Texttxt GarethEdwardsDiffs30Apr2003.txt r1 manage 1.6 K 2003-04-30 - 14:02 GarethEdwards Diffs against CVS 30 Apr 2003
Texttxt diffToVer26_Sep_2002.txt r1 manage 4.3 K 2002-12-16 - 23:56 PeterThoeny Diffs to version 26 Sep 2002
Texttxt morediffs.txt r1 manage 1.7 K 2002-12-31 - 13:03 AnthonPang More diffs to version 26 Sep 2002.
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2003-05-10 - PeterThoeny
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.