After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 167521 - RFE: Better concurrent/sequential task handling
RFE: Better concurrent/sequential task handling
Status: RESOLVED DUPLICATE of bug 132917
Product: planner
Classification: Other
Component: General
0.12
Other Linux
: Normal enhancement
: ---
Assigned To: planner-maint
planner-maint
Depends on:
Blocks:
 
 
Reported: 2005-02-15 21:12 UTC by twilit77
Modified: 2009-05-21 23:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description twilit77 2005-02-15 21:12:26 UTC
Version details: 0.12.1
Distribution/Version: Mandrake 10.1

When using imendio for projects whose component tasks take up much or all of  
the actor's time, you tend to need one task to come after the next.  Imendio as  
it is, doesn't support sequential tasks very well, and assumes a concurrent  
task system (to the point that I can hardly work with it).  Here are some 
possible suggestions:  
  
1. Have a global radio option of "Assume tasks are concurrent" and "Assume  
tasks are sequential".  When the sequential option is selected, tasks ordered  
higher in the list would come before tasks lower in the list.  Tasks would  
automatically bump to when they could first be done, and the overall project  
time would reflect correctly.  
  
2. Have two differert mouse drags.  Regular dragging a mouse to associate two  
tasks would say, "These are sequential but don't depend on each other."  No  
dependency arrow would be drawn, and if the task reassigned or there is a task  
inserted before it, then the task's tenative starting time would be bumped to  
the appropriate place.  
  
The other would be Shift+Drag which would say, "Associate these as an old-style  
one-is-a-prerequisite-of-the-other."
Comment 1 twilit77 2005-02-15 21:14:15 UTC
That was ambiguous.  When I'm describing the mouse actions, and I write that a 
dragging action would "say" something, I mean that those mouse actions would 
essentially do that.  I don't mean that it would pop up some dialog or have a 
tooltip or anything 
Comment 2 Richard Hult 2005-02-15 21:44:39 UTC
This should be handled by some kind of resource usage algorithm in my opinion.
So if you specify that the maximum resource usage is 100%, tasks would be moved
so that the resources only work 100%, and the priority field should decide the
order. Would that work for you?
Comment 3 madcap 2005-03-29 15:13:53 UTC
I agree with Richard's approach. In addition, in PS Scheduler it is possible to
manually change the day-to-day allocation of resources to a task. This is
sometimes necessary when you have 2 resources on a task and the auto-balancing
like Richard proposes does something like have one resource assigned 100% for
the first half the task and the 2nd resource assigned 100% for the second
half... if the task is such that the resources must work together, this is wrong
and must be manually entered.

Even if auto-balancing is too complicated for now, allowing for manual entry of
resource usage from day to day on individual tasks would let us manually balance
at least. For example, if TaskA has 10 days of work, I'd like to be able to
specificy that ResourceP will expend 100% for the first 5 days, then 50% for the
next 10 days to complete the task.
Comment 4 Josep Monés i Teixidor 2005-04-15 11:45:03 UTC
I had the same problem with Planner, which I commented in the user's mailing
list here:
http://article.gmane.org/gmane.comp.gnome.apps.planner.user/497

Later, I had to switch to Microsoft Project 2000 because of interoperability
with other participants in the project (BTW, I could possibly have avoided the
switch if I had been able to export MS Project from planner) and I've realized
that it has a feature that's works ok to solve this: it's called Resource
Leveling and works by delaying tasks when overallocation occurs.

The part I like is that this information is kept apart from real constraints, so
I can wipe it just by using "Clear Leveling" option.

Perhaps that could serve as inspiration.
Comment 5 Alexandre Franke 2009-05-21 23:50:32 UTC

*** This bug has been marked as a duplicate of 132917 ***