Problem in booking with multiple ressources

[David F]

First, thank you for this product.

with the new version 0.10, I have problem to book multiples
ressources : in a supplement task, only the fisrt ressource is booked.
It was working well in 0.0.8.

Sample :
SaaS.software.Suivi26 {
booking dev1 2010-12-08-09:00-+0100 + 8.0h, 2010-12-09-09:00-+0100 +
8.0h, 2010-12-14-09:00-+0100 + 2.0h
booking dev2 2010-12-17-09:00-+0100 + 8.0h, 2010-12-23-13:00-+0100 +
2.0h
}

the booking for dev2 is planified in the futur.


You can find here the project to reproduce the problem :

project acso "Portail client" 2010-12-08 +6m {
timeformat "%Y-%m-%d"
numberformat "-" "" "," "." 1
currencyformat "(" ")" "," "." 0
now 2011-02-01-08:00
currency "EUR"
workinghours mon - fri 9:00 - 17:00

dailyworkinghours 8

scenario plan "Plan" {
projection { strict }
scenario delayed "Delayed"
}
}

copyright "©"

flags team

macro allocate_developers [
allocate dev1
allocate dev2
]

resource dev "Developers" {
resource dev1 "David" {
email "de...@test.Fr"
vacation 2010-12-20 - 2010-12-27-23:00
}

resource dev2 "Julien" {
email "de...@test.Fr"
}
flags team
}

task SaaS "Portail Client" {
task software "Développements" {
priority 500
start 2010-12-08

task Suivi26 "Administration globale" {
effort 2.5d
delayed:effort 3.5d
allocate dev1,dev2
}
}
}

supplement task SaaS.software.Suivi26 {
booking dev1 2010-12-08-09:00-+0100 + 8.0h, 2010-12-09-09:00-+0100 +
8.0h, 2010-12-14-09:00-+0100 + 2.0h
booking dev2 2010-12-17-09:00-+0100 + 8.0h, 2010-12-23-13:00-+0100 +
2.0h
}

resourcereport resourceGraph "ResourceGraph" {
formats html
scenarios delayed
headline "Allocation des ressources"
columns no, name, note {width 10}, effort, effortdone , effortleft ,
complete , daily { }
loadunit shortauto
# We only like to show leaf tasks for leaf resources.
hidetask ~(isleaf() & isleaf_())
sorttasks plan.start.up
}

[Chris Schlaeger]

On Thu, Feb 3, 2011 at 5:35 PM, David F <david....@gmail.com> wrote:
> with the new version 0.10, I have problem to book multiples
> ressources : in a supplement task, only the fisrt ressource is booked.
> It was working well in 0.0.8.
>
> Sample :
> SaaS.software.Suivi26 {
>  booking dev1 2010-12-08-09:00-+0100 + 8.0h, 2010-12-09-09:00-+0100 +
> 8.0h, 2010-12-14-09:00-+0100 + 2.0h
>  booking dev2 2010-12-17-09:00-+0100 + 8.0h, 2010-12-23-13:00-+0100 +
> 2.0h
> }
>
> the booking for dev2 is planified in the futur.

Not really, but there is clearly a bug. The new inheritance algorithm
for scenario specific attributes does not work for bookings. It
probably doesn't really need to because I don't think passing bookings
to child scenarios makes a lot of sense. You cannot selectively change
or override such inherited bookings. Probably the right way to go is
do disallow bookings for non-leaf scenarios. But I have to think about
this some more before I fix this.

Just move your bookings to the delayed scenario and it should work fine.

Chris

[David F]

OK, it's work with moving booking to the delayed scenario.

I made a mistake : I'm using the "plan" scenario for the initial
scheduling, and the "delayed" scenario for the actual life of
project.

I will inverse the 2 projects : the plan project will be the actual
project, and my delayed project will be the "initial" project.

Thanks,
David

[bdb]

Hi Chris,

Today i ran into a problem. I wanted to add a scenario "alternative"
to my "delayed" scenario. This is for figuring out what the effect on
the length of certain tasks at the customer is. So this is a possible
change in the plan, but I would like to have the bookings done for
"delayed" taken into account also for this alternative scenario.
Now I do double bookings, delayed: booking.... and alternative:
booking.
From my point it would be easiest if the bookings were inherited,
especially if there are a lot of bookings.

Regards, Bas

On Feb 6, 10:24 pm, Chris Schlaeger <cschlae...@gmail.com> wrote:

> On Thu, Feb 3, 2011 at 5:35 PM, David F <david.fuz...@gmail.com> wrote:
> > with the new version 0.10, I have problem to book multiples
> > ressources : in a supplement task, only the fisrt ressource is booked.
> > It was working well in 0.0.8.
>
> > Sample :
> > SaaS.software.Suivi26 {

> >  bookingdev1 2010-12-08-09:00-+0100 + 8.0h, 2010-12-09-09:00-+0100 +

> > 8.0h, 2010-12-14-09:00-+0100 + 2.0h

> >  bookingdev2 2010-12-17-09:00-+0100 + 8.0h, 2010-12-23-13:00-+0100 +
> > 2.0h
> > }
>
> > thebookingfor dev2 is planified in the futur.

>
> Not really, but there is clearly a bug. The new inheritance algorithm

> forscenariospecific attributes does not work for bookings. It

> probably doesn't really need to because I don't think passing bookings
> to child scenarios makes a lot of sense. You cannot selectively change
> or override such inherited bookings. Probably the right way to go is
> do disallow bookings for non-leaf scenarios. But I have to think about
> this some more before I fix this.
>

> Just move your bookings to the delayedscenarioand it should work fine.
>
> Chris

[Chris Schlaeger]

On Thu, Mar 24, 2011 at 9:39 PM, bdb <baslu...@gmail.com> wrote:
> From my point it would be easiest if the bookings were inherited,
> especially if there are a lot of bookings.

I though about this for quite some time now. Passing bookings to
sub-scenarios causes too many problems. Scenarios can be so diverse
that I don't want to take care of all the weired corner cases.

If you really need this, you can define your bookings in a macro that
has a scenario parameter. That way, you need need to write them once,
but can add them to as many scenarios as you like.

Chris

[grib]

Chris, I may be thinking about scenarios wrong, but the ONLY way I can
think about using them is such that inheriting bookings is important.

In my project, "bookings" represent what has really happened, and
scenarios represent different models for building a schedule for the
future.

So I have a "plan", a "best", and a "worst" scenario. At the start of
the process, they will diverge in the end dates, task ordering, and
other measures because my tasks have scenario-specific properties
(almost always effort).

When a task is complete, "best" and "worst" don't have any more
meaning; there is only the bookings.

By the time the project is completed, "plan", "best", and "worst"
should converge, because the only wiggle room they have to differ is
in the uncompleted work, which converges (slowly!) to zero.

Would a booking macro like you describe work in that use model?

Thanks,
Bill Gribble

On Apr 2, 1:13 pm, Chris Schlaeger <cschlae...@gmail.com> wrote:

> On Thu, Mar 24, 2011 at 9:39 PM, bdb <baslumin...@gmail.com> wrote:
> > From my point it would be easiest if the bookings were inherited,
> > especially if there are a lot of bookings.
>
> I though about this for quite some time now. Passing bookings to
> sub-scenarios causes too many problems. Scenarios can be so diverse
> that I don't want to take care of all the weired corner cases.
>
> If you really need this, you can define your bookings in a macro that

> has ascenarioparameter. That way, you need need to write them once,

[Chris Schlaeger]

On Mon, May 2, 2011 at 9:47 PM, grib <gr...@billgribble.com> wrote:
> Chris, I may be thinking about scenarios wrong, but the ONLY way I can
> think about using them is such that inheriting bookings is important.

Several users have requested that bookings should not get inherited.
So, there are other use cases.

But I agree, using the top-level scenario to track the reality with
bookings and have all derived scenarios inherit the bookings is
probably the most common use case. Macros would be able provide the
same effect, but I think this feature should be built-in. I'm already
working on a solution that works for both use cases.

Chris