Cascade Skyline - with Microsoft Logo and Project Support header - author Brian Smith

January, 2011

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Localization and the SDK Samples


    We had a support case this week relating to the use of the samples from the SDK on a Spanish version of Project Server 2010.  It was possible to work around the initial issues by installing the English version, and applying the Spanish language pack – but this isn’t an ideal combination if Spanish is the desired main language as certain things will always display in the the core language – and in this case English.  The biggest issue for the customer was that even with the Spanish language pack the labels for the project impact statements would still read None, Low, Moderate etc. instead of the desired Ninguno, Bajo, Moderado etc.

    So the best solution is to address the original problem – the sample not working on the Spanish version.  In this case it was the code for the sampleproposal2, supplied with the SDK as an example of how the out of the box sample proposal was coded.  Now the samples are not localized and this was the problem – some hard coded strings in the samples do not play well with a non English installation.  The first issue when trying to deploy the sample was “Error      1              Error occurred in deployment step 'Activate Features': Failed to create workflow association 'SampleProposal2 - ProjectWorkflow'. Cannot find SharePoint list with name "Project Server Workflow Tasks" . 

    Looking at the properties of the workflow it can be seen that the history list and the task list that the sample want to use are in English:


    So to correct this you can ensure you have the right localized lists – which can be found by looking at your site content (Site Actions, View All Site Content – or whatever this is in your language of choice).


    and again, in Spanish:


    Once these are corrected the workflow will deploy, but there is another issue.  Firstly like the English version you will need a user in the Portfolio Mangers group(“Jefes de cartera de proyectos” )  to be assigned the workflow tasks.  Once this is done then tasks will be assigned but it was found that once these tasks were approved they were not going all the way to Completed (which they do in an English version) but were sticking at Approved (or Rejected) – or rather Aprobado (o Rechazado).  Again, this comes down to a hard coded string – this time in the WorkflowStrings.cs file.  The first two string variables set are:

    public static string APPROVAL_TASK_OUTCOME_APPROVED = "Approved";
    public static string APPROVAL_TASK_OUTCOME_REJECTED = "Rejected";

    and these are used to identify when a workflow has reached the specific status – and then they are automatically moved on to Completed.  As the string in a Spanish system will be Aprobado and not Approved they just get stuck.  Just updating these strings to:

    public static string APPROVAL_TASK_OUTCOME_APPROVED = "Aprobado";
    public static string APPROVAL_TASK_OUTCOME_REJECTED = "Rechazado";

    will resolve things.  Obviously the code needs to be re-built, deployed and then the services stopped/started and an IISRESET – and the new workflow re-associated with an EPT before you see the change…

    As you will no doubt see there are many more strings in the WorkflowStrings.cs file that will make the sample more usable in a Spanish system if they were to be translated.  Most are just used in dialogs – so do not break anything if they are in English – apart perhaps from their understanding.

    Thanks to my colleague Sutendu for his help with this support incident.

  • Brian Smith's Microsoft Project Support Blog

    Project Server 2010: Permission problem when accepting New Task requests


    This probably isn’t a very common scenario – but you may run in to it.  In My Tasks a resource has the ability to request a new task on any of the projects they are working on (Insert Row, Create a New Task).  This request goes to the project owner (as there isn’t the concept of a status manager for a task that doesn’t yet exists.  However, if before it gets accepted the project owner changes we get into a strange condition.  If the new project owner goes to one of these new task requests in their Approval Center – and clicks on the name of the new task to see the details then they will see this error - You do not have sufficient permissions to view the specified page. Please contact your administrator for permissions to view this page:


    It will also throw some stuff in the ULS logs – I have added that at the end of this posting for the search engines to read – you can skip it if you want.

    The problem comes about because of a difference between the criteria used to offer updates for approval and those checked for permission to see the details.  The Approval Center is populated based on the ‘owner’ of the requested update (the new project owner) and when they click to see details the permissions check still sees the old project owner as the approver.  So I’d say the bug is that we do not update the approver for outstanding requests when we change the project owner.  Not sure when we will get this fixed but there are some simple workarounds:.

    • Just accept or reject without seeing the detail (Probably not the best idea)
    • Accept, and then review the detail by clicking into the History tab - and at this stage you will pass the security check.  The new task at this point is unpublished, so if you are not happy with it then you can revert the change by deleting from the plan and re-publishing.  (My favorite)
    • Make the original PM the owner again and they will be able to see the detail and accept the update. (could be difficult if they are gone – but you could use a dummy account)

    This only affects New Task requests as far as I can tell – normal task updates are not affected.

    And now for the boring stuff:

    ULS logs will show:

    EventID: 2q1K

    Level: Exception

    Message: System.Web.Services.Protocols.SoapException: ProjectServerError(s) LastError=GeneralSecurityAccessDenied Instructions: Pass this into PSClientError constructore to access all error information at Microsoft.Office.Project.Server.WebServiceProxy.Statusing.ReadAssignmentHistory(Guid itemid, AssnHistoryItemType itemtype)    at Microsoft.Office.Project.PWA.CommonControls.AssnHistory.OnPreRender(EventArgs e) 


    Level: Unexpected

    Message: Microsoft.SharePoint.SPException: You do not have sufficient permissions to view the specified page. Please contact your administrator for permissions to view this page.  
    at Microsoft.Office.Project.PWA.PJUtility.HandlePageError()   
    at Microsoft.Office.Project.PWA.PJDlgPage.OnError(EventArgs e)   
    at System.Web.UI.Page.HandleError(Exception e)   
    at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)   
    at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)   
    at System.Web.UI.Page.ProcessRequest()   
    at System.Web.UI.Page.ProcessRequest(HttpContext context)   
    at ASP._layouts_pwa_statusing_taskdetailsdialog_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\d0bde918\866ac2ac\App_Web_taskdetailsdialog.aspx.4e58013c.brzjlbjz.0.cs:line 0   
    at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()   
    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Page 1 of 1 (2 items)