David Tuma

Read-only WBS nodes become editable in subprojects

Read-only WBS nodes become editable after save

It's quite a bit more complex than a simple max(0, xxx) calculation. As you've stated: when computing the Replan date for in-progress tasks, the dashboard will subtract actual time from planned time to produce remaining time. Remaining time is then used as the "weight" for a new earned value calculation, as described here, to produce a set of replan dates. The Forecast calculation is similar, except it divides planned time by CPI before subtracting the actual time. If some of the in-progress tasks...

It's quite a bit more complex than a simple max(0, xxx) calculation. As you've stated: when computing the Replan date for in-progress tasks, the dashboard will subtract actual time from planned time to produce remaining time. Remaining time is then used as the "weight" for a new earned value calculation, as described here, to produce a set of replan dates. The Forecast calculation is similar, except it divides planned time by CPI before subtracting the actual time. If some of the in-progress tasks...

It's quite a bit more complex than a simple max(0, xxx) calculation. As you've stated: when computing the Replan date for in-progress tasks, the dashboard will subtract actual time from planned time to produce remaining time. Remaining time is then used as the "weight" for a new earned value calculation, as described here, to produce a set of replan dates. The Forecast calculation is similar, except it divides planned time by CPI before subtracting the actual time. If some of the in-progress tasks...

Different people have different work schedules: which days they work, and which hours. The Team Member List in the WBS Editor does not have a way to record those nuances; and the dashboard has no way to respect nuances that it knows nothing about. So the Replan and Forecast dates are based purely on calendar-time proportions: 24 hours a day and 7 days a week.

After testing, I was able to verify the root cause I suspected earlier: the size of the appended signature can change from one run to the next. Timestamping could be a contributing factor. Fortunately, the size isn't completely unstable; it usually differs by a few bytes, and toggles between two (or occasionally three) possibilities. This makes it feasible to produce a successful signature by iterating until the sizes match in two consecutive runs. I took a look at modifying the original sign4j.c...

I've been experiencing this too. Unfortunately it is nondeterministic; sometimes it works and sometimes it doesn't. When it works the file is signed successfully; when it doesn't, running the EXE results in an error message "Invalid or corrupt jarfile" from the launched javaw.exe process. Nothing in my build process changes; I can run the build again, and it might work the next time or it might not. Overall my success rate is only about 50%. The worst problem is that I can't detect this failure in...