SharePoint: List does not exist after adding Data Form Web Part to a page

Problem:

After checking in your Page Layout containing a Data Form Web Part and changing the page layout of the publishing page you get error:

List does not exist.
The page you selected contains a list that does not exist.  It may have been deleted by another user.

Specifically, your DFWP uses SharePoint List located on another site.

Solution:

SharePoint Designer has been helping you during the checkin process and has added two attributes to the Data Form Web Part: ListId and ListName. Remove those and you're good to go.

<WebPartPages:DataFormWebPart runat="server" Description=""  Title="Contacts" ... ListId="SOMEGUID" ListName="{SOMEGUID}" ...>

THIS MIGHT NOT BE RELEVANT: It may have also added duplicate ParameterBinding with correct list GUID, but incorrect Name. Should be "ListID". <ParameterBinding Name="ListId" Location="None" DefaultValue="SOMEGUID"/>

Note You need to keep removing those every now and then as they keep reappearing.

SharePoint: Filter Data Form Web Part using Metadata value of current Publishing Page

Challenge:

On a Welcome Page of a Publishing Site I had few Managed Metadata fields. I was to implement a functionality that would fetch items from a list located on another site and filter the items using value of a metadata field of the current Welcome Page.

The idea is brilliant: there is a customer site, and there is a common list of contacts. Due to requirements, one common contacts list was preferred, so I decided to map contacts to customers by adding Metadata to contact AND to the same Metadata customer Welcome Page.

Solution:

As you cannot reference page field values in DFWP like it is done with CQWP, you must use Control parameter in Location attribute inside your ParameterBinding node (thank you Tomas Breen).

<ParameterBinding Name="Customer" Location="Control(CustomerName,ItemFieldValue)" DefaultValue=""/>

Customer above is the name of the parameter you will use in XSL. CustomerName is the ID of the Control on the Page Layout that contains the value you want to use as a filter. ItemFieldValue is the magic word I had to look for way too long.

Then, in the xsl:stylesheet of your DFWP, you will have

<xsl:param name="Customer" />

and finally you will do the filtering like this

<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[@Customer= substring-before($Customer, '|')]"/>

Note that @Customer is the value of the Customer metadata field of one of the list items we're about to display. $Customer is the xsl:param that contains the value from the Customer metadata field of the current Welcome Page. Substring is done because Welcome Page metadata value comes in the form CompanyX|GUID.

Not yet working? No, because what is still missing is the actual CustomerName control that will contain the Customer value of the current Welcome Page. In my case I used TaxonomyFieldControl and added the ID attribute. You could also use SharePointWebControls:FieldValue, or SharePointWebControls:ListItemProperty, but TaxonomyFieldControl allows editing of the value when in Edit mode and I needed that.

<Taxonomy:TaxonomyFieldControl FieldName="becb57f8-ac0e-45b1-a0b4-e5fa71c0d7fa" ID="CustomerName" runat="server"></Taxonomy:TaxonomyFieldControl>

Note that you will not be able to preview the functionality in SPD. You will have to browse to the page to see your beautiful markup magic.

SharePoint 2010: The data source control failed to execute the insert command.

Problem:

When modifying a Form of a list with SharePoint Designer 2010, at some point you might get error:

Error while executing web part: System.ArgumentException: Value does not fall within the expected range

The data source control failed to execute the insert command.

This may only occur with a specific type of List Form (New, Edit,Display).

Solution:

While there can be many causes for this generic error message, in my case the first parameter or ddwrt:DataBind function inside the SharePoint:FormFields element was 'i' and I was working with an Edit Form. Changing it to 'u' as it was with every other FormField fixed the issue.

<SharePoint:FormField runat="server" id="ff1{$Pos}" ControlMode="Edit" FieldName="Esittaja" __designer:bind="{ddwrt:DataBind('u',concat('ff1',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Esittaja')}" />

Explanation:

DataBind operation type parameters (the first parameter) are listed below:

'i' stands for INSERT,
'u' stands for UPDATE,
'd' stands for DELETE.

More about ddwrt:DataBind syntax can be found from Bryan's article.

Office 365 domain verification with Joker.com

CHALLENGE:

I'm using joker.com domain registrar and Office 365 needed to verify that I'm the owner of the domain. This is done by either adding TXT or MX record to the DNS records at joker.com (domain registrar).

TXT is the preferred method in order to minimize risks of causing issues in mail delivery if one manages to type in incorrect values for the MX record (in Finnish: ryssiä).

THOUGHTS:

In my (test) scenario I wanted to register intra.jussipalo.com.

Office 365 instructs the following:

In the TXT box for the domain, type the following: @

In the Fully qualified domain name (FQDN) or Points to box, type the following: MS=ms12312312

Where it asks for TTL information, type the following: 1 Hour

Now, in Joker.com, I only have the fields Host and Description:

Host field didn't accept @.

SOLUTION:

In Host field, type in the third level portion of the domain name, in my case intra. In Description, type in the MS=ms12312312.

Save and accept the changes and wait for some time (for me it took maybe 1-2 hours) and you can successfully verify the domain in O365 admin console.

SharePoint Online: You can use your custom domain name, but...

Keep the following things in mind:

1. You cannot use custom domain name in your private (=HTTPS) SharePoint Online sites.
2. What you will can use for your private site depends...you can only hope that https://yourcompanyname.sharepoint.com is available, otherwise you will end up with https://notquitemycompanynamebutthiswillhavetodo.sharepoint.com
3. intra.yourdomain.com CNAME notquitemycompanynamebutthiswillhavetodo.sharepoint.com won't help you either, because you cannot modify AAM settings of your SharePoint Online sites.

What you can do to ease end user's life of they wish to use their custom domain name is to

1. Create public SharePoint Online site with the custom domain name and redirect users to actual private site
   PROs: You can do it with SharePoint Online's Redirect page layout
   CONs: You will use up your one and only public SharePoint Online site slot
2. If you have any other servers with web sites you can host intra.yourdomain.com web site there and have a simple HTTP redirect from that web site to yourcompanyname.sharepoint.com
   PROs: You won't use up public web site slot in SharePoint Online
   CONs: You will need to have web server somewhere where you can implement the HTTP redirection.

SharePoint: How to clear Metadata and People Editor fields using jQuery

Challenge:

NewForm and EditForm of a custom SharePoint list contain Managed Metadata field and People Editor fields. I need to be able to clear the field values dynamically based on what selections the user makes when filling the form.

Just hiding the fields is not good as I don't want to include an additional column only for storing the value of the radiobutton selection.

Solution:

This is possible by using few Javascript tricks, and as I'm most familiar with jQuery I decided to use it to accomplish the goal. There are few hidden fields you need to modify in addition to the visible elements.

First you need to surround the fields with DIV's so that it is easier to reference the correct elements.

<asp:RadioButton runat="server" id="presenterSisainen" Text="Sisäinen" GroupName="presenter" />
<div id="presenterUserDiv" style="display:none;">
<SharePoint:FormField ... />
<SharePoint:FieldDescription ... />
</div>
<asp:RadioButton runat="server" id="presenterAsiakas" Text="Asiakas" GroupName="presenter" />
<div id="presenterMetadataDiv" style="display:none;">
<SharePoint:FormField ... />
<SharePoint:FieldDescription ... />
</div>

To clear Metadata field, do this:

jQuery("#presenterMetadataDiv > span > span > input[type='hidden']").val("");
jQuery("div[title='DISPLAYNAMEOFMETADATAFIELD'] > div > span[class$='valid-text']").replaceWith("&#8203;");
jQuery("#presenterMetadataDiv > span span.ms-formvalidation[role='alert']").html("");
jQuery("#presenterMetadataDiv > span > br").remove();

Note: 'DISPLAYNAMEOFMETADATAFIELD' needs to be the display name of the metadata field in question. It can contain spaces, etc. If it contains special characters such as umlauts, remember to save your .js file using UTF-8.

To clear People Editor field, do this:

j("#presenterUserDiv input[id$='HiddenUserFieldValue']").val("");
j("#presenterUserDiv span[id$='UserField']").attr("editoroldvalue", "");
j("#presenterUserDiv input[id$='UserField_hiddenSpanData']").val("");
j("#presenterUserDiv div[name='upLevelDiv']").html("");
j("#presenterUserDiv span[id$='UserField_errorLabel']").html("");

Note: You can use different jQuery selectors to achieve the same result, so above is not the only truth.

SharePoint: Some files not visible after migrating Content DB between Classic/Claims enabled Web Applications

Problem:

After migrating a SharePoint 2010 Content DB to a freshly installed environment my style sheet located in /Style Library suddenly disappeared.

Well, without really thinking it through I created new .css file and renamed it to what it was and should be. I got error saying such file already exists. Say what?

Reason:

What I didn't immediately remember was that when Content DB backup was taken, it was from a Web Application that was using Classic Mode Authentication.

The new environment instead is using Claims Based Authentication. So, what was going on was that my current user account didn't see the style sheet because the file was checked out to classic-based-me instead of claims-based-me at the time when backup was taken.

In addition that file had never been checked in by classic-based-me so there was no way I could see it when logged in with claims-based-me (from SharePoint permissions perspective they are two different user identities).

Solution:

1. Navigate to the list in question and go to settings of that list.
2. On List Information screen you see "Manage files which have no checked in version"
   
   
3. Select the file(s) you need to gain access to and select Take Ownership of Selection
4. 
   
5. BOOM! You have regained access to the file(s)!