Project Server 2003 overwriting published EFs

[Stephan Steiner]

Hi

I thought I had already posted this yesterday but cannot find the post
anywhere so perhaps I forgot to submit and apologize in advance for
any double post should my eyes or google groups deceive me.

Anyway, we recently published some enterprise fields in read-write
mode, so that resources can write into them. Now we have resources
that swear that the values they enter into those fields magically
change overnight.

So I started investigating and managed to reproduce the issue. It
seems the problem happens whenever a resource makes a change to one of
those enterprise values while the project is being worked on in the
project client. Upon saving the project, any changes made between the
point where the project has been loaded into the client, and the point
where the project has been successfully saved, is being lost and the
value that was there prior to opening the project in the project
client is being restored.

I also tested this with time reported, and it seems there the changes
survive the same scenario - the same also goes for writeable standard
fields (we have fixed work tasks so our resources can change remaining
work).

However, I'm left wondering if we did something wrong when publishing
those EFs as I have a hard time wrapping my mind around that EFs that
appear in the timesheet and are writeable would be overwritten when
somebody is working on the project in the meantime.. it makes the
whole idea of having writeable EFs completely useless as we cannot
guarantee stability on those fields and we risk overwriting values
entered by resources (I understand that if assignments are republished
fields are being overwritten but we're not doing that.. a simple
saving the project, or also accepting a timesheet will do the trick
just fine).

Regards
Stephan

 

[Dale Howard [MVP]]

Stephan --

Let's go back to my original question. The behavior you are seeing is
usually caused by a project manager publishing a project using Collaborate -
Publish - Republish Assignments. Have you checked with your PMs to
determine if anyone, or all of them, are publishing their projects this way?
Because if any of them are, this is not the right way to publish. They need
to use Collaborate - Publish - All Information after each round of revisions
or updates to their projects. Let us know what you find.

 

[Stephan Steiner]

Hi Dale

The issue was first noted (and so far only noted) on projects which are
automatically managed by an application I have written (well.. two
applications.. one writing tasks using PDS, another one publishing tasks
using "Publish New and Changed Assignments" but only for visible tasks (I
set a boolean EF for all tasks I want to publish, then select a view which
shows only those tasks, then call

application.PublishNewAndChangedAssignments(false,
Microsoft.Office.Interop.MSProject.PjPublishScope.pjPublishScopeVisible,
false, Missing.Value);
)

However, this happens exactly once in the lifetime of each task.. none of
these projects must be published manually ever, and all people having access
to these projects know that they have no business even opening those
projects except during the process of timesheet approval.

So, with regards to those tasks I used to testing only Publish New and
Changed Assignments were used. And there's no project manager opening the
projects and making adjustments to the plan.. all that is done using the
client is approving timesheets, and publishing of the new tasks.

Regards
Stephan

 

[Dale Howard [MVP]]

Stephan --

I suggest you repost this question in the microsoft.public.project.developer
newsgroup. Hope this helps.

 

[Stephan Steiner]

Dale

Why post it to the developer group when it is standard functionality by the
Project Client and the process that causes the problem is a manual one?

The issue also happens with manually created projects. It's just that we
have a bunch of projects where we have no project manager adapting the
plan.. they just write tasks once and from that point on there's no PJM in
the traditional sense... the PJM just adds additional tasks if necessary and
publishes them selectively (using the same mechanism I'm using in my
software) and accepts submitted timesheets.

Regards
Stephan

 

[Dale Howard [MVP]]

Stephan --

I'm surprised you challenge my recommendation. Since your PMs are not the
ones publishing their projects, and you are using PDS to do this, you might
be seeing an issue related to your automation routines. So, perhaps our
developer community could comment on what you have done. I leave that up to
you.

 

[Stephan Steiner]

Dale

I'm not challenging your recommendation - I merely pointed out that by
process of elimination I have already eliminated my programming as a source
of the problem. If I create a new project plan and publish it the way I
described (opening the plan, selecting Collaborate - Publish New and Changed
Assignments), and then have resources report and me approve the hours (and
not using any publish functionality again), the issue can be reproduced.

Needless to say that I agree that it is crucial to eliminate potential
problem sources one by one to track down the root of the problem - hence me
trying out to reproduce without any third party application interference.

Regards
Stephan

 

[Gary L. Chefetz]

Stephan:

I think the software is behaving as designed, despite the fact that it
doesn't bode well for what you're trying to accomplish. Assignment level EF
values are roll-down values from their associated tasks. I suspect that the
calculation engine is responsible for pushing these values down to the
assignment level. What may be happening is it's pushing that value down with
each save and/or publish. What happens if you turn automatic calculation off
and the refrain from calculating the project until after it's saved, and the
re-opened and then process the updates? I'm not sure there's a way around
this behavior. The most important thing you need to consider is that the
system does not carrry discreet values for EFs at the assignment level. If
you have more than one resource per task, the person who entered the last
value wins.

--
----------
Gary L. Chefetz, MVP
MSProjectExperts
Project Server Consulting: http://www.msprojectexperts.com
Project Server Training: http://www.projectservertraining.com
Project Server FAQS: http://www.projectserverexperts.com
Project Server Help Blog: http://www.projectserverhelp.com

 

[Stephan Steiner]

Gary

I'm afraid my initial post lacks some data, besides the fact that I can
reproduce with a blank project and no macros:

1) We're dealing with task level enterprise fields here (just for good
measure I went through each field to verify and it is definitely so)
2) We use the highlander principle for all our tasks (based on the
suggestion of the consultants we hired to help with the design - at one time
we thought we knew better but we had the pay a price for that and went back
to the original concept) - so one resource per task.

I checked the field definition, but the fields I'm refering to neither have
a formula behind them, nor do they have a calculation (and thus rollup)
defined. One field is a date field which is as is, and two fields are flag
fields which have a value list (yes / no).

So, I'm not if there's any calculation to be turned off (my main job is
designing and writing software so working with the project client isn't my
daily business) in this scenario. If so, could you tell me what I need to
change in order to go through the steps you mentioned?

Regards
Stephan

 

[Gary L. Chefetz]

Stephan:

I was referring to the scheduling engine that underlies the Project client,
so it doesn't matter if your fields have formulas or not. All task-level EFs
have a rolldown feature. All but text fields have a roll-up value. The value
of a task field is stored at the task level and rolled down to assignments
and up to summary tasks. In the project client, you can set calculation to
manual from Tools > Options > Calculation Tab. I was wondering if the
behavior changes when this is set to Manual.

--
----------
Gary L. Chefetz, MVP
MSProjectExperts
Project Server Consulting: http://www.msprojectexperts.com
Project Server Training: http://www.projectservertraining.com
Project Server FAQS: http://www.projectserverexperts.com
Project Server Help Blog: http://www.projectserverhelp.com

 

[Stephan Steiner]

Gary

Sorry for the late reply - some other things took priority.

Anyway, I did what you suggested and performed a bunch of tests and the
results are mixed.

For one, if resource makes a change to a writeable EF in their timesheet
and submits that (without reporting actuals or making any other changes in
that line) while the project manager has the project open to approve hours,
the EFs are no longer being overwritten.

If , however, the resource both enters actuals and changes a writeable EF
for the same task and then submits that and then the project goes through an
approval process without the particular task being approved.. the EF is
being reset.

Likewise if a resource reports actuals, then the plan is opened for approval
but not saved yet, and during that time the resource changes the EF, upon
saving the plan the EF is being overwritten, and approving the second update
won't change anything.

So, even if automatic calculation is disabled, writeable EFs are still
unsable.

Regards
Stephan