create new tag
, view all tags

I installed this beta. It works well but - i do not get 'notify' mails anymore. If i start from command line

  ./actionnotify DEBUG changedsince=yesterday
i get a printout of the mail to be send, but noting receives on the mailbox (even DEBUG ic is not given). I also placed DEBUG = 1 into TWiki.ActionTrackerPlugin.txt.

The standard notifications driven via the status field sent via

  ./actionnotify web=....
are working.

Any hints ?

-- PetricFrank - 20 May 2003

I screwed up the notification code - I just found the problem last night - in such a way that if you have any open actions, you don't get mailed changes. I hope that's the problem you are seeing, but without more detail it's hard to tell.

If you use DEBUG on the command line the mail isn't sent, only printed. The idea is the output can be piped to a mail program.

UPDATE: evening of 20-May-2003

I just uploaded release candidate 2, which I trust fixes the problem you highlighted (though note that changes to actions that were created using the previous beta will not be seen). The changes are:

  1. UID handling has changed completely, because I found that the UIDs I was creating were too long to act as in-page anchors. UIDs are now numeric and sequential.
  2. Now supports <<EOF syntax for multi-line actions, at the price of actions embedded in actions - which is going to catch someone out, I know.
  3. I changed the "goto" bahaviour in the action tables so it now has a (go to action) link at the end of the action text. This was to address a request reported by GarethEdwards. It would be perfectly possible to change this link to an image, if anyone felt energetic.

-- CrawfordCurrie - 20 May 2003

Notification works now. Congratulations

Question: What is to do to get the self defined fields (the ones defined in EXTRAS) also being displayed in the notification mails ?

A bug in ActionTrackerPlugin.txt. In the sample demonstrating the <<EOF behaviour you should replace the '<<EOF' by '&lt;&lt;EOF'. Otherwise the text after the sample gets wrongly formatted.

-- PetricFrank - 21 May 2003

The tables in the notifications are built using the same headers and bodies as the tables in normal topics, so if you display them in 'view' you should see them in the notification. Well spotted on the << if everything else is OK, I'll fix that minor problem and upload to the main action tracker topic tonight (official release!)

UPDATE: evening of 21 May 2003

I found one minor bug where it was ignoring the orient=rows in an ACTIONSEARCH. I've added a test, and it now passes, so it's released! Get the latest version from ActionTrackerPlugin.

-- CrawfordCurrie - 21 May 2003

This all looks great - thanks Crawford.

A couple of comments:

  1. I'd still really like to have an 'Add Action' button at the bottom of the table.
  2. I added a request on MorePluginHooks for mailnotification - perhaps you can elaborate or refute the request as you see fit
  3. Having that pop-up window not disappear when completing is confusing.
  4. It would be nice to have a DemoUrl for the plugin. Peter only knows why we can't have the plugin installed at TWikiDotOrg, it would be so useful. Peter / anyone on the CoreTeam (CoreTeamGroup) - is it time now?

Thanks again.

-- MartinCleaver - 23 May 2003


  1. I was going to do it, but I just ran out of steam. Source is in CVS.
  2. I'll have a look.
  3. I know. Please, someone fix it - I can't!
  4. I can't provide a demoUrl, all my sites are behind firewalls.

-- CrawfordCurrie - 23 May 2003

In the interest of making it as quick and easy as possible to enter new actions, I wonder if it would possible to have the plugin recognize some non-ambiguous values without labeling the value. What I mean is making it possible to enter "%ACTION{ 06/04/2003 open }% task description" and have it simply recognize the date and status variables. I realize that this may be much more complicated to implement than it appears. It requires having the plugin recognize certain types of strings. Perhaps it would be plausible for specific date formats that could easily be recognized.

-- LynnwoodBrown - 23 May 2003

Good work!

  1. Its nice that we can leave out the parameters i.e. just write %ACTION{}%
  2. Another nice-to-have would be repeating tasks.

-- MartinCleaver - 26 May 2003

I've added a section at the bottom of this page called 'nice to haves'. Please add ideas here.

-- CrawfordCurrie - 26 May 2003

I am having a problem where any page that contains one or more action items will ignore the "---++" type formatting if it is the first line of the page (the ---++ is the first line -- not the action item). Anyone else notice this problem?

-- MarcusKellerman - 03 Jun 2003

FIXED 6 Jun 2003

Edit an existing action tracker item, save it and re-edit it- the old contents (text and status values) reappear in the edit dialog.

Remark: i've set NOPREVIEW = 1

Any ideas how to track this down ?

-- PetricFrank - 04 Jun 2003

Marcus: No idea, I'll try to reproduce.

Petric: I would guess you've got USENEWWINDOW = 1. This is probably due to browser caching (a never-ending problem). What browser are you using? Have you tried putting an 'expires' into the edit.action.tmpl template?

-- CrawfordCurrie - 04 Jun 2003

Yes it seems to be a browser cache problem. If i clean up the cache before re-editing the action tracker item all works well. I haven't had this behaviour up to now. And it appears only when editing action tracker items but not when i edit standard topics.

The browser is Netscape 4.78 (Win NT).

USENEWWINDOW is set to 0.

Where (syntax, etc.) to place this 'expires' into edit.action.tmpl ? Is that a standard HTML tag (i haven't found it in HTMLDOC web page) ?

-- PetricFrank - 04 Jun 2003

FIXED 6 Jun 2003

I've installed the 21 May 2003 release archive from ActionTrackerPlugin and now the EXTRAS functionality doesn't seem to work; the defined fields just don't get recognized. I'm investigating further just now but I'm kind of hoping a lightbulb goes off over Crawford's head...

-- GarethEdwards - 04 Jun 2003

We're looking at using ActionTrackerPlugin to keep track of required training. So, we have a new topic for each training request with action items for all the people who need to complete this specific training. The problem is the amount of typing that has to be done to add all the actions for all the people who need the training. Most training request pages will have over 30 action items on them that are all identical except for the assignee. I'm not opposed to writing some code. I'm just not sure I know what the best interface would be for simplifying the amount of work required to create new tasks.

-- DougAlcorn - 04 June 2003

We've found a fix for the bug with the EXTRAS handling. In Action.pm, there is a line in Action::extendTypes around line 192 that reads

   foreach my $def ( split( /\s*\|\s*/, $defs )) {
      if ( $def =~ m/^(\w+)\s*,\s*(\w+)\s*(,\s*(\d+)\s*)?(,\s*(.*))?$/o ) {

which needs to read

   foreach my $def ( split( /\s*\|\s*/, $defs )) {
      if ( $def =~ m/^\s*(\w+)\s*,\s*(\w+)\s*(,\s*(\d+)\s*)?(,\s*(.*))?$/o ) {

i.e. "\s*" needs to be added to the start of the second regexp. The preceding "split" leaves whitespace at the start of $def. Now, the implication of the first argument to split as I read it is that it should remove the whitespace but IANA Perl expert so I don't know where the disconnect is.

In other news, I'm seeing Mozilla doing weird things sometimes editing actions (not Netscape 4.7 or Opera) but I'm hot on the trail.

-- GarethEdwards - 05 Jun 2003

Petric, read http://vancouver-webpages.com/META/metatags.detail.html

Doug, is there some reason you can't just list all the names in one action? e.g. %ACTION{who="HayNewby,AbeGinner,AlEarner"}% Bang rocks together to create fire

Gareth, an obvious workaround is to not put whitespace after the | in the extras definition. I guess this is why the tests pass; I'll check tonight.

Evening update

Marcus' problem with headers was due to the javascript inserted for edit links not being terminated with a \n. To fix it manually find the "embedJS" function in ActionTrackerPlugin.pm, and put a newline (or \n) in the string after </script> thus:

// -->

Gareth's fix for EXTRAS is correct (for some extraordinary reason, it only happens if there is a space after the first | in the extras, not the subsequent |'s).

I haven't uploaded a new installation to the main topic, because I still want to see if I can fix the 'expires' problem, but the fixes for the above two problems are so trivial you may wish to do them manually in your installation. I have, however, updated CVS.

-- CrawfordCurrie - 05 Jun 2003

  1. I've added a couple of things to the table below, one of which to clarify what I meant about the MorePluginsHooks issue.
  2. Bug report, I'm afraid:

TWiki: Create Usage Statistics
* Executed by a guest or a cron job scheduler
* Statistics for Jun 2003
* Reporting on TWiki.Know web

  - view: 0, save: 0, upload: 0
Content-type: text/html

<h1>Software error:<h1>
<pre>Can't call method &quot;param&quot; on an undefined value at ../lib/TWiki/Plugins/ActionTrackerPlugin.pm line 391.
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

[Fri Jun  6 00:22:52 2003] statistics: Can't call method "param" on an undefined value at ../lib/TWiki/Plugins/ActionTrackerPlugin.pm line 391.

Now, 391 is in beforeSaveHandler:

390  my $query = TWiki::Func::getCgiQuery();
391  if ( $query->param( 'closeactioneditor' )) {

I guess that statistics is trying to save the WebStatistics file with the new data in it. I could do with knowing whether this affects anyone else and to get a quick hack or fix for it. Longer term the statistics stuff needs an overhall. IMO it should be a plugin anyway (See WebStatisticsShouldBeAPlugin)

-- MartinCleaver - 06 Jun 2003

More on the Mozilla weirdness I was seeing earlier. If, for example, the "pretext" field of the form ends in "&#10;" and Mozilla is being used to POST, the return from the Perl CGI module is lacking this final character. I'm investigating further to see if CGI.pm or Mozilla itself is at fault.

-- GarethEdwards - 06 Jun 2003

Thanks for the hint with 'expires'. I added in edit.action.tmpl this line using a date from last century and the problem disappears.

FIXED 6 Jun 2003 I had problems with notification using standard Wiki groups. After a lot of debugging i changed in the file ActionNotify.pm in the subroutine _getMailAddresses the line reading

  if ( $text =~ m/^\s+\*\s+Set\s+GROUP\s*=\s*([^\r\n]+)/so ) {


  if ( $text =~ m/.*\s+\*\s+Set\s+GROUP\s*=\s*([^\r\n]+)/so ) {

and everything works. Due i am not a perl programmer the fix applied may not a good one - so there could be a better solution.

-- PetricFrank - 06 Jun 2003

Mozilla oddness update: it is definitely Mozilla that is doing the unexpected thing; if there is a trailing linefeed on a hidden field value it is stripped off before the HTTP POST operation. I've filed MozillaBug:208546 but this may be an undefined "feature" of the HTTP specification.

-- GarethEdwards - 06 Jun 2003

Is noone else having the actiontracker crash the statistics script?

Can't call method "param" on an undefined value at ../lib/TWiki/Plugins/ActionTrackerPlugin.pm line 391.

-- MartinCleaver - 12 Jun 2003

My bug report on Mozilla has been marked as a duplicate of MozillaBug:114997. Although it appears to be scheduled for fix on the 1.5 release it has been kicking round for 18 months so I'm not betting on it making the manifest. Unless I come up with a workaround it looks like the edit action will have to be done on the topic, not on the action.

Martin, the statistics script is working fine for me when I force the run from the browser. I don't have the script in a cron job so I can't say whether this would be different but I suspect not.

-- GarethEdwards - 12 Jun 2003

It works fine for me through the browser. I suspect there is a CGI reference that is undefined when run on the command line. This means that no automatic updates can work which in turn makes it impossible to track visits per page per day.

-- MartinCleaver - 12 Jun 2003

FIXED 6 Jun 2003 OK, Martin, I tried from the command line and I agree that the script is broken. I made it work for me by adding a trap to the code thus:

Lines 392 and 393 of ActionTrackerPlugin.pm in the function beforeSaveHandler reads:

  my $query = TWiki::Func::getCgiQuery();
  if ( $query->param( 'closeactioneditor' )) {

I added a line

  my $query = TWiki::Func::getCgiQuery();
  return unless $query;
  if ( $query->param( 'closeactioneditor' )) {

and everything worked ok after that.

-- GarethEdwards - 13 Jun 2003

I have installed the May 21 version of the plugin with the Feb 2003 version of TWiki. On a page with two actions, the following html is generated:

<table border="1"><tr bgcolor="#FFCC66"></tr><tr valign="top"><a name="000020"></a></tr></table>
<p />
<table border="1"><tr bgcolor="#FFCC66"></tr><tr valign="top"><a name="000021"></a></tr></table>
<p />

Clearly the plugin is installed and doing something, but not actually formatting the action data. Actionsearches don't produce anything. Any idea what is going wrong?

-- EelcoVisser - 30 Jun 2003

I have encountered two problems with the actually released plugin.

  1. Lockfile is not removed after the edit session if NOPREVIEW is set to 1. FIXED 6 Jun 2003
  2. Sometimes the '<<EOF ... EOF' will be removed even if the text part contains more than one line. As result continuation lines are no longer part of the action tracker item. This does not always occur.
    This becomes a blocking item, because the next one editing the item gets only presented the first line of the text. FIXED 6 Jun 2003

-- PetricFrank - 01 Jul 2003

Further analysis reveals that the second problem above only occurs if you have more than one action tracker items in a topic. Also only the action tracker items above the actual edited item get the '<<EOF ... EOF' stripped away.

-- PetricFrank - 01 Jul 2003

I did some debugging. I changed Action.pm (subroutine findActionByUID) . Remove the line '$gathering = undef;'. Then exchange the block:

  my $auid = $anAction->{uid};
  if ( ( defined( $auid ) && $auid eq $uid ) || $an == $sn ) {
    $found = 1;
    $action = $anAction;
  } else {
    $pretext .= "%ACTION{$attrs}%";

by the following one:

  my $auid = $anAction->{uid};
  if ( ( defined( $auid ) && $auid eq $uid ) || $an == $sn ) {
    $found = 1;
    $action = $anAction;
  } else {
    $pretext .= "%ACTION{$attrs}%";
    if ($gathering) {
      $pretext .= " <<$gathering\n";
    $pretext .= "$descr\n";
    if ($gathering) {
    $pretext .= "$gathering\n";

    $gathering = undef;

Hope that helps.

-- PetricFrank - 01 Jul 2003

I just installed the May 21 2003 version, and am trying to format a search table. I'm using this command:

%ACTIONSEARCH{ within="30" format="|$text|$topic|$due|" header="|Item|Topic|Due Date|" orient="cols" }%

Here's the output I get:

Item Topic Due Date
Item 1 (go to action) ActionTrackerPlugin Mon, 7 Jul 2003
Item 2 (go to action) ActionTrackerPluginDev Tue, 8 Jul 2003

Notice that the topics aren't automatically linked. Here's the output I'd prefer:

Item Topic Due Date
Item 1 ActionTrackerPlugin Mon, 7 Jul 2003
Item 2 ActionTrackerPluginDev Tue, 8 Jul 2003

Any way to accomplish that under the current setup?

-- MikeBoone - 03 Jul 2003

Gareth, Martin: I don't understand this, but I'll put the fix in (mostly harmless)

Eelco: I had this report from another installation, but they were unable to reproduce after restarting the server. Maybe something to do with mod_perl?

Petric: great bit of debugging, I'll put it in as soon as I get a chance. I'll have a looksee at the lockfile issue as well.

Mike: Put spaces in the format="| $text | $topic | $due |" should work.

-- CrawfordCurrie - 04 Jul 2003

OK, a bugfix version is in the main topic and I've refactored this page so I remember what we've fixed ;-).

Mike: sorry, I just realised what you were saying. No, there's no way to do that.

Incoporated in the bugfix:

  • META HTTP-EQUIV=Expires in edit.action.tmpl
  • Fix for GarethEdwards GROUP problem (Gareth, the problem was that the RE should have had 'm' after it, not 's'. To see what this means, man perlre )
  • GarethEdwards's "undefined $query in actionnotify" fix
  • PetricFrank's fix for gathering <<EOF..EOF

-- CrawfordCurrie - 06 Jul 2003

Crawford, putting spaces between the pipe characters did allow the $topic to hyperlink correctly. Thanks! For now, I'm removing the (go to action) part by commenting out that piece of code, but I'd prefer to be able to turn it off as an option (I added it to the list below).

I was so occupied with the new formatting of the Action Search (which works fine), that I didn't notice that the actions themselves are not displaying. I get nearly empty HTML from my action table. This looks like EelcoVisser's problem. Installing the update you just posted had no effect. (I added some line breaks for clarity):

<table border="1"><tr bgcolor="#FFCC66"></tr>
<tr valign="top"><a name="AcTion0"></a></tr>
<tr valign="top"><a name="AcTion1"></a></tr>
<tr valign="top"><a name="AcTion2"></a></tr>
<tr valign="top"><a name="AcTion3"></a></tr></table>

I am running ModPerl, but simply restarting Apache did not help. Turning off mod_perl did not fix the problem either.

These actions were carried over from an older version of this Plugin. I started wondering when the atUidReg file came into play. It was not created automatically, so I added an empty file to the /data folder. Is this file only used when using the Action Tracker's little edit form? I'm accustomed to editing my ACTION statements directly in the TWiki text.

Any ideas what I'm doing wrong?

-- MikeBoone - 06 Jul 2003

Hmmm. Have you edited and saved the topic containing the actions since the upgrade? If not, can you try doing so and see if that makes a difference? I'm just guessing, but maybe it's something to do with the missing fields.

Oh, I assume that the fields printed in the ACTIONSEARCH actually do exist in those actions? (Just checking)

Have you modified the TABLE settings in the WebPreferences? Is the plugin topic readable by the server?

The (go to action) is there because I was asked not to link the first few words of the action as the target. Using the topic as the target is not sufficient as a single topic may contain many actions, so you have to target an anchor within the topic. If you don't need that anchor, then that's fine.

-- CrawfordCurrie - 07 Jul 2003

I figured it out! In TWikiPreferences, I had to change my plugin from the old Plugins.ActionTrackerPlugin to the new TWiki.ActionTrackerPlugin. I forgot to do that when I upgraded the plugin to the newer version. That fixed my action table display problem. I'm not sure why the action search worked without it. The uid stuff seems to be working now too. The 'upgrade notes' on ActionTrackerPlugin mention that the ActionTrackerPlugin.txt file moved from /data/Plugins to /data/TWiki, but perhaps mention should be made that the location needs to be updated in TWikiPreferences also.

With regard to the (go to action), I guess I don't have enough actions on any one page that I would need the anchor to find them.

-- MikeBoone - 07 Jul 2003

Oho! That explains a lot! The plugins module in the twiki core finds plugins by reading the TWiki and Plugins webs. If it found the version in the plugins web it wouldn't have seen the settings for TABLES etc. resulting I guess in empty tables. it shouldn't be anythign to do with the list in TWikiPreferences which should be auto-generated.

As for (go to action), keep on editing. I found a page a few days ago that had 362 (count them, 362) actions on it!

Hi, I installed the 06 Jul 2003 release yesterday and things went fairly smoothly. I am having some trouble setting up the action notifications as I want them. What I want is to send one email per day containing any changed actions and all late actions for a person, for a specific web. I think this should look something like:

   $ actionnotify web=Myweb,late,changedsince=yesterday
but this just notifies only the late actions in Myweb. It seems that changedsince isn't working for me because if I just specify the changedsince argument nothing gets notified. Since I have only just installed this plugin all my actions are new and are in new topics. I have done a little investigation and found that my actions are failing to get through the _findChangesInTopic function in ActionNotify.pm. Line 403 seems to ignore topics if there was no revision at the time we are looking back to:
   return unless defined( $oldrev );
Should this not be that if there was no revision at that time then all actions in the topic must have changed (i.e. they are new)? Please excuse me if I have misunderstood this as I am (obviously) fairly new to this plugin.

-- MikeLees - 17 Jul 2003

Crawford, a minor detail: I added your signature to the Plugins topic so that the PluginPackage index table shows your name. Best to include that in your next version.

-- PeterThoeny - 19 Jun 2003

Another minor detail. The installation instructions still say to add ActionsTrackerPlugin to the INSTALLEDPLUGINS list. I changed in the online documentation, but the package needs to be updated. Thanks.

-- MichaelMathis - 06 Sep 2003

FIXED 2/Feb/04

I tried to get the Action Tracker running (both the release version and the most recent one from this page). I cannot get the example search dialog to work. It contains empty fields for properties not queried. So if I am querying for every action for the user TWikiGuest, which should geive a result on the example page already, all other fields (due, etc.) are empty. The ACTIONSEARCH results in an empty table when empty fields are in the query. This is also the case, if just an ACTIONSEARCH is used on a page with an empty property as on of the property parameters. What do I need to change to get the dialog woking?

-- RalfFindeisen - 09 Sep 2003

FIXED 2/Feb/04 - QBE was broken

I installed the Plugin yesterday and had a few problems relating to the actionnotify script. I modified some code in my version. Here are the diffs:

RCS file: RCS/ActionNotify.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
<       $actions = ActionTrackerPlugin::ActionSet::allActionsInWebs( $webs, $attrs );
>       my $internal = 1;
>       $actions = ActionTrackerPlugin::ActionSet::allActionsInWebs( $webs, $attrs , $internal );
<     my $from = TWiki::Func::getPreferencesValue("WIKITOOLNAME");
>     my $from = TWiki::Func::getPreferencesValue("WIKIWEBMASTER");
RCS file: RCS/ActionSet.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -r1.1 -r1.2
<     my ( $web, $attrs ) = @_;
>     my ( $web, $attrs, $internal ) = @_;
>     $internal = 0 unless defined($internal);
<         my $text = TWiki::Func::readTopicText( $web, $topic );
>           my $revision = undef;
>         my $text = TWiki::Func::readTopicText( $web, $topic, $revision, $internal );
<     my ( $theweb, $attrs ) = @_;
>     my ( $theweb, $attrs, $internal ) = @_;
>     $internal = 0 unless defined($internal);
<       my $subacts = allActionsInWeb( $web, $attrs );
>       my $subacts = allActionsInWeb( $web, $attrs, $internal );
The two problems I seemed to have:
  • The web I was trying to work with has some permission settings. The Plugin code does not call the TWiki::Func::readTopicText function with the flag required to override permissions set for web access. This flag had to propagate down through the call stack form the ActionNotify.pm code to the ActionSet.pm code.
  • The ActionNotify.pm code uses the WIKITOOLNAME variable as the email "From" address. I am not 100% sure but my installation did not seem to like this. I modified this to a variable which provides a real email address, WIKIWEBMASTER, and this fixed the problem. I guess the problem might be on my mail server. However, it is clearly preferable to use a value which looks like a real email address.

Does anyone have any comments on these changes? I don't want to end up running my own patched variant of the plugin if possible.

-- EdMcGuigan - 01 Oct 2003

FIXED 2/Feb/04


I take a look on the Mozilla bug when after editing action is this action merged into action before it. If you want a 'hot fix' and you don't want to wait until Mozilla fix this bug, you can use code bellow. In ActionTrackerPlugin.pm file in afterEditHandler function replace lines:

  my $pretext = $query->param( 'pretext' ) || "";
  my $posttext = $query->param( 'posttext' ) || "";
  my $pretext = $query->param( 'pretext' ) || "";
  my $char = chop( $pretext );
  $pretext .= $char if ( $char ne "\n" );
  $pretext .= "\n";
  my $posttext = $query->param( 'posttext' ) || "";
This code does that the $pretext variable always ends with new line character. And that's what you need in Mozilla!! wink

RichardBaar - 08 Oct 2003

FIXED 2/Feb/04

Bug: Foreign (Danish) letters destroyed in topic after editing action

  • Edit the two files actionnotify.tmpl and edit.action.tmpl
  • Change the Content-type from us-ascii to %CHARSET% (iso88591 in my case)

-- NielsKoldso - 05 Nov 2003

Bug: Foreign TWiki users with funny names (like me: Niels Koldsų) not mail notified

  • Replace /twiki/lib/TWiki/Plugins/ActionTrackerPlugin/ActionNotify.pm with this patched one: ActionNotify.pm

-- NielsKoldso - 02 Dec 2003

FIXED 2/Feb/04

Does anyone else have this problem: I have users SamA and SamAbrams. When I setup a search, such as %ACTIONSEARCH{who="me" ..., SamA sees actions for herself AND SamAbrams.

I tried to anchor the who field with a regular expression, "%WIKINAME%[ ,\"]", but I can't get regular expressions functioning properly inside of actionsearches.

-- SamAbrams - 22 Jan 2004

Sam, a gen-ewe-wine bug. I'll fix it when I get time, but in the interim, you I'm pretty sure you can do the following. In Action.pm, there's a function _matchType_names. In it you'll find the line

      if ( $this->{$vbl} =~ /$who/ ) {
change it to read
      if ( $this->{$vbl} =~ /$who,/ || $this->{$vbl} =~ /$who$/ ) {
let me know if this works, please.

-- CrawfordCurrie - 22 Jan 2004

FIXED 2/Feb/04

Could somebody please try in their installation and create an action with a due date before 14 Dec 1901. In my TWiki, any earlier date gets changed into a date far in the future. I don't know whether there is something wrong with my installation? Unfortunately, ActionTrackerPlugin is not activiated on twiki.org, so I cannot check myself.

-- ThomasWeigert - 05 Jan 2004

Yes, Thomas, on my installation as well, if I change a date to pre-1901, it gets changed to something around 2036.

-- SamAbrams - 06 Jan 2004

A wild guess is it's something to do with Time::ParseDate. To be honest, I never tested dates before 1901, as I naively expected actions to be in the future, and be assigned (most people born in 1901 are already dead). If anyone can establish a rational requirement for this, I'll have a look.

-- CrawfordCurrie - 06 Jan 2004

CrawfordCurrie, this is probably not worth the trouble. My main concern was whether something was screwed up in my installation. It might be helpful though to put a note into the documentation page ActionTrackerPlugin.

I looked at CPAN; the documentation for Time::ParseDate states that "The return code is always the time in seconds since January 1st, 1970 or undef if it was unable to parse the time." So probably this is not meant to work with dates before that.

-- ThomasWeigert - 07 Jan 2004

Aha! UNIX bites deep. I'd better write a test for dates in the far future (2300, isn't it?), just in case. in the interim, I'll put in a documentation fix as you suggest.

-- CrawfordCurrie - 07 Jan 2004

FIXED 2/Feb/04

Does anyone else have this problem: I have users SamA and SamAbrams. When I setup a search, such as %ACTIONSEARCH{who="me" ..., SamA sees actions for herself AND SamAbrams.

I tried to anchor the who field with a regular expression, "%WIKINAME%[ ,\"]", but I can't get regular expressions functioning properly inside of actionsearches.

-- SamAbrams - 22 Jan 2004

Sam, a gen-ewe-wine bug. I'll fix it when I get time, but in the interim, you I'm pretty sure you can do the following. In Action.pm, there's a function _matchType_names. In it you'll find the line

if ( $this->{$vbl} =~ /$who/ ) {

change it to read

if ( $this->{$vbl} =~ /$who,/ || $this->{$vbl} =~ /$who$/ ) {

let me know if this works, please.

-- CrawfordCurrie - 22 Jan 2004

Crawford, yes, this worked like a charm. Thank you !

-- SamAbrams - 22 Jan 2004

FIXED 2/Feb/04

ActionNotify.pm is sending email from WIKITOOLNAME. This is not a complete email address (is has no domain) and is thus rejected by my email software. At line 324, ActionNotify.pm should be modified to use WIKIWEBMASTER instead. BTW, this is the sender used by mailnotify. -- JoaquimBaptista - 28 Jan 2004

FIXED 2/Feb/04

The example Query-by-example does not work. There is no way to distinguish between an attribut without a value and an attribute with the empty value. Therefore, the search always searches for actions with empty attributes, and finds none. At ActionTrackerPlugin.pm, subroutine _handleActionSearch, you can remove the empty values from $attrs before calling allActionsInWebs, but then you lose the ability to search fro actions with empty values. I don't see a simple solution for this. -- JoaquimBaptista - 29 Jan 2004

FIXED 2/Feb/04

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2004-02-06 - CrawfordCurrie
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.