Tag Archives: column

JSLink – Using the Lookup Column with CSR

This post covers another column type for use with CSR overrides. Lookup columns have what I consider an irritating default display characteristic in that they are displayed as a hyperlink to the lookup list item.

image

Where the link goes to:

image

The majority of the times I’ve seen a Lookup used, they are simply a list of items to select in a dropdown or radio buttons – like a category. In this case the hyperlink and displaying the form are useless (to me). Every so often the lookup list has a few other fields, like Description, etc. in that case the link can be a bit more useful, but it still seems to be more of a distraction from a user experience (UX) perspective.

What I’d like to see is the Lookup value – the same text – displayed without the hyperlink. I can get this value using the following:

ctx.CurrentItem.Theme[0].lookupValue

Or, more generically:

ctx.CurrentItem.[internalName][0].lookupValue

You can also access two other properties of the item. The properties are: isSecretFieldValue, lookupId, and lookupValue. And no, right now I have no idea what the heck ‘isSecretFieldValue’ is other than a Boolean value. Smile 

Note: OK. I looked it up. There’s one post under ‘isSecretFieldValue’ here – and if set to ‘True’ it apparently hides the values of the Created By and Modified By values in the form. Huh.

Back to our Lookup column.

As with several other column types, the Lookup column can contain more than one item and is stored as an array. As with those other column types you can also check how many items are contained in the column value by checking the length of the array:

ctx.CurrentItem.[internalName].length

Once an override is put into place using this approach, the list view now looks something like this:

image

Definitely cleaner.

Sample code for this example can be found here.

JSLink – Using the Person Column with CSR

When starting with JSLink and CSR (Client-Side Rendering) in SharePoint 2013 one usually starts with text fields. They tend to be the most intuitive and simple. Referring to a text field looks like this:

ctx.currentItem.[internalName] like “ctx.CurrentItem.Title”

Pretty straightforward. Other fields take a little bit more poking around to figure out the correct syntax. Person fields, like a few other field types, allow for one or more values to be stored – meaning the data will be stored in an array. Because of the array, overriding Person fields looks something like this:

The name:
ctx.CurrentItem.[internalName][0].title

The email address:
ctx.CurrentItem.[internalName][0].email

For some reason, the complete list of properties that are available for my ‘Created By’ field (internal name ‘Author’ – using Name with Presence) and ‘Modified By’ field (internal name ‘Editor’) are: email, id, picture, sip, and title.

However, when I have a Person field that I manually add to the list the properties I get are: department, email, id, jobTitle, picture, sip, title. When a People field allows multiple values it also has a ‘value’ property.

I’m not sure why you get the extra properties (department,  jobTitle, and value)  in addition to the original fields. The manually added field also has the picture property populated by the data from the user profile while the Created By and Modified By fields do not. More to dig into at another time.

If the Person column does contain more than one item, you can check ctx.CurrentItem.[internalName].length and then iterate through the array for all the names, email addresses, etc.

Definitely more nitty gritty details on how these fields work. But this should get you started for now.