Can a Custom Field Type reference other Fields?

Question

One of the common issues we have with SharePoint is that we want to display a whole lot of information about a user in a list, for example Job Title, Phone Number or Manager. We want to have this information in a read-only field of the list, so that it actually renders out in the Excel or RSS Views.

So I just wonder if I could create a custom field type that essentially reads information from the Created By/Author field of a List item and that doesn't show up on the New/Edit forms, but that essentially behaves as a normal field everywhere else.

Could I override the Value/FieldValueAsXxx Methods and get a "Context.ListItem" like access to the SPListItem?

Answer 1

Couldn't you just create a field that retrieves the SPUser from the created by field, then show properties from that user in the field (as text). Mark the field as readonly in the field definition CAML and the user will only see the field and not be able to edit it.

Answer 2

In 2010 you can override SPField.GetFieldValueAs* (Text or HTML dependant on the parent type), and in 2007 and 2010 you can set SPField.RelatedField, which allows you to use the following in the RenderPattern CAML:

<Column UseRelatedField="TRUE"/>

More information here.

However, neither method allows you to display the value in the datasheet view, since this looks directly at the stored value (which will be empty). There are also many pitfalls along the way using either method (for example, the CAML method breaks when there's a multi-lookup on the view), and custom field types in general are frustrating to the point of breaching human rights.

Coding a custom field type is like being a fly stuck inside, baffled by the windows (bzzzt donk donk donk bzzzt); there are strange undocumented barriers barring your every turn, but you have no idea why or what they are.

For such a straightforward requirement I'd recommend a workflow that sets a boring normal column to the value of the source column (if different) on edit; effective making it read-only.

Answer 3

You could just add a lookup field to the list that would pull in the additional user data as secondary fields. You could also specify that those additional fields should be present only in the Display template and not in Edit or New.

Alternatively you could create a Custom Field Type definition with accompanying controls and rendering templates in order to define just how you want your data displayed in each of the three different modes (i.e. Display, New and Edit) when the field is included in an SPList.