Tag Archive for SharePoint

BlumShapiro Live Tiles with Count

BlumShapiro is excited to announce that our technology consulting team has created a new app that will help SharePoint users extend the functionality of Live Tiles / Promoted Links. The free app “Live Tiles with Count” allows you to create multi-colored live tiles with the option to add item counts. Instead of your live tile just pointing out the link to open issues, you can also have it show how many open issues are assigned to the logged in user!

Read the rest of this post to see all the features, some screenshots and some sample CAML queries.

Description

Live tiles are a great way to give users quick links to content contained within a site. Live Tiles with Count allows you to get an actual count of items within a specific list on your site. The item count can even be filtered based on a CAML query.

This app allows users to easily create, and personalize live tiles.

BlumShapiro Live Tiles with Count features:

  • Standard live tiles hover functionality
  • Easily create live tiles and add to a SharePoint site
  • Choose different colors for each tile
  • 19 built in background images or upload and use your own
  • Add counts of lists on current site
  • Filter list count by CAML query

Screenshots

 

 

CAML Query Examples

Assigned To field is the current user or group the current user is in.

<View><Query><Where>

<Or>

<Membership Type=’CurrentUserGroups’>

<FieldRef Name=’AssignedTo’/>

</Membership>

<Eq>

<FieldRef Name=’AssignedTo’></FieldRef>

<Value Type=’Integer’>

<UserID/>

</Value>

</Eq>

</Or>

</Where>

</Query>

</View>

 

All items where the ID is greater than or equal to 1

<View><Query><Where>

<Geq><FieldRef Name=’ID’/><Value Type=’Number’>1</Value></Geq>

</Where>

</Query>

</View>

 

 

BlumShapiro Live Tiles with Count

 

Description

Live tiles are a great way to give users quick links to content contained within a site. Live Tiles with Count allows you to get an actual count of items within a specific list on your site. The item count can even be filtered based on a CAML query.

This app allows users to easily create, and personalize live tiles.

BlumShapiro Live Tiles with Count features:

  • Standard live tiles hover functionality
  • Easily create live tiles and add to a SharePoint site
  • Choose different colors for each tile
  • 19 built in background images or upload and use your own
  • Add counts of lists on current site
  • Filter list count by CAML query

 

Screenshots

 

 

CAML Query Examples

Assigned To field is the current user or group the current user is in.

<View>

<Query>

<Where>

<Or>

<Membership Type=’CurrentUserGroups’>

<FieldRef Name=’AssignedTo’/>

</Membership>

<Eq>

<FieldRef Name=’AssignedTo’></FieldRef>

<Value Type=’Integer’>

<UserID/>

</Value>

</Eq>

</Or>

</Where>

</Query>

</View>

 

All items where the ID is greater than or equal to 1

<View>

<Query>

<Where>

<Geq><FieldRef Name=’ID’/><Value Type=’Number’>1</Value></Geq>

</Where>

</Query>

</View>

 

 

Customize Related Items field in SharePoint 2013

Related Items

SharePoint 2013 introduced a new field to the Tasks’ list called “Related Items”. This field allows you to link other SharePoint items and/or documents to a specific task. The association occurs by using a wizard to look up and relate items anywhere within SharePoint.

Figure 1: Related Items Wizard


Figure 2: Related Items field with one relation

It’s a welcome change from prior versions, where one solution might have been to create a lookup into another list or library. A solution like that was not only restrictive (to just one library), but also not restrictive enough (all items in that list). So if the item you were trying to reference was located in a very large list, trying to find that item or document becomes a hassle since you only have the title to search upon. The Related Items wizard allows you to search using the different views, filter on columns, and even add new items!

Figure 3: Lookup field

I will say that lookups do have their place, and they are very handy with their cascading/restrictive delete functionality. Related Items which are deleted, will automatically be removed as a reference.

Customizing Related Items

As SharePoint fields go, the “Related Items” field is quite shy. By default, it’s located in the “_Hidden” group, which means when creating a new column on any list, it will not appear.

Note: You have to change its group in order to use it in other lists.


Figure 4: Related Items site column

Not only that, it only shows up on the “View Properties” page, and not even on the “Edit Properties”, which makes it such an under-utilized field. One that could be overlooked entirely!

And when viewing it on the list view page, it doesn’t even want to reveal what its holding! Two related items? Which two?

Figure 5: Out of the box view of Related Items

Note: its actually stored as json: [{ItemId:'[ID]’,WebId:'[GUID]’,ListId:'[GUID]’}]

 

Customize Related Items

Now, let’s try to get “Related Items” to come out of its shell a little bit, and show what those related items are. In order to do this, you will need to override its view display, which SharePoint easily lets you do.

For this example, I’ve modified the sp.ui.relateditems.js file to do our bidding which is to list the related items, like on the edit form, removing the “Add Related Item” and “Remove” links.

To use my example, you will need to upload the sp.ui.relateditems.custom.js file into your site collection. Copy the URL. And then paste it in the “JS Link” box on the list view page.


Figure 6: List View webpart properties

Note: I uploaded mine into the Master Page gallery as a “Design File” for simplicity sake. And used the JS Link value of
~sitecollection/_catalogs/masterpage/sp.ui.relateditems.custom.js

Now, instead of the “2 related items” text, we get the actual items and what they show! No more guessing what the related items are, because they now render (asynchronously).


Figure 7: Related Items custom template

This is just the starting point. You can easily override it even more, starting with having the Related Items field appear on the edit form.

 

sp.ui.relateditems.custom.js

Download

Refining Unstructured Search Results in SharePoint 2013

SharePoint search is awesome. It gives you the ability to search content inside of SharePoint, as well as outside of it. Plus, it gives you the ability to search for other employees in your organization. And quite easily!

Though, what it also gives you is a window into your organization’s disorganization. How many times have you taken a look into Active Directory only to find that users have job titles like “Mgr”, “Manager”, “Senior Manager”, etc.? One person’s naming convention is rarely ever exactly like someone else’s.

Now what happens if users actually want to refine these results. Say they want to pull back a list of all managers. They’d need to create a query similar to this:

Not very intuitive, is it?

Another option is to go back to your IT department and ask them to standardize this naming convention. Which wouldn’t be that difficult of a task for them, except they are already over worked and don’t really have time for another non-mission critical task.

So what does that leave? How about trying out a custom entity extractor? What is that you say? A custom entity extractor is a keyword mapping for a managed property, allowing you to customize the search refiner. In laymen’s terms, it’s a way for us to map our unstructured data (Mgr, Manager, Senior Manager) into a single term (Manager). Which allows you to add it as a search refiner so you can easily filter on just the “Managers”.

Our Example

For our tutorial, I’m going to use baseball as an example. Our people search returns the following players.

Each player has a unique job title, “Designated Hitter”, “Right Field”, and “Second Base”. We want to search for these players by “Infield” or “Outfield”. This would be akin to having “Mgr” / “Manager” / “Senior Manager” as job titles and wanting to filter by just “Manager” or “Partner”.

Create the Custom Extraction Dictionary

First we need to create our Custom Extraction Dictionary. This a comma separated (CSV) file which will define our mappings. I’m going to name this PositionsDictionary.csv and have all the infield positions map to “Infield” and all the outfield positions map to “Outfield”.

 

Import the Dictionary

Next we will need import the dictionary into our search application. Here is where we need to decided what type of extract it is. Should “First Base” match exactly to our values in AD, or should it just match part of it, and is it case sensitive? You can view the different types over on TechNet. For this example we will be using the Word Extraction type which is case-insensitive and matches the full word exactly. Run the following PowerShell cmdlet as an administrator on your SharePoint box:

$searchApp = Get-SPEnterpriseSearchServiceApplication
Import-SPEnterpriseSearchCustomExtractionDictionary -SearchApplication $searchApp
-FileName \\UNC-PATH\PositionsDictionary.csv
-DictionaryName Microsoft.UserDictionaries.EntityExtraction.Custom.Word.1

 

The FileName argument needs to be a UNC path. The DictionaryName argument needs to be exactly whats defined on TechNet (if you follow the link above). And if done correctly you will see a “Dictionary imported successfully”.

 

Map the Property

We now have to link our dictionary / mappings to the Job Title managed property. To do this, head over to the Search Service Application in Central Administration. Click on “Search Schema” link in the left navigation, which is found under “Queries and Results”, and search for the managed property “JobTitle”, and click on it to edit it. Then scroll down to the “Custom Entity Extraction” section.

This is where we need to link our managed property to the dictionary. Since we used the first Word Extraction dictionary, we need to check it off. If you used a different one, you will need to choose that one instead. Click “Ok”, and run a full crawl.

Add the refiner

Since we cannot change the default People Search page, I’ve created an exact replica of the People Search page in my Search Center, and changed the “People” link to that new page. The only difference, is that in my refinement webpart, I used “WordCustomRefiner1” instead of “JobTitle”, which I also gave it Display Name of “Job Title” just like the actual JobTitle managed property.

Click “Ok” and Save / Check In / Publish the People Search page.

 

Results

Now to test it out. If we do our search again, you can see that we just have two different job titles, “Infield” and “Outfield”. Which we can refine our results based on that.

And just like that, we’ve managed to filter our employees exactly as we desired without updating Active Directory or bothering IT.