If you’re like us (no one is like us) then you don’t use Project Server Workflows, but you have a project level field that you don’t want just any monkey to be able to change. You could use Department to hide this from other users and then use the PSI or PowerShell to update it, but that has some constraints, such as it’s not as easy as clicking a button to make the change – and in our case, the field needs to be updated by a very end-user level admin. (no offense to my coworkers if they are reading this!) So I will share with you our new “magical” workaround for this. There’s no query or anything in this – in fact it’s all done on the front-end! Can you believe I’m posting something with no query or Excel? Craziness.
If you’re a super-user, all I need to do is tell you the methodology behind this. I’ll also post step-by-step instructions that the rest of us would need.
The gist is that you add a multi-line text field at the project level (doesn’t show in the project client) then create a new PDP for your projects that has that field in its own Project Fields web-part, with audience targeting turned on.
Create a multi-line value text field at the project level. For our purposes, the field is called “Approval Status”.
Multi-line values are all rich-text enabled, so the Project client won’t display them.
If you happen to have PMs that don’t use PWA detail pages to update their schedules (like, ever) then you’re pretty much done right there. But in our scenario we let them make updates there (especially useful for sub-projects) so we have to take it a few steps further.
Within PWA, create a SharePoint group with the correct access for the field.
Create a new Project Detail Page
This is going to replace the default Project Information Page. I wanted to leave the original intact, so I just created a new one.
I created a new one “from scratch”, called “Project Info” (instead of Information. Obviously.). The “Page Type” should be “(2) New Project”.
On the new page, I added two “Project Fields” web parts. For the first one, I just added the fields that we need from the default Project Information page.
The second “Project Fields” webpart is where the magic comes in. Only add the multi-value field you created in Step 1. I named the web-part “Admin Use Only”.
Now go into the web-part properties and expand the Advanced section. Go down to Target Audiences. Add your SP group from Step 2.
Associate the new PDP with the Enterprise Project Type(s). Go to “Enterprise Project Types” and select the type you want to use the new PDP for. In our case, it was just “Basic Project Plan”.
Scroll down to the “New Project Page/Project Detail Pages” portion and make sure you remove Project Information and add your new page.
After that, you should be good to go!
There are three things you need to know about this. The first is that when you update the field in PWA for a project, after you save it will behave like it’s not going to save. It will ask you if you want to navigate away from the page, claiming that it won’t save. Don’t worry, it will and it did.
Two is that we do have one project that’s getting the dreaded 9133 error when we try to save it. But, we’re only having it with this one project, and we were able to update the field anyway by toggling the field back to a regular single line text value, setting it in Project, then changing it back.
Third is that the multi-line fields look ugly in the database. (they have a rich text/html looking markups around them. You can usually fix something like that in your query, especially if your field really isn’t for crazy text but simple values like yes/no or a date. If you get really desperate, a stored procedure can do the trick.
Anyway, hope this helps you rule your Project Server schedules with an iron fist!