How to create a lookup column that targets a Doc Lib and uses the 'Name' of the document? - sharepoint

How do you create a lookup column to a Document Library that uses the 'Name' of the document as the lookup value?
I found a blog post that recommends adding another custom field like "FileName" and then using a item reciever to populate the custom field with the value from the Name field but that seems cheesy.
Link to the blog in case people are interested:
http://blogs.msdn.com/pranab/archive/2008/01/08/sharepoint-2007-moss-wss-issue-with-lookup-column-to-doc-lib-name-field.aspx
I've got a bunch of custom document content types that I dont want to clutter with a work around that should really work anyway.

I created a one step workflow to set the title from the name, fired on modify and created. Seems to work and took seconds to create.

One way you can do this (although not the easiest way) is by creating a custom field type that extends the SPFieldLookup class. SharePoint's field editor for Lookup fields purposefully hides any columns types that aren't supported by Lookup fields, but you can create a field editor for your custom field type that shows them.
However, I have created a Lookup column that points to a Name column in a Document Library before, and it probably doesn't work like you'd expect. While the value stored in the lookup column is valid, it doesn't show up right in List view or on the View Properties form.
The solution you posted may actually be the best way to handle this. Lookup fields require some kludges if you want to handle more complex scenarios, but that's because they're not meant to provide the same functionality as a foreign key relationship in a database.

Coding in any form always scares me. So Here's what I did: I simply renamed the Stupid "Title" Field to something else, say "Keywords", since you cant do anything with that field: cant even make it mandatory.
Then I created another Single line field called "Title" and used this field for the Lookups

Well there is a simple solution to that and in might work in some case.
In the nutshell if you make the Title field Mandatory, this will force the user to enter a title. In that manner we can use title field as a lookup field.
Now How to do that?
One you are done create a document library go to the library setting. Select Advance Setting and Select Yes for the option "Allow management of content types?".
Then go back to the Library setting and Under content types select the "Document" Content type. THen Select Title Column and then Select "Required (Must contain information)" and say OK.
Now try uploading a document to this document library. You will see Title field in the form.
Hope this helps
Cheers
Vaqar

You have to add the field as XML with the ShowField as 'FileLeafRef'
var XmlFieldDefinition = "<Field DisplayName='myLookupColumn' Type='LookupMulti' StaticName='myLookupColumn' Name='myLookupColumn' Required='FALSE' List='THE LOOKUP ID HERE' WebId='THE WEB ID HERE' UnlimitedLengthInDocumentLibrary='TRUE' Mult='TRUE' Sortable='FALSE' ShowField='FileLeafRef' />"
Field fld = fieldCollection.AddFieldAsXml(XmlFieldDefinition, true, AddFieldOptions.DefaultValue);
ClientContext.Load(fld);
ClientContext.ExecuteQuery();

Related

Formula referencing parent doc works in computed field, not as default value

Following on from this question: Referencing parent field on document creation I'm using the formula for the default value for a name field.
IfError(#IfError(#GetDocField($ref;"ProductFamilyManager");
#GetDocField(ParentUNID;"ProductFamilyManager"));
"")
This works when it's a computed field, but not when i change it to be editable with a default value formula.
Any ideas how I can get the field populating with the default value?
The best way of doing this is to use #InheritedDocumentUniqueId. You need to enable inheritance to make that function available, but you don't actually have to inherit any of the parent values.
You should definitely not have to be using two different techniques and #IfError to get this done. And btw: did you know that #IfError is obsolete as of Domino 7?
It may not be supported but just to be sure, has the parent doc been saved before you create the response doc?
Assuming that's not the problem, the alternative is to use the "inherit field values from parent doc " option, which will pass a value from the parent doc to the response doc on creation. I may have the wording wrong but the option is on the form properties dialog in Designer.

Sharepoint Extenal List and Custom Field Types

I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.

Sharepoint lookup field and WebId="

I try to add lookup field in content type. Field has this definition:
<Field ID="{c80e8e3c-7124-4772-a39d-5b69f131d542}"
Name="Site"
Group="Tieto Intranet Columns"
Type="Lookup"
DisplayName="Site"
StaticName="Site"
List="Lists/FavoriteSites"
ShowField="Title"
PrependId="TRUE"
WebId="~sitecollection"
>
FavoriteSites list, which I want reference by this lookup field, exists on the site collection scope. Deployment goes fine, but when I create list based on content type with this lookup it looks like that lookup field is not connected to FavoriteSites list. I add some data into FavoriteSites and than I a try to add something into second list with lookup field on FavoriteSites. Unfortunately drop down select, which should show me data from FavoriteSites list is empty.
When I create new lookup column to FavoriteSites manually everything is OK.
Do anybody have some idea where can be problem in this lookup definition?
UPDATE:
As Rich recommended me, I set log level on Verbose a find this message:
The WebId=~sitecollection and List=Lists/FavoriteSites attributes specified for field {c80e8e3c-7124-4772-a39d-5b69f131d542} in feature {d86c7005-d31d-43ae-b86b-38f28b81072e} could not be found. Set List={39CEC23E-FB28-47B3-BC36-C21780AD1D94}.
I don't understand it because list FavoriteSites exists. FavoriteSites list and also second list with Site field are deployed by one feature on site collection scope.
I can't specify list in lookup by GUID because I don't know the guid in deployment time.
What that log message means is that Lists/FavoriteSites does not exist in either the site collection root site or the site where the feature is being activated (if the latter is a subsite).
If Lists/FavoriteSites is being created by a feature, then make sure that it is activated before your Fields feature. Put the ListInstance element right above your Field element if you have to. But the message is clear: the list does not exist at the time that your custom field is being provisioned to the site collection. And that is why it is not working.
To be clear, the list has to exist at the time that the feature is activated, not just when you create a list instance that will use that field.
P.S. I found this by checking the "documentation" for the Microsoft.SharePoint.SPFieldElement.PerformFixUpIfLookUpField method.
Try changing the list field to the ID of the list e.g. List="{4641f5f2-b358-4805-9d7d-e910d2243fb5}"
I would also recommend using SharePointManager to look at the Field definition of your manually created field and to easily find the blooming guids of lists etc.
I had the same problem. In the end my problem was that you can not declaratively reference a list that is in the rootweb. The ~sitecollection token in the WebId property is not working because it will write the Guid between braces, while SharePoint expects it without braces (explanation can be found on http://martensboarterstun.wordpress.com/2013/06/15/how-to-create-a-list-definition-with-a-lookup-field-declaratively/). I ended up placing the Rootweb ID in my list definition.

Why the OnWorkflowItemChanged is different between List and document library?

I am doing a workflow for a document library. I put a OnWorkflowItemChanged, and I want to get the value of the column which is changed. I use the workflowProperties.Item["name"] and use the afterProperties. But when I use the workflowProperties.Item["column name"], I still got the original value. When I use the afterProperties, it's NULL.
Then I make another workflow that is the same as above for a list. I can use the workflowProperties.Item["column name"] to get the new value in OnWorkflowItemChanged.
Has anyone come across this problem before? Can you give me some help?
The question seems to mix up Item with ExtendedProperties. As to why a difference is seen on a List/Document Lib, it might have something to do with versionining or perhaps the internal serialization is different. Anyway, some of my experience is outline below. I hope it may be of use:
Use the GUID (as a Guid object, not a string) to access the Before / After ExtendedProperties field. Using the Display Name in the ExtendedProperties will not work. The documentation on it is wrong. You can use SPList.Fields to go from Display Name to Column ID (Guid).
I bind all "Before" to MyWhatever_PreviousProperties and all "After" to MyWhatever_Properties, only accessing MyWhatever_[Previous]Properties after the appropriate event(s)).

Hiding a SharePoint Custom Field Type in Edit and Create mode

I am trying to create a Custom Field Type in SharePoint.
This control has it's value set based on another field in the same list.
Because of this requirement, this field should be displayed only in the Display Mode, and not in the Edit or Create mode.
How do I ensure this?
If I just code the ASCX control to not render a field, the field will show up like this in the Edit and Create mode.
alt text http://www.mannsoftware.com/blog/Lists/Photos/121308_0204_CrossSiteLo6.png
Generally you set the SPField.ReadOnlyField property to True to achieve the desired behaviour for any field. (Don't forget to SPField.Update accordingly!) There is an equivalent CAML attribute for list definitions, I believe.
That said, in your control class deriving from BaseFieldControl, you might just override the RenderFieldForInput() method and not call the base implementation to ensure nothing is rendered during Create or Edit. However, this would still render the field's table row in the form, which is probably not what you want. So to enforce the desired behaviour, use ReadOnlyField and override Update() in your SPField (not field control) class to always have it set to True.
It might be easier to just change this on a list-by-list basis by going to the Advanced section of the List Settings, setting Allow management of content types? to Yes, and then editing your content type to change the value of your field to 'hidden'.
Take a look at this blog post. I think it will give you some ideas. The concept uses different rendering templates based on the mode.
http://sharepoint.nailhead.net/2008/04/creating-rendering-template-that.html
Did you try and set the field as hidden?
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfield.hidden.aspx
Custom FORMS pages for new item and edit item (NewForm.aspx and EditForm.aspx) would be another way to achieve this.
Setting the ShowInEditForm and ShowInNewForm properties solved this for me.

Resources