Modifying Risk List Problem

[ChrisP]

Hi,
I have modified the risk and issues lists in our WSS template for our
Project Server 2007 implementation only to find that risks and issues now do
not appear on people's PWA pages. Further research indicates that I should
not have modified the status values. I have re-instated the default status
values and gone back to some risks and issues to reset their status values
accordingly. Issues now appear on the PWA pages but not risks. Could anyone
point me to more detailed technical advice on what else I may need to fix?

 

[Paul Conroy]

When you publish a project, do you get a sync error? if so, please post the
error.

 

[ChrisP]

The error messages are below. I know I get these because I modified the
issues and risk lists. The question is can I recover from this by fixing up
the modified lists and then delving to the synch process to correct anomalies
at that level. For the issues list I have already reinstated the "Owner"
field and fixed "Status" field values and can now see assigned issues in the
PWA - but I still get the error.

Note we picked this up in testing so have not implemented yet. I am happy
to start again from the standard issues and risks lists but be more careful
this time - any pointers on what must be avoided? I still need to modify
these to meet company standards for risks and issues management. In
particular, risk management is in accordance with Australia/New Zealand
Standard (AS/NZS 4360).

<error id="24018" name="ReportingWssSyncListFailed"
uid="9aad37f1-b326-47b9-9eb4-96d2af196918" SPListType="1100" Error="Failed to
prepare the transfer of SP list 1100 for project
'7b603507-edd4-4bab-838e-9e7706e91d9b'. The field Owner was missing from the
SP list and was ignored." />

<error id="24018" name="ReportingWssSyncListFailed"
uid="7856ce68-c8a2-49a3-9b0c-3b3e45972e72" SPListType="1101" Error="Failed to
prepare the transfer of SP list 1101 for project
'7b603507-edd4-4bab-838e-9e7706e91d9b'. The field AssignedTo was missing from
the SP list and was ignored." />

 

[Paul Conroy]

A good rule of thumb is not to delete/change the name/field type of any
default fields. Instead, create new fields that meet your requirements and
hide any system fields that are no longer relavent.

 

[ChrisP]

Thanks Paul, I've learnt my lesson. The amount of posts regarding problems
with customised lists is significant. Maybe someone in Microsoft could take
this onboard to either prevent the ease at which you can modify or post
numerous warnings when doing so.

 

[Ravi]

Thanks Paul, I've learnt my lesson.  The amount of posts regarding problems
with customised lists is significant.  Maybe someone in Microsoft couldtake
this onboard to either prevent the ease at which you can modify or post
numerous warnings when doing so.

Hi Chris,

Definitely this is something thats needed when anyone attempts to
modify/delete out of the box default columns. Status being such
critical column.
You can try a solution as below to fix this currently.

1. Get into the default view that includes the status column and
export it into excel
2. Delete and recreate the workspace
3. Get into the default view and "hide" (not to delete) the status
column. Meantime hide the status column value on the excel sheet.
4. Make use of this excel sheet and import the entire list.

This holds good if you have only risks in trouble and issues are low
in #. Also you do not have documents posted. Otherwise you can use
stsadmn.exe tool to export and import the workspace data, which is an
all time solution in your case.

Hope this helps!

Thanks,
Ravi.