Tags:
create new tag
, view all tags

ProjectPlannerPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on ProjectPlannerPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on ProjectPlannerPlugin

I needed something for project tracking and looked at XpTrackerPlugin. It just had so much Xp stuff assumed that I couldn't use it. So I shamelessly took a lot of the same ideas and wrote a ProjectPlannerPlugin plugin which has a different architecture of what a project,task,developer is and how they are handled.

I know perl but I am a C++ programmer so there might be inefficiencies in the script and possible bugs though I have use strict to eliminate some of common issues I know of.

We use this at our work for tracking our group projects. I think it is generic enough for most uses though we do customize the PlanTemplate select boxes, etc. to suit our purpose.

All feedback is welcome though no support is promised smile

-- KiranBondalapati - 02 Aug 2004

Did you look at FormQueryPlugin which I think already does everything you require?

-- CrawfordCurrie - 03 Aug 2004

Wow, a competitor! big grin Welcome aboard the twiki plugins development community.

As the XpTrackerPlugin maintainer, I'm very curious about what are the "Xp stuff assumed" that make you don't use it. It's the terminology, the reports, the complexity?

I ask because we use it at work and we're not an Xp shop, so I assumed that it could be used by more or less everyone that don't need a gantt chart.

By the look of it, I think that there are a lot of similarities between the two projects:

ProjectPlannerPlugin XpTrackerPlugin
Project Project
Plan Iteration
Task Story
Developer Developer

If you want the Story to be atomic, put only one "task" on it. We prefer to have a Story with multiple task because that way we make explicit the "integration" and "pre-integration test" task explicit for each requirement. (Very useful, in our case)

Besides that, the only additional information is the "Module" column. Hmm... it makes sense if you have that organization... we have that organization at work... hmm.. can I "borrow" it? wink I also like the way the plugin display the summaries.

If I'm not mistaken, the main difference between the two is that XpTrackerPlugin needs one page per story to track additional information (and to provide a kind of journal) and ProjectPlannerPlugin use one page for all the tasks. In that sense it should be faster than XpTrackerPlugin (how does it scale?).

I have to check FormQueryPlugin...

-- RafaelAlvarez - 03 Aug 2004

FormQueryPlugin is not configured as a project planner out of the box, it's just that's one of the uses I have put it to. When I configured it to do that, I used a table of tasks in a topic, same as Kiran.

But it's the underlying topic object model and cache that is most powerful, that could be the engine room for either XpTrackerPlugin or ProjectPlannerPlugin (looking for code reuse opportunities here, and also looking for a way to retire some more of the functionality I had to put into FormQueryPlugin). I already abstracted the topic object model out into DBCachePlugin to support re-use.

-- CrawfordCurrie - 04 Aug 2004

I tried FormQueryPlugin even before I tried the XpTrackerPlugin. My second choice was just use a single edit table rather than forms. I think the problem with Form query was the dynamic update nature. It was good if items were entered once and not actively modified. But, my group wantes a mechanism to edit multiple tasks at the same time and change priorities, status, owners etc. Forms were too painful to do it or I did not know how to use it smile

I think I had problem with XP tracker just with the data model of how tasks are built from story pages and the assumptions of collecting the status from them. I do not remember the exact reasons now though. However, the fact that I copied some of the ideas shows that it is close to what I was looking for smile And yeah evangelizing Wiki is not helped by the fact that you have to end all story pages with a Story word. (It might not be obvious for you guys: I program but work in a chip design firm and peoples eyes would glaze over if you said Iteration and Story smile

It is not supposed to be a competition. Just selfish: I just put it out there because someone might spot some bad (inefficient) perl coding that I did or any other spiffy things that can be done and I can borrow the changes back. I just finished it and installed it for our use and we are in the process of using it. I will see about speed and such issues in a few months. I did have problems with EditTablePlugin becoming slow after 50 rows in the past.

-- KiranBondalapati - 05 Aug 2004

This is not competition. People have different needs, I am sure some people find your project planner useful. Thanks for sharing it with the TWiki community smile

-- PeterThoeny - 06 Aug 2004

No, it's not a competition; however we have to have conversations like this to find common areas and reduce duplication. That's how we will improve.

Subsequent discussion moved to TrackerPlannerContribDev.

-- CrawfordCurrie - 08 Aug 2004

Hi, thanxs for the great work!

I installed version 2 of ProjectPlannerPlugin onto version 01 Feb 2003 of WTiki and all works fine now.

... but I found a small bug in version 2. The edit task table did not display in the plan topic due to a syntax error in the plan template file. The solution it to change the plan template file. The ProjectTemplate file is ok.

Syntax problem in 2 lines in PlanTemplate.txt file, eg.:

<!-- WARNING! Do not edit this table directly!! Go Back and use the Edit Table button. >

You need to add the -- before the >. Hope this helps.

-- AndyCohen - 09 Sep 2004

Well, I am having a devil of a time getting this plugin (v2.010) to work.

First, the plugin would not load. I originally thought this was due to a corrupt ProjectPlannerPlugin.txt file. I finally got the formatting right but no load.

Second, I thought it might be due to a missing data/_yourweb_/NewPageError.txt but there wasn't one ion the distribution zip so . . . . I ignored that part.

Finally, I found that by commenting out use strict the plugin loads -- but still doesn't do anything, at least as far as I can tell by seeing if %PPALLPROJECTS% renders, which it does not.

DEBUG indicates that the plugin is now initializing okay, but placing debug code into ppReadPlanTemplate indicates that the subroutine is not being called.

So, I imagine that it has something to do with use strict but I am currently at a loss.

We are running Feb, 2003 version of twiki and Perl 5.6.1 on Solaris 9.

-- SteveRJones - 08 Oct 2004

BTW, I thought I would mention that this is the first plugin that I have ever really had any problems. It's always been pretty plug-n-play.

-- SteveRJones - 08 Oct 2004

I just realized something - there is a Twiki dependency of $TWiki::Plugins::VERSION 1.024 and according to http://ntwiki.ethermage.net:8181/svn/twiki/trunk/lib/TWiki/Plugins.pm this is an alpha release of plugins.pm. I also notice that V2.010 has "some fixes for new Twiki releases. So, two questions:

1.> Is the alpha version of plugins.pm required if running v2.010 of the plugin and the Feb 01, 2003 release of twiki? 1.> if so, is it safe simply to plop the alpha ver of plugins.pm into the TWiki\plugins directory?

I'm going to try V2.0

-- SteveRJones - 09 Oct 2004

Nope, V2.0 does not work. The plugin topic states that this has only been tested on the 01 Feb 2003 release, however, that release does not have the required version of PLUGINS.PM. This is not explicitly stated in the plugin topic.

-- SteveRJones - 11 Oct 2004

Wouldn't it be good if the notification system actually notified interested parties? Have you tried emailing Kiran... ?

-- MartinCleaver - 11 Oct 2004

Ah, yes. That was my next step (email), but I am on vacation and this just keeps nagging at me to figure out. Don't you hate that when it happens smile

-- SteveRJones - 12 Oct 2004

Sorry for the poor response on my part. I got the email from Steve and responded to him but have not been able to figure out the problem. The basic problem being that I do not have access to a newer Twiki installation to test/debug. Can someone point me to a installation where I can get some debug info, maybe by bouncing back and forth the plugin perl file?

A couple of answers/clarifications:

- PLUGINS.PM version dependency is totally accidental. I picked up the ExamplePlugin.pm code which has the same check and did not modify the check. If you look at the ProjectPlannerPlugin source you will see much of the harmless(?) ExamplePlugin code left in there.

- NewPageError missing is a bug frown However, it shows a oops page instead of an error message (an error did occur anyway). I will try to fix it with other issues in the next release.

you can create the topic when you get the oops, does not exist page and cut and paste this into that page:

Error creating new project planner page

One of the following is the cause:

            • No page name was entered in the form
            • The page name is not a legal WikiName
            • A page with the given name already exists. See WebIndex for current pages.
Go back to the previous page and enter a legal name.

-- KiranBondalapati - 26 Oct 2004

AndyCohen, thanks for pointing the error out. Similar to above issues, older Twiki is more forgiving with HTML comment bug. I fixed the issue you pointed out in version 2.0 already.

-- KiranBondalapati - 26 Oct 2004

Kiran, the problem that I am having is the plugin does not run under my installation of Twiki version 01Feb2003. Now, we are running Perl 5.6.1 under Solaris8 and the plugin page indicates that you tested this under Perl 5.005. So far, teh only way I can get the plugin to inialize and show up in the Active Plugins list is to comment out use strict, but then nothing works other than the initialization.

I also noticed that in the plugin initialization section that you call two plugin routines everytime:

&ppReadPlanTemplate($web);

&ppReadCache($web);

Doing this would seem to add alot of overhead - is that true?

Thanks!

-- SteveRJones - 27 Oct 2004

Steve, I might have been incorrect. I just checked our installation and we use perl 5.6.1 on linux.

the two routines are called in the initialization section. I do not think it gets called everytime on each page view. I need to read the files at least once to initialize the state and I do not think there is any other mechanism to read only once. Please correct me if I am incorrect.

If you are unable to point me to any site, you can add

$debug =1

in the initialization and repeat these lines throughout the files to trace if it is failing in any specific function.

TWiki::Func::writeDebug( "PP: your message" ) if $debug;

Maybe I should add an error msg but if it does not find PlanTemplate file or it is corrupt, nothing much is going to work.

-- KiranBondalapati - 28 Oct 2004

Ok, good, then you are using Perl 5.6.1. I would update the requirements on the Plugin page.

My understanding of Plugin execution is, all Plugin init sections execute whenever VIEW.CGI is run, which is why (I believe) there is a caution about loading too many plugins. I did place some debug statments into the ProjectPlannerPlugin code and the debug code makes an entry into debug.txt whenever a page is VIEW 'd. I am not, however, a plugin guru.

On the final note, PlanTemplate is included with your distribution, correct? Then I would expect to see the Plugin function %PPALLPROJECTS% display your demo project on the TWiki.ProjectPlannerPlugin page under the

Installation Test

section.

As I pointed out, the Plugin does not initialize until I comment out the use strict directive. Even setting debug=1 results in nothing, telling me that Perl is refusing to compile the code for some reason.

Is there a dependence on a Perl module that perhaps we do not have installed?

-- SteveRJones - 29 Oct 2004

Kiran, the statement:

Plugin might use many Perl libraries that need to be initialized with each page view

in TWikiPlugins#A_Note_on_Plugin_Performance is what leads me to believe that the two functions in your INIT section will be called at every page VIEW . But again, I am not a plugin guru. I put CrawfordCurrie in the category of "plugin guru". No slight to you or anyone else, it's just that I used to work with Crawford and developed great respect for his programming abilities. That respect has simply been carried forward.

-- SteveRJones - 29 Oct 2004

Steve, A very quick check that I do to check the strict is just typing "perl ProjectPlannerPlugin.pm" on the command line. It usually shows me any violations due to the use strict. Can you try that?

I am definitely not a Plugin guru, I am not even a perl guru smile

-- KiranBondalapati - 04 Nov 2004

%time wget -qO /dev/null http://ourserver/cgi-pub/wiki/controlled/view/TWiki/AbcPlugin 0.000u 0.000s 0:00.12 0.0% 0+0k 0+0io 160pf+0w

that does not seem bad but I have no idea.

Another answer: PlanTemplate.txt is in the distribution, but you need to copy it to the web where you are using your plugin (and ProjectPlannerPlugin topic also needs to exist in the same web according to TWikiPlugins#A_Note_on_Plugin_Performance).

-- KiranBondalapati - 04 Nov 2004

BTW, if you do have the patience, we should be migrating to a new version of TWiki in the near future (at your sysadmins schedule). I can test it on the new version and check it works...

-- KiranBondalapati - 04 Nov 2004

Ooops:

%time wget -qO /dev/null http://ourserver/cgi-pub/wiki/controlled/view/TWiki/ProjectPlannerPlugin

0.000u 0.000s 0:00.03 0.0% 0+0k 0+0io 160pf+0w

-- KiranBondalapati - 04 Nov 2004

You are right, there appears to little overhead in the init section - so I'll just be quiet! smile

I'll give it a try running it on the cammand line and let you know what comes up.

-- SteveRJones - 05 Nov 2004

Kiran, thanks for the tip in running the PM through Perl - it seems that the HTTP::Date perl module is not available and Perl barfs on that. I'll get it installed and give it another whirl!

Thanks!

-- SteveRJones - 09 Nov 2004

Crawford:

You said "FormQueryPlugin is not configured as a project planner out of the box, it's just that's one of the uses I have put it to."

Perhaps you could contribute that as a "Cookbook example somewhere".

-- AntonAylward - 10 Nov 2004

Steve, I realized I wanted to use some Date routines but I didn't I think you can comment the line out and try.

-- KiranBondalapati - 18 Nov 2004

Ok, I'll give that a try!

BTW, I think CalenderPlugin already has a Date module dependency - yes, Date::Calc. You might look at this module to see if it provides the functions that you were thinking of using, if you want to try in the future.

Anyway, I'll report back tomorrow!

-- SteveRJones - 19 Nov 2004

I finally got a new release installed and I just tested the plugin as is in the new TWiki release Sep 2004. And everything just worked out of the box. So I suspect it has to do something with the perl installation at your site.

-- KiranBondalapati - 19 Nov 2004

Ok, I got it running and here is what I ran into:
I'm running 01Feb2003 release, Perl 5.6.1, Solaris 9.

  • Definitely comment out the "USE HTTP::Date". the plugin now initializes
  • The topic ProjectPlannerPlugin is somehow corrupt when it comes out of the zip file. I suspect hidden chars are in the file as CRLF's appear not to be present. An edit in Twiki then a save seems to fix things.
  • Now the real kicker: in the TWiki web, looking at ProjectPlannerPlugin, the directive %PPALLPROJECTS% does not appear to be working as the variable is still visible (ie., no plugin stuff). Well, while fixing the formatting issues (listed above) I noticed that in PREVIEW mode I could see the plugin output! Once I saved, though, back to no output.
So, I created a test Web and setup PPPlugin there. Voila! it works in view mode. The only difference between the two webs is, TWiki has the default skin with its VIEW.CGI/TEMPLATES and the test web has our production skin (AMBAR) with its VIEW.CGI/TEMPLATES. It must be the TEMPLATES as both use the same VIEW script.

UPDATE: I can't seem to get this little nuance to occur everytime. I am getting an error in my errorlog that I included below. Strange behavior.

-- SteveRJones - 19 Nov 2004

Improvement Suggestions

  • When one places the command %PPPALLPROJECTS% in a topic, the plugin tells the user that the ProjectTemplate cannot be found. One may click on the "?" but that does not really help as in one may not know what needs to be in the template. How about having the plugin either:
    • copy TWiki.ProjectTemplate, OR
    • grab the raw TML out of TWiki.ProjectTemplate and place it into the new topic?
  • Same comment for TWiki.PlantTemplate
-- SteveRJones - 19 Nov 2004

More Improvement Suggestions

  • Shouldn't PLANS be child topics of the PROJECT? My test indicates PLANS become children of ProjectTemplate and not the project itself.
  • SELECT lists for PLAN table. Currently, these are hardcoded into the PlanTemplate. Instead, have the select items %INCLUDE%d from a separate topic, making it easier to change SELECT items - even have a link to the SELECT item topics on the main page.
  • PROJECT and PLAN ID's: Could these be autogenerated if not manually entered?
A couple of nits - mostly preference
  • The TABLEDIT view is very wide - is it possible to scale the font down such that the table more easily fits on the screen without scrolling?
  • Instead of "EST DAYS" and "SPENT DAYS" why not use the TABLEEDIT popup calendar feature to have the user pick the estimated completion date, then pick the actual completion date, then use date math to calculate the EST DAYS and SPENT DAYS?
  • The fields "Project Name", "ID(s)", and "Project Summary" on the plugin create form don't really line up correctly, perhaps these can be adjusted a little?
-- SteveRJones - 19 Nov 2004

The Twiki errorlog is indicating a:

view.cgi: Use of uninitialized value in pattern match (m//)
at /proj/sysadmin/ess/www/twiki/html/lib/TWiki/Plugins/ProjectPlannerPlugin.pm line 647.

I looked at the code in question:

        if ($planIds eq "") {
            if (!($cachedIdPlans{0} =~ /$plan/)) {
                $cachedIdPlans{0} .= "$plan;";
            }

and it would seem to indicate that $plan has not been initialized, but there is clearly a my $plan; in the subroutine ppReadCache.

-- SteveRJones - 19 Nov 2004

Steve, thanks for the feedback and keep it coming. I am thunking on all of these and will explain some of the design choices and use the other suggestions for 3.0 release smile

w.r.t. the bug. I can only suspect it is complaining on $cachedIdPlans{0}. You could add this line before the two while loops and the for loops and see if it fixes the error.

%cachedProjPlans = ();
%cachedIdPlans = ();
$cachedIdPlans{0} = ""; <-------- new line

-- KiranBondalapati - 19 Nov 2004

Ok, I'll try that.

In the meantime, I think I can make some test mods like for the topic driven selects, since these are part of the templating system -- if that is ok with you.

Have a great weekend!

-- SteveRJones - 19 Nov 2004

I'm running this - or trying to - with

  • Windows XP
  • cygwin perl 5.8.5
  • Apache 1.3.33 (win32)
  • TWiki 20041030beta
I don't need something as heavy as FormQueryPlugin.

However this only works as far as "inputing the data" goes. The listing of " All plans for project XXX" and " All plans and tasks for all projects XXX" are blank. Perhaps it has somethng to do with the choice of the fields.

My overall opinion is that if one looks at LynwoodBrown's TopicClassificationAddOn the use of metadata for keys ang categories makes more sense. As he says:

Plugins.TopicClassificationAddOn helps you organize content in your wiki by classifying topics according to their function and/or subject matter. It also provides a user-friendly interface for creating new topics that automatically incorporates this classification system. Together, these basic elements provide a platform that allow you to create any number of simple TWikiApplications.

Perhaps I'll get around to trying to adapt TopicClassificationAddOn when I have time. As it stands, I'm very disappointed with this.

-- AntonAylward - 20 Nov 2004

Well, tried adding:

    # read disk cache
    my $cacheText = &TWiki::Store::readFile($cacheFileName);
    %cachedProjPlans = ();
    %cachedIdPlans = ();
    $cachedIdPlans{0} = "";  <---- New entry

but the error still occurrs - line 647 unitialized value in pattern match. I was assuming that it meant the value in between (m//) was at fault - not sure what the 'm' is all about. Not so?

-- SteveRJones - 22 Nov 2004

Kiran, I've run into some more questions:

  • The ProjectPlannerPlugin page depicts "hand massaged" output that is now vastly different from what is truly output from the plugin.
  • It is not readily apparent what determines the colors of the bars - perhaps adding a "legend".
  • My test shows that the "spent days" for "all plans" shows up as zero, even though the "Total Spent" shows the correct number.

Plan Sort Summary Sort Status By Tasks Sort Status By Days Sort Est Days Sort Spent Days Sort
TestPlan test plan
40 0
TestPlanTwo Another plan
25 0
        Total Est: 65 Total Spent: 14

  • Lastly, notice that the colorbars do not fill in the entire cell. On my Twiki site the entire cell is colored. Which is the correct behavior, or does it matter?
-- SteveRJones - 22 Nov 2004

Ok, I looked at the code and it appears that "Spent Days" in this summary table is not the same "Spent Days" in the task list. This column become non-zero when a task status is "Done". So, perhaps the column is mislabeled and should be like "Actual Days" or something like that - although the math doesn't work out as the task I marked as "Done" had 10 "Est" days and 1 "Spent" day, but the code set final "Spent" to 10 (my original "Est".)!

I think I see what you are driving at - a measure of "Actual Spent" once a task is marked "Done". Is that correct? Below is my actual test data:

All plans for project TestProject

Plan Sort Summary Sort Status By Tasks Sort Status By Days Sort Est Days Sort Spent Days Sort
TestPlan test plan
40 10
TestPlanTwo Another plan
25 0
        Total Est: 65 Total Spent: 23

Plan Name: ID(s):
Plan Summary:

Task Information

All plans and tasks for all projects TestProject

Project Sort Plan Sort Task Sort Summary Sort Developer Sort Module Sort Status Sort Priority Sort Est Days Sort Spent Days Sort Results_Comments Sort
TestProject TestPlan                  
    NewTaskNameWikiWord?   unassigned other in progress low 30 3  
    NewTaskNameWikiWordTwo?   unassigned environment done low 10 1  
  TestPlanTwo                  
    TaskTwo?   unassigned whacker in progress low 25 10  

-- SteveRJones - 22 Nov 2004

Steve, I notice that in the new release/skin, the color bars don't fill the cell. Need to debug HTML as to why they don't.

I guess some of the logic in the display needs more documentation. It seemed so obvious to me smile The status bars and the spent days use the task status in handling it. If an item is "not started" then the spent days is ignored, else the spent days is factored into the color bars. When an item is marked "done" then spent days is ignored and it is assumed that spent days is equal to done days and the developer was too lazy to update the spent days. smile If he/she overran the estimate the assumption was that the Est Days would be updated.

Anyway, based on your feedback and our extensive usage, I will see what should be the rules to handle the collation of the information. Maybe est date of completion etc. would be a better way to handle this. But, typically it seems easier to estimate effort level and assign days to it than assign developers, figure out their schedule and assign est completion days.

If you change the effort column you can see that the plugin computes actual man days of effort. That seemed a better approach to the scheduling problem.

Thunking...

-- KiranBondalapati - 22 Nov 2004

I think I was looking at it from the perspective of "what if I actually did spend fewer days than estimated" -- I would actually want to see the fact that the original estimate was out-of-line with actual.

This was one reason why I suggested using a date picker for the target completion date and when an task was marked "Done" one would then update the "Finished date". I suppose this could actually be programmed in - when I mark "Done" the date field is automatically filled in.

Nevertheless, I see your point when you describe it - it was simply not obvious to me until I actually started looking at the code.

BTW, can you also provide a description as to the purpose of the cache? That, too, is not obvious to me.

Thanks!

-- SteveRJones - 23 Nov 2004

Kiran, I've done some work with the appearance - most in the template but a very small amount in the plugin. Below is what the new output looks like:


TestProject


TestProject Summary:

*PP Project Template* PROJECTPLANNER
*PP Project Summary* To Test the functionality of the plugin
*PP Project Id(s)* 0000001


Legend DONE IN PROGRESS OTHER

All plans for project TestProject

Plan Summary Status By Tasks Status By Days Est Days Spent Days
TestPlan test plan
40 10
TestPlanTwo Another plan
25 0
TestPlanFour (456457) summary
0 0
Total Est: 65 Total Spent: 23


Plan Name:

Plan ID(s):

Plan Summary:


TestProject Task Information:

All plans and tasks for all projects TestProject

Project Sort Plan Sort Task Sort Summary Sort Developer Sort Module Sort Status Sort Priority Sort Est Days Sort Spent Days Sort Results_Comments Sort
TestProject TestPlan                  
    NewTaskNameWikiWord?   unassigned other in progress low 30 3  
    NewTaskNameWikiWordTwo?   unassigned environment done low 10 1  
  TestPlanTwo                  
    TaskTwo?   unassigned whacker in progress low 25 10  
  TestPlanFour (456457)                  


TestProject Details:



The plugin code change involved "shrinking" the All Tasks table so that it more easily fit on a screen without side-scrolling. This involved wrapping the output from ppAllProjectTasks inside a <font> tag. Of course, the html output that I plugged in above looks a little different on this site (I had to do some by-hand tweeking) but the gist is captured.

If you feel that the changes are appropriate I can send them to you, or update the plugin package.

-- SteveRJones - 23 Nov 2004

Steve, I think adding a font tag is useful but I am not sure what it breaks (size relative to other text on page?). My colleagues just use Ctrl- and Ctrl+ to resize page to fit their browser when looking at the page.

I am noting down the suggestions and questions. I maintain a Userguide for the plugin locally for people to understand how they are supposed to use it. Some of it can be incorporated into the main documentation. I hope that I can generate a design document (description) of what the next revision will look like and release that and more documentation before I release the next rev. We will also be testing and deploying it on the newer release.

However, it will come a little slowly because even supporting the plugin at my work is already over my main line of work frown I wrote it to avoid maintaining a MS Project file on my own smile

(I have also been thinking of accessing previous revisions of topic to present the info and compute the rate of progress. I have not figured out if the existing Func API can support it. Any comments?)

-- KiranBondalapati - 24 Nov 2004

The cache was a quick list of pointers to navigate between different projects, plans and tasks without having to repeatedly looping through all the pages to find a list of topics to read. If you see the cache building process if it does not exist, it reads all the topics in the web. I would have to do something similar for every page view if I did not have the quick cache to use around the plugin.

-- KiranBondalapati - 24 Nov 2004

So far, adding the font code does not appear to break everything, it simply scales down the font (by a "-1") relative to the starting size. The call is yours, however, I found it useful in that the initial tables are sized more closely to the right size. As for effecting other text, the font tag only surrounds the table and contents - all other text is left alone. Note also that I repositioned the HTML form such that it sits beside the All Plans table. I did this by "wrapping" the table and the form inside another table - this also appears not to break anything.

I understand the issue of plugin maintenance - and I too see this plugin as my desparate plea to avoid M$ Project in our org! If we can pull this off then I think there will be a huge number of people begging for this. I am very new to plugin development so your code is helping me quite a bit, plus your code is more "C-like" than "Perl-like" and therefore much more readable smile

I'm not sure about accessing the RCS history, however, there is a plugin that does this - perhaps you can look at that plugin for a hint. I'm not sure what a 'rate' of change would tell one about a project - except that some people tend to update more frequently than others (which could prove interesting!)

Ah, I see the point of the cache - a very plugin-specific version of a more general cache. Clever!

Lastly, I noticed something extremely clever - you managed to create a TWiki topic without having to go through EDIT.CGI! I have seen this request numerous times with few good answers. In looking at your code, though, I did discover the reason why tasks and plans are not parented appropriately (the tempates end up being the parent topics). It is because the ppSavePage routine is not setting the $meta data correctly. I looked at EDIT.CGI but I am not at this level of comfort yet.

Anyway, I hope I can help in any way. I will likely send you a patch diff to show you the changes I made - perhaps they will prove useful.

-- SteveRJones - 24 Nov 2004

Hi Kiran ,

How can i use ProjectPlannerPlugin in my code.Will this work if i use this as like a perl module.

Rgds,

Shine.

-- ShineV - 15 Dec 2004

Hi,

I have just upgraded from 2.010 to 2.040 and everything appeared to be ok except when I wanted to add three different variables, say %PPPROJECTPLANS%, %PPALLPROJECTTASKS% and %PPDEVSUMMARY% in one single page. Then the topic hangs. It does even happen with two variables in one page - I've tried %PPDEVSUMMARY% and %PPDEVDETAILS%. Of course I have not tried every possible combination but it seems to me that some of the variables are too demanding and they cannot coexist with other varibles in one single page. Anyone noticed this ? Please advice. Thanks. Miguek

-- MiguelDuran - 15 Dec 2004

please somebody help me to how can i use ProjectPlannerPlugin in my perl code

-- ShineV - 16 Dec 2004

Miguel, I have used three variables in the same page but have not noticed a hang though the ones I have used are different variables. I might not be able to figure out remotely what is wrong, but can help you with debug if you want and know a little perl.

I looked through the plugin code and cannot think of any dependecy or problems with three tags.

-- KiranBondalapati - 04 Jan 2005

Shine, I am not sure how well the plugins work as a perl module? The TWiki architecture takes care of calling the different functions of the plugin (initial, commonTagsHandler, etc.). Also, the plugin relies on the cgi query being passed sometimes. It also needs to read the text pages of data from TWiki by using TWiki builtin functions. It can be changed for all that, but I do not have any plans of making it stand alone without TWiki.

-- KiranBondalapati - 04 Jan 2005

Migeul, BTW, let me know if you did not see the error in 2.010 and you are seeing the hang in 2.040.

-- KiranBondalapati - 04 Jan 2005

Hi, After some investigation i discovered that this plugin is not happy running under mod perl frown

Can anybody think of a workaround ?

-- StuartHannay - 11 Jan 2005

Ok, after doing some digging, the reason for no output is related to using mod_perl. See the discussion at SettingLibPath.

The change was simple. Here is the diff (one line to add), well two with comments smile

diff -r1.1 ProjectPlannerPlugin.pm
82a83,84
> # Ensure the library paths are set during compile time
> BEGIN { unshift @INC, '.'; require 'setlib.cfg'; }

However all is still not well. One thing I noticed is that the PPDEVSUMMARY & PPDEVDETAILS tags do not list all developers (however all developers do show up in PPALLPROJECTSINFO and PPALLPROJECTSTASKS) .....

-- StuartHannay - 12 Jan 2005

Stuart, the diff you posted always works? even in normal mode? I can try it and add it.

I can look through the code to see if I have obvious bugs missing all developers.

One known issue I should mention though is that there is a known problem with repeating task names across multiple projects and plans. If you end up leaving default names for tasks, you could expose this bug. I have a fix for it and I should release it in the next revision. If you really need it email me and I could send you a patch. I changed the indentation in my local version from last release and it is a pain to figure out the exact diff now smile

-- KiranBondalapati - 13 Jan 2005

Kiran, The diff does not effect running without mod-perl. However I don;t think all is well. From research t seems mod_perl has an issue with globals, and from my no perl skill perusal of the code it looks like the cache relies on globals ?

For now I have the plugin runing in a web with mod_perl disabled.

cheers Stu

-- StuartHannay - 13 Jan 2005

Another question, what was the reasoning behind using the estimated days time for a done task ? (in for example PPPROJECTPLANS ) ? Thanks

-- StuartHannay - 13 Jan 2005

I have not documented well the handling of days. I hope to do it in the next release.

If you read the original documentation (perl code wink ) :

The idea was that once a task is done someone did not update the correct number of days spent and just marked it done (like all guys do at our installation).

-- KiranBondalapati - 20 Jan 2005

Request For Feedback: I am posting what I have in the next version. If there are easy requests then I can incorporate them into the release:

  • Added a pseudo SQL like query based on columns
    • This is not expected to be a full fledged database query mechanism but rather a lightweight way to extract required information from the project data. For the purpose of the query you can think of the tasks in each Plan as a table with common description across all plans. You can use the query mechanism to select all the rows of all the plans in the web which match the criteria specified using the query mechanism.
    • The tag used for the query is PPQUERY
    • The parameter passed to the query is a list of field operator value triplets.
    • field: The fields are predefined set of columns that are based in the table defined above. In addition to the columns of the task table that are described in the Plan Template, additional fields that are supported are PROJECT, PLAN, and PROJECTPLANTASK. All the parameters including these three take * as a wildcard.
    • operator: Only operators current supported are =, <, >. Also, < and > are not intelligent and do a dumb integer comparison of two fields so it is advisable to use it only for number fields
    • value: It is a regular expression. The only operator supported in the values currently is the | which indicates the logical OR. Unspecified fields have no restriction and unspecified projects, plans and tasks mean all of them.
    • e.g. PPQUERY{PROJECT=My*Project;TASK=Jan*Task,DEVELOPER=myuser;STATUS=not started|in progress;STATUS=high}

  • Added configuration settings that can be picked using web options
    • ProjectTemplate and PlanTemplate: Instead of using a fixed topic names as the templates for projects and plans, we now use an option. However, the PlanTemplate would still require the presence of the columns that are mentioned in the table above so the script can parse the columns appropriately and present the different views. (PROJECTPLANNERPLUGIN_PROJECTTEMPLATETOPIC, PROJECTPLANNERPLUGIN_PLANTEMPLATETOPIC)
    • Timescale: Now we also support Est. Time rather than Est. Days so the time units can be interpreted as required by the project. However, there are a couple of places where estimates are converted into calendar dates. Specifying the Timescale to a legal value will make this accurate (if you care). (PROJECTPLANNERPLUGIN_TIMESCALE)

  • Additional Handling of Est Time and Spent Time
    • Track Overflow of Spent over Estimate: By setting this parameter, the plugin will handle Est Time and Spent Time differently than default. The default behavior is to assume that when a task is done, the Est Time is the only valid value and actual spent time was Est Time. However, by setting this option, the plugin will track them separately and report the number of days over the estimate that were spent. (PROJECTPLANNERPLUGIN_TRACKESTOVERFLOW)
-- KiranBondalapati - 21 Jan 2005

Stuart, I have no way of really avoiding globals. When I set some state in some functions, the other functions use the globals and TWiki takes care of persistence of the globals due to loading the module I think.

Also, I realized that I did already add documentation of how the days are handled in the ProjectPlannerPlugin page.

-- KiranBondalapati - 21 Jan 2005

Hi folks -- I just installed this plugin and it looks like it might be useful. I've tried phprojekt and projectbench (standalone web-based open source project managers) and so far ProjectPlannerPlugin looks like it's almost as good, and being built into twiki is a huge plus for us.

A couple of things bother me so far:

  • the plan table (PlanTemplate) is definitely too wide. Adding a <font size=-3> tag helped that quite a lot.
  • Having to name Plans as WikiWords is a huge pain! All our plans want to be named things like AVX 1.0 or release 3.07beta1, and wikifying those names produces terrible ugliness. Is there any way around that?! (I discovered I can do it by manually copying the template on the server and renaming it, not the best plan in the long run though.)
  • There needs to be a way to move a task from one plan to another (e.g. to defer it from this release to the next.)
I wonder if what's needed isn't a real SQL database with twiki front end. Is anyone thinking along those lines?

-- GaryOberbrunner - 02 Feb 2005

StuartHannay, we are running PersistentPerl (or SpeedyCGI) as an alternative to mod_perl and have zero issues with it as long as one uses the PersistentPerl by invoking it from the #! line (not as an Apache module). Speed appears to be equivalent to mod_perl without all of the caveats.

-- SteveRJones - 03 Feb 2005

For some reason, the Projectpage does not list Tasks if NOSEARCHALL is set to on in the WebPreferences for the Project Web.

-- WolfgangAlper - 11 Feb 2005

Gray, where did you place the html tags? I tried it within the Topic enclosing the PPVariables with partial success. The text messages render as expected, but the table has still its original size.

-- WolfgangAlper - 11 Feb 2005

I just installed ProjectPlannerPlugin, and had to edit the project error page, because it had eight spaces before the *, rather than the 3 my system wanted.

Also, it is too bad that projects have to have WikiWord names. We have lots of projects with names like "ADP" and "Hawaii" which are not supported.

Finally, a question: can I change the columns in the task list by just editing the table? If so, are there any columns that I must not change? (Or is it one of those things were you can add, but not change anything.)

-- JoshuaLevy - 24 Feb 2005

I just saw that my question is answered in the doc. Sorry about that, but I'm still interested in being able to name project with non-WikiWords

-- JoshuaLevy - 24 Feb 2005

Is there any way to change the columns in the summary task table on the project's page? I have added a "due date" column to the task table on the plan page, and I would like to see that data on the summary table on the project page. Also, the "Summary" information is useless to me, so I would like to remove the field from the entire plugin. Is that possible?

-- JoshuaLevy - 25 Feb 2005

Kiran, referring to some feedback that I gave back in Nov, 2004:
- Refer to The Parent Problem. Newly created tasks and plans are not parented correctly - they become children of your templates and not the appropriate parent. I believe this is due to not passing the the correct parent to your topic creation code.

-- SteveRJones - 08 Mar 2005

Is there any way to have add a column for estimated completion date or actual completion date? Or a column for estimated start date or actual start date?

-- TenniTheurer - 28 Apr 2005

Just wanted to report that I had to disable ProjectPlannerPlugin on my site due to the fact that it reads ALL the pages of a web. Maybe using a naming convention, or just posting a warning on the possible slowdown would be good ? See WhyIsTwikiSlowAndReadingALLTopics for more details.

-- GillesEricDescamps - 23 May 2005

Have a look at Basecamp: this is state-of-the-art shared project management. Any TWiki project planning plugin may learn from this.

-- ArthurClemens - 25 May 2005

checked http://twiki.org/p/pub/Plugins/ProjectPlannerPlugin/ProjectPlannerPlugin.2.040.zip into CVS

-- WillNorris - 19 Jul 2005

Hi, I have installed ProjectPlannerPlugin, and made the following alterations to ProjectPlannerPlugin.pm:ppSavePage

    my @metaargs = ( "name" => "$parent" );
    $meta->put( "TOPICPARENT", @metaargs );

This fixed the parenting problems for me...

-- DavideSantolin - 03 Aug 2005

One problem I'm having trouble when creatingNew Projects or Plans... The following Software Error is displayed:

Insecure dependency in open while running with -T switch at /var/www/twiki/lib/TWiki/Store.pm line 986.

The project pages are created anyway, but the error is bad for users.

I know itis to do with Tainting , has anyone else experienced this problem and/or has a fix?

I'm using:

  • ProjectPlannerPlugin 2.040
  • TWiki20040902
-- DavideSantolin - 03 Aug 2005

Has anyone gotten this to work with Dakar?

-- AndyWilcox - 09 Nov 2005

With Dakar, when jumping to a non-existant web, this error is thrown:

Can't create file /home/httpd/twiki/data/<non-existant webname>/.ppcache - No such file or directory

I am not a user of this plugin, just wanted to note this somewhere.

-- SteffenPoulsen - 09 Jan 2006

The problem Steffen mentioned was just the tip of the iceberg. It had to do with the Store function changing to a Func function if I remember correctly. After that, there are still many problems to deal with - like creating the Project.

-- JohnnyKwei - 26 Feb 2006

To the Plugin maintainer: Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 27 Feb 2006

Just uploaded a version that "work for me" on Dakar. Hope that it will work for you as well.

-- IsaacTo - 18 Apr 2006

Thanks Isaac for contributing this.

There are now many attachments on the Plugin topic, which is confusing for the admins downloading the Plugin. It is more customer focused if there is just one zip file that runs on Cairo and Dakar.

-- PeterThoeny - 19 Apr 2006

Hi, I just installed the ProjectPlannerPlugin on

* Windows XP * Perl 5.8.7-5 (Cygwin) * Apache/1.3.34 (Win32) * TWiki 04 Sep 2004 $Rev: 1742 $ then create a separate web for projects and put some Test-Projects and -Plans in this web. Now I can't open the WebHome-Topic of this web with the projects summary - after clicking on the link the browser send the request, but nothing happens... Using the web search I can open the separate project-topics - the only problem is the WebHome-Topic. Can anybody help me?

-- GeorgiNachev - 18 May 2006

The main page for the ProjectPlannerPlugin says to add the following tag after installing

% PPALLPROJECTS%

The space after the percent sign means it is not evaluated and it appears the plugin doesn't work (I copied and pasted off the HTML)

-- KeithPlayer - 19 May 2006

This plugin causes a 500 Internal Server Error if someone tries to view a non-existing web. Although this definitely a user error, the standard error message of TWiki about the non existing web is much more helpful than just throwing an internal server error. I therefore suggest to include a check in the initialization phase of the plugin like

    # Check if Web exists
    if ( !TWiki::Func::webExists( $web ) ) {
        TWiki::Func::writeDebug( "-  TWiki::Plugins::${pluginName}::initPlugin(
$web.$topic ) doing nothing, since web $web does not exist" )    if $debug;
        return 0;
    }

-- JChristophFuchs - 31 Jul 2006

Oops! I realized people do use this plugin after I stopped getting emails about it. I only read twiki.org very rarely. Thanks Isaac for fixing it for the Dakar release.

Sorry for the lack of maintenance on the plugin. Originally twiki was our group installation and I could hack all around it. Since it has been more widely adopted at our company it is now a sysadmin administered with very few permissions for others (including plugin authors to muck around). I cannot easily change it and look at new info/debug. Andrew Barber has updated this plugin and has done some cleanup of code. Please find it at OoProjectPlannerPlugin. There is more luck in getting things fixed in that version (and as Andrew says - real work gets in the way smile )

>>>>>>>>>>>
The main page for the ProjectPlannerPlugin says to add the following tag after installing

% PPALLPROJECTS%

The space after the percent sign means it is not evaluated and it appears the plugin doesn't work (I copied and pasted off the HTML)

-- KeithPlayer - 19 May 2006

Sorry about that but I was trying to avoid it being interpreted when in the doc section. I did not think that people would cut and paste :)

>>>>>>>>>>

Just wanted to report that I had to disable ProjectPlannerPlugin on my site due to the fact that it reads ALL the pages of a web. Maybe using a naming convention, or just posting a warning on the possible slowdown would be good ? See WhyIsTwikiSlowAndReadingALLTopics for more details.

-- GillesEricDescamps - 23 May 2005

Guilty! I am not sure if OoProjectPlanner fixes this issue. I uploaded a fix in version 2.050 on the twiki page with the fix. I also rolled in the topic parent fix suggested above and the non-existent page fix.

However, I did not test it due to reasons mentioned above. Try it after backing up previous version.

-- KiranBondalapati - 23 Aug 2006

To the maintaines of this plugin: Please use only one name ProjectPlannerPlugin.zip, not ProjectPlannerPlugin.2.050.zip etc. TWiki versions attachments, there is no need to version by file name. Also, latest version cannot be detected by a program if the zip file name has a version number.

-- PeterThoeny - 27 Aug 2006

I'm trying to get the most recent version (2.050) working on a TWiki 4.0.4 install (running on Apache 2.0.55 and Perl 5.8.8 on Linux). %PPALLPROJECTS% displays the new-project form on the page where I've included it, but when I actually go to create a new project, I get the following:

TWiki detected an internal error - please check your TWiki logs and webserver logs for more information.

Can't use string ("TOPICPARENT") as a HASH ref while "strict refs" in use

-- ScottAlfter - 05 Sep 2006

I encountered the same problem, Scott. I'm not a Perl guy, but by commenting out this line:
TWiki::Meta::put( 'TOPICPARENT', @metaargs );
in the ppSavePage method solved the problem. I've send a mail to the author describing what I did. See also Support.HowToUseProjectPlannerPlugins

-- MarcJSVerwerft - 26 Sep 2006

Unfortunaltely, the fix I provided only partly works. You can create projects and plans but when you revist the pages afterwards, the projects don't show up in the projects list and the tasks are not linked to the projects frown

-- MarcJSVerwerft - 26 Sep 2006

How do I delete a project in a tidy way? The only way I can see is to remove links to the project and then clean it up via the interface for tidying up orphans.

-- SteveWray - 17 Oct 2006

Feedback to contributors of this plugin: Please submit new plugin versions by overwriting the existing ProjectPlannerPlugin.zip attachment; do not attach files with versions number (e.g. do not use ProjectPlannerPlugin.2.050.zip etc) because the download links in the queries will point to old versions. TWiki version controls the attachments, so there is no need to put that into the filename.

I just noticed that the latest ProjectPlannerPlugin.2.050.zip contains just the .pm file in the root directory. I suggest to update the .txt topic with change history, package it properly, and re-attach it as ProjectPlannerPlugin.zip.

If you have partial updates, best to attach diffs to this dev topic here.

-- PeterThoeny - 27 Oct 2006

I had a little trouble getting this plugin working. I had placed the %PPALLPROJECTS% variable on a web i had created for project as instructed. I could create new project but they would not display on the WebHome page. It turns out the _ppcache file was not being written to. The piece of code in ProjectPlannerPlugin.pm that was causing the problem was an if statement that compared $cacheStat[9] < $latestStat[9] . Ths code compares the timestamp on the _ppcache file to that of it's parent directory. Once i uncommented out this code the plugin worked fine.

-- IanClancy - 21 Dec 2006

Hi can someone confirm if this works with Apache 2.2.4 and Twiki 4.1.1? thanks

-- JasonOKeeffe - 01 Mar 2007

I've added a patch file that adds a "Remaining Days" to the project summary (as Remaining Days is not always equal to Estimated - Spent...). It also stops Cancelled tasks being counted as progress, which was rather strange.

-- MikeMoreton - 02 Mar 2007

Hi, I installed the ProjectPlannerPlugin. I have created a Test Project From that page I had created a Test Plan. But in the Projects page in the I don't see any details regarding the plan. Also if I try to use %PPALLPROJECTS% or %PPALLPLANS% no project or plans are showed. Can someone please advice, Thank you, Rotem.

-- RotemGlasner - 10 Jul 2007

I think I had a similar problem that was solved by manually deleting the ProjectPlanner cache files.

-- MikeMoreton - 11 Jul 2007

It's a bug in the program flow, it's not written to standard like TagMePlugin. For version 2.050 I added code to delete the cache file in ppReadCache before the code that reads it.

-- SeanDwyer - 12 Sep 2007

Following SeanDwyer's advice, I did this to fix the issue in the ppReadCache function.

    # if there is no disk cache file, build one
#    if (! (-e "$cacheFileName")) {
#        TWiki::Func::writeDebug( "- NO CACHE, BUILDING DISK CACHE" );
#        &ppBuildCache($web);
#    }
    &ppBuildCache($web);

Basically, commented out the if file does not exist and causes it to build the cache every time it need to read the cache.

-- DouglasWoodgate - 02 Oct 2007

The ProjectPlannerPlugin topic is a bit out of date with wrong information, wrong version and several strange attachments which means that the plugin installer feature in configure will not be able to install this extension.

The plugin has a Feel Free To Modify policy. Can the last maintainer please update the plugin topic and cleanout the attachments so only the last version is visible with the right filename? And also please update the form to the current version.

This plugin is also on Subversion but not kept up to date there either.

-- KennethLavrsen - 03 Oct 2007

On a fresh install of TWiki 5.1.0 (VM), the ProjectPlannerPlugin fails to either compare or recreate the ppCache file. The workaround is, as SeanDwyer suggests, to add an unlink($cacheFileName); at the beginning of sub ppReadCache.

Edit: Snap, I've just realised that this does the same thing as the workaround of DouglasWoodgate.

There's another problem which I'm not experienced enough to debug and it's that even though the project does not exist and it does get created, the plugin redirects to the NewPageError after creating it. By Commenting out the if() call where it checks if the topic exists, the problem obviously disappears, though this is only patchwork and not too elegant a solution.

-- FernandoEblagon - 2011-09-15

Does anyone know who can I query for tasks that are due today. I tried this

Task due today

%OOPP{action="querysummary" project="%TOPIC%" query="Due Date<=Today()" group_by="Developer"}%

And it didn't work for me.

My 'Due Date' is in this format date, 11, , %m/%d/%Y.

-- AnkitShah - 2011-09-30

As others have noted, this plugin really doesn't work as currently distributed in TWiki 5.1. I suggest that it not be labeled as "tested" in version 5.1 as that's really misleading. The mechanism the plugin uses to save the document fails (generating a NewPageError) because save is performed from the commonTagsHandler which is called many times during the generation of a page. Adding a flag to indicate that save was already called and skipping save avoids this problem. The cache rebuild fails because it looks at the /pub directory's timestamp to see if the cache should be rebuilt, but topics are saved in the /data directory.

Because of these obvious bugs in a tested plugin, I'm a bit concerned about the meaning of the "tested" field in plugin descriptions.

-- Paul Merchant, Jr. - 2013-08-30

TWiki.org is a wiki maintained collaboratively, please feel free to fix stuff that is not correct. That is, remove the tested on flag for 5.1, or better yet help fix the bug.

-- Peter Thoeny - 2013-09-02

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiffs ProjectPlannerPlugin.pm.diffs r1 manage 9.4 K 2007-03-02 - 09:52 MikeMoreton Patch to add "remaining days" column to project summary
Edit | Attach | Watch | Print version | History: r99 < r98 < r97 < r96 < r95 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r99 - 2013-09-02 - 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.