Monday, June 30, 2014

Change a custom field label in PDPs

When you're in charge of a large Project Server deployment, you might face concerns and issues that are due to the project scaling. When I say "large", I mean thousands of users, hundreds of custom fields, tens of project types, PDPs...

In this context, in order to keep a consistency between lookup tables, custom fields or any other objects, I usually use a naming convention such as "lkp_table name", or "organization_customfieldname" for multi-organization deployment. Thus it means that you do need to find a way to display a custom label for those custom fields, different from the name in the system.
Figure 1: naming convention for lookup tables or custom fields

It also make sense for out-of-the-box fields such as "project Owner". In many case, the project owner will be a project manager, but it could be a PCO. Thus organizations might want to give a custom label to this native field.

Facing this concern, evenif I'm not a developer, there is an easy way to give custom label. So enjoy it because that will probably be the one and only post I'll ever write about coding. But as you'll see, it is not much difficulty.

We'll make a simple example with the "owner" out-of-the-box field.
Figure 2: default owner field

First you need to download the following jquery librairy. You can upload the js file to the style librairy of your PWA site collection, accessible from the "site contents" link. Once uploaded, you can download from the TechNet gallery a script provided by a fellow MVP Paul Mather. Download the script for example in your site collection document librairy (sites/pwa/SiteCollectionDocuments).

You can edit the js file and replace the custom label.
Figure 3: update the js file with your custrom label
Then edit your PDP from the server settings and add a content editor webpart.
Figure 4: add a content editor webpart to the PDP
Edit the webpart then enter the path of your javascript file (/sites/pwa/SiteCollectionDocuments/ChangeCustomFieldDisplayLabelonPDP.js in my case) and set the webpart as "hidden":

Figure 5: enter the javascript file's path in the webpart configuration and hide it

Et voilà!! The native field is "renamed" as you needed to.
Figure 6: PDP with the new label

Note that if you have installed language packages, since the code contains the name of the field and not the GUID, you'll need to consider writing in the javascript file the label for custom field in all languages supported on your PWA instance.

**2014-08-01 : need to add a function or it will not work. I'll update the post asap.
**2015-06-22: post (lately) updated with a new code example, based on Paul Mather's excellent post.

Share this article :

9 comments:

  1. Ótimo Guillaume, eu já precisei disso algumas vezes mas não tinha conseguido, muito bom.

    ReplyDelete
  2. In PS 2013 not funcionallity :(. There is one solution for this?

    ReplyDelete
  3. Hello, Thank you for the post! Quick question. I have 3 labels for 3 different custom fields that I need to modify. Would I need to insert 3 content editor web parts and have 3 different js files to use as well?

    ReplyDelete
    Replies
    1. Also, when does the js get executed, when the page is loaded the first time? The simple example with "owner" is not working for me. even though I can see the snippet of code when I am editing the Content Editor web part. Thanks!

      Delete
  4. Finally I updated the post, it should work now.

    ReplyDelete
  5. This is great for PDP pages, do you then maintain these custom labels in reporting somehow? Excel reports would show the "real name" and force you to maintain this somewhere for accuracy. Maybe a mapping table stored on the Project Server governance site.

    ReplyDelete
  6. Good remark Stephen! Either a custom table or a sharepoint list could be used for mapping fields in the reporting.

    ReplyDelete
  7. I can get this working for standard fields and custom fields. However, it will not work for required fields. Any suggestions?

    ReplyDelete
  8. I can get this to work with standard fields and custom fields. However, it does not work with required fields. Any suggestions?

    ReplyDelete