FieldDescription

First of all I thought the SharePoint webcontrol ‘FieldDescription’ would show the description of the field. At MSDN the FieldDescription class was described as

‘Represents the description metadata of a field.’

Any context is missing here.
After looking around a little bit more some context was found at the description of the Render method:
This member overrides TemplateBasedControl.Render(HtmlTextWriter).
Ah, so this webcontrol is used in template based controls. In the SharePoint root folder some references to this control were found in DefaultTemplates.ascx and SharePoint_Publishing_defaultformtemplates.ascx.
Stubborn as I am I just put this control on a page layout to check if anything will be rendered, but nothing was.

FieldProperty

The FieldProperty control

‘Represents a property of a field; that is, a column, on a list.’

This is what I’m actually looking for!
The control is very easy to use:

<SharePointWebControls:FieldProperty FieldName="Title" PropertyName="Required" runat="server" />

The FieldName is the static (internal) field name and the PropertyName can any of the properties of a field.
The FieldProperty control will return the values set in the UI or in XML, dependent on how the field is created.

In the picture below the results are shown of the property values of three columns:

• SingleLineOfTextField: single line of text field, created in xml, not required, created in a group, ShowInNewForm set to TRUE.
• UICreated: single line of text field, manually created directly at list level, required
• UICreatedSiteColumn: single line of text field, manually created in the site columns gallery and added to the list, required and stored in a group

The value of the ShowInNewForm attribute isn’t returned, so probably not all field elements can be used.

Summary

The FieldProperty control can be used to show values of field properties on a page, but not all. In the above example the ShowInNewForm isn’t exactly useful to show on a page, but ok.
Be aware of the value of the description property returned: this is the value on the list, not the site columns itself.

The value of the property ‘SearchEnsureSOD’ is null or undefined, not a Function object

by just clicking in the page…

Hmm, according to the name of the function it seemed it has something to do with search and after investigating the page it seemed there was a custom Coreresults webpart on the page when there was no searchbox on the same page…
To make sure this was it I added a searchbox to the masterpage and the javascript exception didn’t occur again.

No big deal, just checked the difference in script files loaded with the developer tools between the page where the error occurred and a page where the searchbox was present: search.js is missing.

After adding a reference to the search.js file in the masterpage another exception was thrown when the page loaded:

The value of the property ‘NotifyScriptLoadedAndExecuteWaitingJobs’ is null or undefined, not a Function object

Ok, this function is defined in init.js, which actually was loaded already…

Maybe init.js was loaded later than the function NotifyScriptLoadedAndExecuteWaitingJobs was called. Just to be sure a reference to init.js was added in the masterpage and the initial exception was thrown again:
The value of the property ‘SearchEnsureSOD’ is null or undefined, not a Function object

It seemed the function SearchEnsureSOD wasn’t loaded when the body (body element in masterpage) was loaded. By adding a function to the _spBodyOnLoadFunctionNames array, the onload eventhandler of the body will execute each function loaded in this array. So by adding the SearchEnsureSOD function to this array it will run when the onload event of the body fires.

To be very minimalistic and a lazy programmer I added an empty SearchEnsureSOD function to the _spBodyOnLoadFunctionNames array:

<script language="javascript" type="text/javascript">
function SearchEnsureSOD() {
}
_spBodyOnLoadFunctionNames.push('SearchEnsureSOD');
</script>

and the javascript error didn’t occur again.

So what about deleting the reference to search.js? That won’t work, because this is the statement the error occurs on:

$addHandler(window.document.documentElement, 'click', function(evt){SearchEnsureSOD();SearchNavigate(evt);});//]]>

and it uses the function SearchNavigate, which is actually defined in search.js

So the full code to add to the masterpage:

<SharePoint:ScriptLink name="init.js" runat="server"/>
<SharePoint:ScriptLink name="/_layouts/search.js" runat="server"/>
<script language="javascript" type="text/javascript">
function SearchEnsureSOD() {
}
_spBodyOnLoadFunctionNames.push('SearchEnsureSOD');
</script>

On a search result page the function is defined as:

function SearchEnsureSOD() {
   EnsureScript('search.js',typeof(GoSearch)); }
_spBodyOnLoadFunctionNames.push('SearchEnsureSOD');

Where GoSearch is present when the searchbox control is.

Summary

The Coreresults webpart is a great thing, but it apparently needs some work when there is no searchbox present at the page. In this post the solution is provided to make it all work.

The exception

Exception in SearchBoxEx::CreateChildControls:System.TypeInitializationException: The type initializer for 'Microsoft.SharePoint.Portal.WebControls.LocStringIdLookupTable' threw an exception. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
 at Microsoft.SharePoint.Portal.WebControls.LocStringIdLookupTable..cctor()

And the inner exception stack trace gave me more info:

at Microsoft.SharePoint.Portal.WebControls.StringResourceManager.ConvertLocStringIdToStringFast(LocStringId lsid)
 at Microsoft.SharePoint.Portal.WebControls.StringResourceManager.GetString(LocStringId lsid)
 at Microsoft.SharePoint.Portal.WebControls.SiteInfo.get_IsUICultureRTL()
 at Microsoft.SharePoint.Portal.WebControls.SearchBoxEx.CreateChildControls()

Investigation

So the exception occurred in the SearchBoxEx control, method CreateChildControls. Since this is a stack trace of standard SharePoint Server code I decompiled the standard SharePoint Server assemblies which I needed. This is necessary because this is no custom code belonging to an application we created. After analyzing the code it seems that when creating the SearchBoxEx control a context is created to build the control and its properties. During the creation of this context a SPSite and SPWeb are needed.
SharePoint is lacking to dispose these objects.
Another site is also using this SearchBoxEx control and no memory leaks have been reported here. The searchbox control used at this site is the same, but the context is different. The searchbox in this site uses its own SPWeb as context and this SPWeb object doesn’t need any disposal.

The SearchBoxEx control can be found at the top of the pages on the right hand side and in the Search center. The PeopleSearchBoxEx is a different control and doesn’t leak any memory.

How does the SearchBoxEx control get its context?

This is the code:

private SPWeb GetSpWeb()
{
  using (new SPMonitoredScope("SearchBoxEx.GetSpWeb"))
  {
    SPWeb personalWeb = null;
    if ((this.m_strCtxScopeFromGetOverride == SearchCommon.GetLocResourceString(LocStringId.SearchBox_ThisSite_Label)) && !string.IsNullOrEmpty(this.m_strSearchWithInUrlGetOverride))
    {
      if (this._PropertiesOverrideableBySite.EffectiveSearchResultPageUrl.EndsWith("/_layouts/OssSearchResults.aspx", StringComparison.OrdinalIgnoreCase))
      {
        personalWeb = SPContext.GetContext(HttpContext.Current).Web;
      }
      if (personalWeb == null)
      {
        SPSite site;
        try
        {
          site = new SPSite(this.m_strSearchWithInUrlGetOverride);
        }
        catch (FileNotFoundException exception)
        {
          site = null;
          ULS.SendTraceTag(0x66673974, ULSCat.msoulscat_SEARCH_Query, ULSTraceLevel.Medium, string.Concat((string[]) new string[] { "The SearchBox was passed an invalid site url in the query parameter: url={", this.m_strSearchWithInUrlGetOverride, "} Exception Detail: message={", exception.get_Message(), "} name={", exception.get_FileName(), "}" }));
        }
        if (site != null)
        {
          personalWeb = site.OpenWeb();
        }
      }
    }
    if (personalWeb == null)
    {
      if (this.Page is MySitePublicWebPartPage)
      {
        IPersonalPage page = this.Page as IPersonalPage;
        personalWeb = page.PersonalWeb;
      }
      if (personalWeb == null)
      {
        personalWeb = SPContext.GetContext(HttpContext.Current).Web;
      }
      if (personalWeb == null)
      {
        throw new ArgumentNullException("SPSite is null. No contextual scopes will be added");
      }
    }
    return personalWeb;
  }
}

The code explicitly checks if the result page ends with “/_layouts/OssSearchResults.aspx” to use the current context or to create an SPSite/SPWeb.

The personalWeb in the above code is returned by this method to the calling method but the SPSite site isn’t disposed!

This method returns the personalWeb to the calling method ‘HandleContextualScoping’. This SPWeb is used in the method, but not disposed!

Summary

Oeps.

Microsoft, would you be so kind to fix this?

An app for SharePoint has its own identity and is associated with a security principal, called an app principal. Like users and groups, an app principal has certain permissions and rights. The app principal has full control rights to the app web so it only needs to request permissions to SharePoint resources in the host web or other locations outside the app web.

Using Microsoft Napa Office 365 Developer Tools these permissions can be set in the properties of the app using some kind of slider.

After installing the app this is the result:

The user can select one list out of all available lists the user has access to.

A better approach would be to help the user pick a specific (kind of) list, not letting the user pick from all lists in the web. This can be accomplished by editing the AppManifest in Visual Studio through a nice looking designer:

At the Permission requests section the column Properties a BaseTemplateId can be filled in to filter the lists the user can choose from. The BaseTemplateId is the numerical equivalent of the list base template, for example 100 represents a generic list, 101 a document library.

In xml this looks like:

  <AppPermissionRequests>
    <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list" Right="Read" >
      <Property Name="BaseTemplateId" Value="101" />
    </AppPermissionRequest>
  </AppPermissionRequests>

This results in the following list:

It looks like multiple properties can be defined, and you can:

but an additional BaseTemplateId won’t recognized and the filter of list types isn’t amended to the property settings.

You aren’t able to add another List scoped permission request in the designer, other scoped items can be added, also once per AppManifest.

The xml can be amended with another List scoped permission request, but only the first one defined is active.

One gotcha: Once the app is installed and permissions link is selected there is no possibility to view the list its current permission setting. The first list in the dropdown is selected…

For example Trust library Site Assets:

Request permissions of the app:

And the first library is selected… hope Microsoft is going to fix this one…

Disclaimer: SharePoint 2013 is in preview at time of this writing, so things may change between now and release date.

From the Site Contents menu (or other places…) an app can be added.

The quick launch menu shows a couple of options:

• Your Apps
  • Apps you can add
• Manage Licenses
• Your Requests
• SharePoint Store

Default Apps You Can Add is selected, showing you.. the apps you can add! Be surprised. The default SharePoint lists and libraries are shown when you just started with this site collection.

Your Apps

Your Apps shows all your apps, including the ones already installed. When there is something ‘wrong’ with the app SharePoint will tell you so. Let’s take a look at the “Napa” app.

It shows You can’t add this app here. And Find out why. The last sentence is a link and redirects you to the app properties(‘About’ the app or the App Details) which tells you why you can’t add the app: Good news – you already have this on your site.

Another option could be some prerequisites are missing (specified by the developer of the app), which would be the content of the message shown.

Manage Licenses

This item shows a list of apps to manage licenses for. When selecting an app details will be shown about license management, such as the user who purchased the app, people with a license, options to recover or remove the license, view the item in the SharePoint Store (public marketplace) and the license managers.

Your Requests

Your Requests has no actual use, beside searching for an app, which is standard available in the Add an app page, when appropriate governance controls aren’t enabled.

With appropriate governance controls I mean settings for App Purchases and App Requests available in SharePoint Administration Center. But before anything can be done about these settings an app catalog site collection has to be created.

In SharePoint Administration Center go to apps and select App Catalog. Here apps can be made available to the organization and requests for apps can be managed.
App Catalog ‘prescreen’:

Properties for the App Catalog Site:

Once the site collection has been created the  App Catalog ‘prescreen’ is not shown again when selecting the link, but the App Catalog site collection created earlier will be shown.

At Configure Store Settings (SharePoint Administration Center; apps) the App Purchases and App Requests can be managed.

With the above settings users are able to get apps from the SharePoint Store. When they go to the Store and find an app of their choice they can Add it.

When App Purchases are disabled users can request the app:

And fill out a simple form about user licenses and a justification.

After this, Your Requests, lists the requested app in a pending state.

In the App Catalog site collection the list App Requests lists the app requested:

With the Status column the user can keep track of the request. Once approved, the app can be installed and can be added by the user. The new app appears in the Your Apps section.

SharePoint Store

The SharePoint Store link redirects you to the store where all kinds of apps are listed, where you can search for a particular app or browse by category,  install or request an app dependent of the setting previously explained.

Summary

In this post I tried to explain some items available at Add an app and how you can add or request an app based on governance settings available in SharePoint Administration Center.

Trevor Sullivan read my post and suggested in his comment to analyze the use of wildcards to export functions, variables or aliases using the manifest file.

After trying this I got enthusiastic about it, read further…

As well in the manifest file as with the use of Export-ModuleMember in the module wildcards can be used.

This can be (very) helpful when naming the function in the module according to a certain structure.
In C# accessibility levels are used to restrict or limit access to certain methods. There is no such thing in PowerShell, but this can be achieved by (not) exporting the functions from a module. In C# reserved accessibility levels as public and private are used. We can use this ‘technique’ in PowerShell by naming the functions in a module according to a standard: use for example -public or _public at the end of a functionname or variable in a module and use the same string literal as wildcard to export functions.

Practically this means defining Export-ModuleMember in the module like:
Export-ModuleMember -Function “*”
Export-ModuleMember -Variable “*”
Export-ModuleMember -Alias “*”
to export all functions, variables and aliases.
Then restrict the exported items in the module manifest like:
FunctionsToExport = ‘*-Public’
VariablesToExport = ‘*_Public’
AliasesToExport = ‘*-Public’

Module (psm1)

$msgText_Public = 'Hello world!'
$anotherVariable = 'more here'

function Say-HelloWorld() { Write-Host $msgText }
function Calc-Numbers-Public([int] $a,[int] $b) { $a + $b }
function I-Am-Public() { Write-Host "Public" }

Set-Alias Add Calc-Numbers
Set-Alias Hello-Public Say-HelloWorld

Export-ModuleMember -Function "*" #Say-HelloWorld, Calc-Numbers
Export-ModuleMember -Variable "*" #msgText, anotherVariable
Export-ModuleMember -Alias "*"  #Hello, Add

Manifest (psd1)

# Functions to export from this module
FunctionsToExport = '*-Public'

# Variables to export from this module
VariablesToExport = '*_Public'

# Aliases to export from this module
AliasesToExport = '*-Public'

And the result:

Summary

In my previous post I wrote in the summary:
‘The export keys in the manifest can be seen as an export override of the Export-ModuleMember used in a module… When trying to control the exports of variables and aliases it all comes clear: export them in the module at all times!’

After analyzing the wildcard options to export I still agree on the above statements, but I would like to nuance it a bit: export all items in the module and restrict the exported items in the module manifest by using wildcards in the module manifest and using a naming convention when defining functions, variables and aliases.

When approaching exporting the items from a module as described above you can not forget to export a function, variable or alias, you just have to follow this naming convention.

2. By using a module manifest and specifiy what resources need to be exported like:
@{
….
FunctionsToExport = ‘ VariablesToExport = ”
….
}

By seeing this I got a little confused on which method to use and why: Export-ModuleMember or the manifest way, so it was time to dig into this matter.
By creating a small module, a manifest and a script file the different options can be tested.

Module (psm1)

In the module three functions, two with an alias and two variables are defined and exported:

$msgText = 'Hello world!'
$anotherVariable = 'more here'

function Say-HelloWorld() { Write-Host $msgText }
function Calc-Numbers([int] $a,[int] $b) { $a + $b }
function I-Am-Private() { Write-Host "private" }

Set-Alias Add Calc-Numbers
Set-Alias Hello Say-HelloWorld

Export-ModuleMember -Function Say-HelloWorld, Calc-Numbers
Export-ModuleMember -Variable msgText, anotherVariable
Export-ModuleMember -Alias Hello, Add

Manifest (psd1)

The export variables of the manifest are (default) set to ‘*’:

# Functions to export from this module
FunctionsToExport = '*'

# Cmdlets to export from this module
CmdletsToExport = '*'

# Variables to export from this module
VariablesToExport = '*'

# Aliases to export from this module
AliasesToExport = '*'

Script (ps1)

The script file imports the module and displays information about the module. This is an excellent way to test what resources are exported:

Import-Module ExportFunctions -Force
Get-Module -Name ExportFunctions | fl

Tests

Running this script results in the following output:

As can be seen two functions, the aliases and variables are exported as defined in Export-ModuleMember in the module.

The Export-ModuleMembers lines are now removed to test the default settings in the manifest file (all ‘*’ for the export keys). Running the same script now results in:

All the functions are exported, but none of the alias or variables. At first sight this seems a bit strange, because the generated comment of the export keys of the manifest say ‘ to export from this module’. This seems only the case for the functions.

TechNet documentation for FunctionsToExport key:

Specifies the functions that the module exports (wildcard characters are permitted) to the caller’s session state. By default, all functions are exported. You can use this key to restrict the functions that are exported by the module…

And the TechNet documentation for VariableToExport key:

Specifies the variables that the module exports (wildcard characters are permitted) to the caller’s session state. By default, all variables are exported. You can use this key to restrict the variables that are exported by the module…

The statement don’t differ, but the behavior is.

The ‘*’ at the FunctionsToExport key means the restriction is:

If Export-ModuleMember -Function in the module is used, the functions listed there are exported:
In module:

Export-ModuleMember -Function Say-HelloWorld, Calc-Numbers

In manifest:

FunctionsToExport = '*'

Result:

If Export-ModuleMember -Function is NOT used in the module and in manifest ‘*’ is used all functions are exported:

The ‘*’ at the VariablesToExport key means: By default none of the variables are exported, unless variables are exported by the Export-ModuleMember in the module.

In module: No Export-ModuleMember -Variable
In manifest:

VariablesToExport = '*'

Result:

In module: No Export-ModuleMember -Variable
In manifest:

VariablesToExport = 'anotherVariable'

Result:

In module:

Export-ModuleMember -Variable msgText, anotherVariable

In manifest:

VariablesToExport = '*'

Result:

In module:

Export-ModuleMember -Variable msgText, anotherVariable

In manifest:

VariablesToExport = 'anotherVariable'

Result:

Summary

The export keys in the manifest can be seen as an export override of the Export-ModuleMember used in a module. When testing this behavior with functions alone it can be confusing – at least it confused me – which method to use – manifest export key or Export-ModuleMember – to restrict function exports. When trying to control the exports of variables and aliases it all comes clear: export them in the module at all times!

While another displays an actual value:
Actual term in a tree

or just a ‘parent’ term

Why?

When the fieldvalue is less than 19 characters the tooltip stays empty. Well empty.. it displays ‘Refine By:’. Every fieldvalue with more than 19 characters is displayed in the tooltip. A ‘parent’ term or a whole path.

How to solve?

This behavior can be solved by adjusting the xslt.

Original xslt:

<a href="{$SecureUrl}" title="{$RefineByHeading}: {$UrlTooltip}">
<xsl:value-of select="Value"/>
</a>

Adjusted xslt:

<xsl:variable name="UrlTooltipAdjusted">
 <xsl:call-template name="format-tooltip">
 <xsl:with-param name="tooltip" select="$UrlTooltip" />
 <xsl:with-param name="string" select="Value" />
 </xsl:call-template>
</xsl:variable>

<a href="{$SecureUrl}" title="{$RefineByHeading}: $UrlTooltipAdjusted}">
<xsl:value-of select="Value"/>
</a>

<xsl:template name="format-tooltip">
 <xsl:param name="tooltip" />
 <xsl:param name="string" />
 <xsl:choose>
 <xsl:when test="$tooltip != ''">
 <xsl:value-of select="$tooltip" />
 </xsl:when>
 <xsl:otherwise>
 <xsl:value-of select="$string" />
 </xsl:otherwise>
 </xsl:choose>
</xsl:template>

The ‘format-tooltip’ template checks if the tooltip is empty and replaces the tooltip value with the actual fieldvalue if so.
By doing this the tooltip will never be empty and will always show the value of the fieldvalue.

Summary

Besides the fieldvalues also the tooltip values suffer from a character limitation. The values of the refinement panel have a 19 character display limit, the tooltip doesn’t display the value when the fieldvalue is less than 19 characters.
This and the previous post solve these issues by making minor adjustments to the OOTB xslt.

Suppose a sitecolumn of a library is a managed metadata column bound to a global termset. The termset is the parent of a few terms and all of these terms have one or more children itself. A termtree.
The display format of the column is set to ‘Display the entire path to the term in the field’.

A few documents are uploaded to the library and the metadata column is set to one of the terms.
A full crawl is completed and the refinement panel shows the metadata refiner.
The refinement panel now looks like this:

As can be seen, not the whole fieldvalue is displayed. That’s weird. How do I know which one to use if not the whole value can be seen?
Maybe it’s a css issue or the left column of the screen isn’t wide enough? Starting up Firebug and checking out the value:

The whole value isn’t present as text to display in the panel! I was seriously surprised!
SharePoint returns only the first 19 characters and three dots…

But… hover over de terms and the whole path is displayed. But that’s not a satisfactory solution, the values have to be displayed properly!

Ok, I agree displaying the whole term tree path isn’t that useful in this case, but it’s needed somewhere else in the site, so the display format of the site column has to stay ‘Display the entire path to the term in the field’.
It would be great to have on option to show only the last term value despite the column display format. An excellent configuration place would be an extra attribute in the filter categories definition xml.

Displaying the last term value

The xslt of the refinementpanel can be adjusted to display the last term value now we know the tooltip does know the whole value.

Original xslt:

 <a href="{$SecureUrl}" title="{$RefineByHeading}: {$UrlTooltip}">
  <xsl:value-of select="Value"/>
 </a>

The new xslt looks a little bit different than that.
First the fieldvalue has to be analyzed if it contains ‘:’. The ‘:’ means the value is a child term and the whole tree path is displayed.
From the value which contains the whole tree path the last term is filtered by a recursive xslt template ´substring-after-last´.
Then a check has to be performed if the last term value contains the three dots. If it does, the last term value should be taken from the tooltip value, because the xslt Value doesn’t contain this value. Confusing, isn’t it?

<xsl:variable name="PartOfValue">
 <xsl:call-template name="substring-after-last">
  <xsl:with-param name="string" select="Value" />
  <xsl:with-param name="delimiter" select="':'" />
 </xsl:call-template>
</xsl:variable>

<xsl:variable name="PartOfTooltip">
 <xsl:call-template name="substring-after-last">
  <xsl:with-param name="string" select="$UrlTooltip" />
  <xsl:with-param name="delimiter" select="':'" />
 </xsl:call-template>
</xsl:variable>

<xsl:choose>
 <xsl:when test="($FilterCategoryType = 'Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator') and ($PartOfValue != '')">
  <xsl:if test="not(contains($PartOfValue, '…'))">
   <xsl:value-of select="$PartOfValue"/>
  </xsl:if>
  <xsl:if test="contains($PartOfValue, '…')">
   <xsl:value-of select="$PartOfTooltip"/>
  </xsl:if>
 </xsl:when>
 <xsl:otherwise>
  <xsl:value-of select="Value"/>
 </xsl:otherwise>
</xsl:choose>

If the fieldvalue contains less than 19 characters, no dots are displayed and the value can be used, but in that case the urltooltip is empty… To solve an empty tooltip, check out my next post.

After the xslt has been implemented the refinementpanel looks like the picture below

And the tooltip displays the whole term tree:

SharePoint returns only the first 19 characters, so what happens when a term itself exists of 19 or more characters?

On the one hand it’s great the 19 character limitation of displaying a whole termtree isn’t applied to this term, on the other hand, it doesn’t look very nice when the text continues outside the refinement panel.

Summary

The values of the refinement panel have a 19 character display limit. When displaying a whole termtree it’s likely this limitation will be exceeded. Just a few xslt adjustments are necessary to display the fieldvalues correct again.