SharePoint – List of ….


 

Querystring parameters you should not use in your pages

ContentTypeId
Type
Mode
View
ID
VersionNo
FeatureId
ListTemplate
List
RootFolder

For a complete list visit – http://blogs.technet.com/b/stefan_gossner/archive/2009/01/30/querystring-parameters-you-should-not-use-in-your-sharepoint-application.aspx

Tokens that can be used with Custom Actions

{ItemId} Returns the ID (int) of the selected List Item
{ItemUrl} Returns URL of the selected List Item
{ListId} Returns the ID (GUID) of the list associated with the Custom Action
{SiteUrl} Returns the URL of the site from where the custom action was invoked
{RecurrenceId} Returns the ID (int) of an instance of a recurrent item. For more info

Custom Action IDs

http://johnholliday.net/resources/customactions.html

Feature IDs

http://blogs.msdn.com/b/mcsnoiwb/archive/2010/01/07/features-and-their-guid-s-in-sp2010.aspx

List Template IDs

http://mosshowto.blogspot.in/2009/04/sharepoint-list-template-ids.html

Site Template IDs

http://jimecox.wordpress.com/2011/07/24/site-templates-id-in-sharepoint-2010/

Ribbon Locations

http://msdn.microsoft.com/en-us/library/ee537543.aspx

Advertisements

Restricting Search Results to contain only List Items / Documents


A very common request that comes up every now and then is to omit views, sites, lists/libraries etc. from Search results and only show list items/documents.

For example, in my test environment, if I search for a term “SharePoint“, I get 23 search results. Some of the items in the search results are site names or view names as shown below –

While not questioning the value or validity of these items in the search results, sometimes it may be necessary to make sure only documents or list items are included. So if I re-submit my search for SharePoint, but this time by suffixing a property called isDocument, I get only 14 items returned in the results. All those 14 items are documents. I have a list item in the Task and Announcements list which contains the word SharePoint in its Title, but those have been omitted as well.

If I alter my query to include a property called contentclass having a value starting with STS_ListItem, I get back 16 items. Two additional list items (one from the Announcements and the other from the Tasks list) are now present in the search results.

So achieving this was pretty simple, but how do you know what properties to include in your search and what values to assign to them. This is where you need to inspect the raw xml returned by the Query Service. The raw xml gives us a wealth of information related to the search results. From the XML I can see a list of managed properties returned and this is how I can take advantage of them to limit the information returned from search.

In case you are interested in knowing how to get search results information in raw xml format, refer to my blog post – Viewing Search Results in raw XML Format.

If you are not comfortable telling your end-users to always include a property in their search queries, you could add the property name:value as an additional query term.

  1. To accomplish this, edit the Search Box webpart.
  2. Under the Query Text Box section, specify the property name:value in the Additional query terms property. Uncheck the Append Additional terms to the query checkbox to hide this additional query term from the end-user by not having it echoed in the Search Box when the page is refreshed.

  1. Save and Close the page. Now when I search for SharePoint, even without specifying any other search limiter, only documents matching the search term are displayed in the results.

     

Viewing Search Results in raw XML Format


When you use the FAST Search for SharePoint 2010 or the Enterprise Search Service in SharePoint, the default way in which search results are rendered is thru the Core Results Webpart. This webpart gets an XML document as input from the Search Service and uses an XSLT style sheet to customize their appearance before displaying them. A lot of requirements related to changing the way in which search results are rendered, can be accomplished by modifying the default XSLT used by the web part.

For example, in my test environment I have the same image uploaded in a Picture Library as well as a Document Library. When I search for a term which causes both of these images to be returned in the search results, you will notice that the item returned from the Picture Library is displayed using a Thumbnail, whereas the item returned from the Document Library is rendered differently.

To explore why these two items are rendered differently in the search results, we can edit the properties of the Search Core Results Web Part and inspect the XSLT.

Under the Core Results category in the Editor Pane, expand the Display Properties section and click on XSL Editor. You will need to clear the Use Location Visualization checkbox.

The XSLT is almost 720 lines long and it would be better to use some XML Editor to understand it. Somewhere in the XSLT is a condition which checks if the current item is coming from a Picture Library and if there is a thumbnail present. If yes, then it proceeds to render the thumbnail or a generic image.

Not only is this XSLT useful for altering the way in which search results are rendered, it is also useful for debugging and understanding better how search results are actually returned.

For debugging purposes, it is better to view the raw XML returned by the Query Service. So typically in my development environment, I always recommend developers to look at the raw XML returned for accomplishing a variety of tasks related to Search.

  1. Assuming you have a site created using the Enterprise Search Center or FAST Search Center template, go to the search center site and create a new publishing page.

  1. Give XML Results as the Title and XMLResults.aspx as the URL Name. Select Search Results as the Page Layout. Click Create.

  1. Save and Close the newly created page.
  2. Edit the default.aspx page in the Search Center. Click Add New Tab.

  1. Specify Tab Name as XML and XMLResults.aspx (or whatever page you created in the previous steps) as the Page. Click Save.
  2. Click on the newly created XML tab.

 

  1. You should be redirected to the XMLResults.aspx page. Edit this page and repeat the previous step to add the same XML Tab on this page as well.
  2. To ensure that when we type a search query in the XML tab, the search results are displayed in the XML tab and not in the All Sites tab, edit the Search Webpart.

  1. Expand the Miscellaneous category and type XMLResults.aspx in the Target Search results page URL textbox. Click OK.

  1. While the page is still in Edit mode, edit the properties of the Search Core Results web part as well.

  1. Expand Display Properties and click on XSL Editor. You may need to disable the Use Location Visualization checkbox to be able to click on the XSL Editor Button.
    Delete the original XSLT and replace it with the following and then click OK.

<?xml version=”1.0″ encoding=”UTF-8″?>

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”&gt;

<xsl:output method=”xml” version=”1.0″ encoding=”UTF-8″ indent=”yes”/>

<xsl:template match=”/”>

<xmp><xsl:copy-of select=”*”/></xmp>

</xsl:template>

</xsl:stylesheet>

 

  1. Save and Close the page.
  2. Type a search query in the Search box of the XML Tab. This time you should see search results in their raw XML format.

Showing Workflow History along with a Document Set ListItem


Problem Statement : Show the workflow history associated with a particular Document Set ListItem on the Document Set’s welcome page.

Solution :

  1. First and foremost, you will need to make the workflow history list viewable in the browser. An easy way to do this is via SharePoint Designer. Navigate to the list via the All Files option and modify its properties.

  1. Clear the Hide From Browser checkbox.

2. Go to the list which contains your document sets and open any one of them. This will take you to the Welcome page of the document set.

3. Edit the page and Insert the Workflow History List webpart wherever you want on the page.

 

4. The Workflow History list contains a column called “Primary Item ID” which contains the item id of the list item the record is for. We need to filter the items displayed in this webpart for the list item that is currently displayed on the Welcome Page.

5. The Item ID colum is not available anywhere on the Welcome Page, but it is available in the query string of the page. We can extract the value from the URL using the QueryString Filter WebPart.

  1. Add a Query String (URL) Filter webpart to the page.

 

6. Edit the webpart’s properties and specify ID as the value for the Query String Parameter name property.

 

7. Connect the Filter webpart to the Workflow History List Web Part. Use the Send Filter Values To option to establish the connection.

8. In the Configure Connection dialog box, make sure the Consumer Field Name is Primary Item ID and click Finish. (Note : You may need to enable popups in your browser to be able to see this dialog).

 

9. Save the page. You will notice that only workflow history information for the current item is displayed on the page.

%d bloggers like this: