The CodePlex Corner: Instant List Filter

The link to the Instant List Filter is https://instantlistfilter.codeplex.com/

This edition of the CodePlex Column delves into the SharePoint Instant List Filter, a project that’s both highly rated and has attracted a significant number of votes. It boasts an impressive 20k+ download count (at the time of writing). It was developed by Jaap Vossers and has previously attracted the attention of Marc Anderson and Alexander Bautz (both well-known JavaScript experts). As the product name suggests, the solution provides filter text boxes on a list/library to allow a “filter-as-you-type” functionality. It also needs JQuery to work successfully when it is deployed. Having being around since 2009, it would be fair to say that the list filter is one of the community products that has stood the test of time.

So, if it has been around for a while, the first question that may spring to mind is; what’s the point in taking a look at it now? The simple answer is the changing SharePoint landscape. As with a few other projects that have been discussed in the CodePlex Corner, the environment that the list filter was born into is very different to the one that we, as SharePoint professionals, have now. Some of the noticeable differences include more powerful versions of SharePoint, newer HTML / CSS standards for each one and of course, very different browser habits to contend with. It’s in this light that an in-depth look at the utility in context of its altered environment might be useful.

A good place to start is to look at how the list filter code responds to the various versions of SharePoint still in use today. Whilst investigating, the opportunity to test the code against the popular browsers of the day also presents itself. The timeline below looks at the release dates of all these products.

Building such a timeline provides two distinct advantages: –

  1. Identifiable points in time at which we can check browsing habits
  2. A linear route to allow us to see which browsers that SharePoint and the list filter would be expected to work with

Cross referencing the most recent three dates from the timeline above with the W3Schools Browser statistics provides the following insights into browser trends at the time of release for each product. The most noticeable thing is the huge increase in Chrome usage and the sharp drop in how many users are sticking with Internet Explorer. Mozilla’s Firefox, despite losing almost a third of its user base between May 2010 and November 2012 does still remain the intermediate browser of choice.

Date

IE

Firefox

Chrome

Mar-09

43.30%

46.50%

4.20%

May-10

32.20%

46.90%

14.50%

Nov-12

15.10%

31.20%

46.30%

Aug-14

8.30%

24.70%

60.10%

Whilst these statistics are for overall browser usage and not specific to SharePoint utilisation, keeping these trends in mind is important as SharePoint doesn’t necessarily play nicely with non-Microsoft browsers. Some of the more unique SharePoint features (like these) are built in Active-X, a proprietary technology that only works in Internet Explorer. Knowing these limits when planning browser support around a SharePoint deployment is invaluable. Extending this line of thinking to third party products both commercial and open source should be seen as a wise investment.

Armed with an idea of the likely browser habits of your audience, a SharePoint professional will know where to begin assessing the list filter. Should the project not work in any of the browsers above, they can now work what the potential damage will be. Having deployed the list filter against several versions of SharePoint in the browsers listed above, the following behaviours were noted.

SP Version

IE

Firefox

Chrome

SharePoint 2007

Rendered

Didn’t render

Rendered

SharePoint 2010

Rendered

Didn’t render

Rendered

SharePoint 2013

Rendered

Didn’t render

Rendered

What these notes (as seen in the project forums here) show are that any FireFox user is not likely to see the list filter render to any SharePoint deployment that they may be visiting. As of August 2014 at 24.7% usability, that’s almost 1 in 4 of any user base, which is a significant number. (How to get the script working with Firefox is the companion tutorial for this article).

Moving on from this, knowing what versions of SharePoint the list filter works on is only one part of our journey. As Microsoft ships the product with several different list and library templates it would be easy to assume that if the List Filter works on one, it would work on all of them. To explore this assumption in greater detail, these templates were all tested. Please see the table below for the results. Please note that only a custom list was tested, not each specific list template packaged.

 

 

Template

Rendered

Worked

Custom List

Rendered

Yes

Asset Library

Didn’t render

No

Data Connection Library

Rendered

Yes

Document Library

Rendered

Yes

Form Library

Rendered

Yes

Record Library

Rendered

Yes

Wiki Page Library

Rendered

Yes

 

The last level that we can assess the list filter on is the column level. It provides a great freebie in that you can use it to filter on field types that normally aren’t filterable. This includes calculated columns and notes (multiple lines of text) fields.

Link to SharePointReviews.com product review

Currently there is no entry on http://www.sharepointreviews.com for the Instant List Filter.

“End User – Developer” scale

This tool fits squarely in in the End User part of the “End User – Developer” scale. The list filter is easily deployed to the client with little effort, from which point it pretty much becomes a “fire and forget” solution. There are several other ways to install the solution but the ability to copy and paste the code into a Content Editor Web Part makes this very accessible.

Potential pitfalls / problems

The instant list filter was originally developed for SharePoint 2007. This is the single biggest problem that IT professionals are likely to have with it. It can work with SharePoint 2010 / 2013 though. The issues that you are likely to experience with it are:-

  1. It only filters on returned item count and doesn’t go past pagination. For instance, if you have a list with 3000 items but have set pagination to 100 per page, the list filter only works on those 100 items.
  2. It also doesn’t work on external lists unless modified to do so.
  3. It doesn’t work very well with FireFox unless modified to do so.

Tutorials

Because the list filter is easy enough to get started with, an installation tutorial would be pointless. Instead, what we’ll look at is how to get the script working with FireFox, which appears to be problematic for some users.

Conclusion

When installed and operational the instant list filter looks and feels like it should have been part of the SharePoint product itself. It’s a classy and easy-to-use extension that complements the OOB search tools very well. The ability to filter on traditionally non-filterable field types is a big bonus. It does have its limitations however, with the most potent of these being that it only filters on the rendered page items NOT the entire list.

The links below are my reference list: –

  1. Original CodePlex Project Link: – https://instantlistfilter.codeplex.com/
  2. Jaap Vossers Blog – http://blog.vossers.com/
  3. Business Data List Web Part usage – https://instantlistfilter.codeplex.com/discussions/228167
  4. Visual Upgrade changes – https://instantlistfilter.codeplex.com/discussions/262132
  5. Filtering on just a single column – https://instantlistfilter.codeplex.com/discussions/257825
  6. 2010 Code – https://instantlistfilter.codeplex.com/discussions/49123
  7. W3C Browser Statistics & trends – http://www.w3schools.com/browsers/browsers_stats.asp

Building a list-specific search with JavaScript

Whilst writing an article that looks at the Instant List Filter (hosted on CodePlex) I started wondering if there was an “Out of the Box” search solution that allows users to search within specific lists. It’s a discussion that I’ve frequently seen in the TechNet forums, particularly whenever search scopes are mentioned. Whilst I wasn’t able to locate anything via the SharePoint GUI, there is indeed a way that this can be achieved, simply by using JavaScript and the Content Editor Web Part.

Solution Details

The core solution is to embed some JavaScript code within a Content Editor Web Part (CEWP) and to tweak it for your list / library. Within the source code (HTML view for SP2010) the code snippet entered provides the end user with a dropdown box, a textbox, and two buttons. These buttons are a Search button and a Clear button.

The dropdown list provided will contain a hardcoded list of all the column names that you want to make searchable. The intention is that the user selects the column to search by picking it from the dropdown box, enters his search text and then clicks the Search button.

The JavaScript will then redirect the user to the same page, with query string data appended to the URL. The Clear button sets the query string url back to blank, which in effect clears the search data and ensures that the entire list is back in view.

When search scopes are enabled in SP2010, the option to search the list is automatically included in the list of options. However, search scopes are enabled at the site collection level, meaning that once enabled, all lists within your site collection will get this option. This JavaScript alternative is particularly useful if you want to enable list-level search for specific lists only. It also has the added advantage of allowing results to be displayed in situ instead of redirecting to a search results page. However, rather than jumping straight into the code, let’s look a little at how OOB list filtering works as this is the functionality that the script plugs into.

Looking at the query string in greater detail

  • In your SharePoint site create a list that has a high number of columns. The Contacts list works perfectly for this

  • Next, input a few dummy items. Having a few rows to play with works best. In my example I’ve used two football managers from the UK Premier League as well as the national team manager

  • Now that you have some test data, apply a filter and wait for the page to reload. The demonstration screenshot below applies a filter to the Last Name column.

Script Details & how to amend

  • Step One: On the page that you want to apply the search field to, use Site Actions à Edit Page
  • Step Two: Click Add a Web Part
  • Step Three: Add an HTML Form Web Part or a Contend Editor Web Part, either will work

  • Step Four: Input the code snippet below and make the following changes
    • In the function RedirectURL add the columns you want to make searchable from left to right using the format “Column2”, “Column3” and so on
    • In the same function, locate this text window.location.href = “AllItems.aspx?” and set this to the page you want the search results rendered on. The script has this set to the default view AllItems.aspx. Please note that you MUST keep the question mark in the code.
    • In the Search field you’ll see some options that look like this: – <option
      value=”Title”>.
      These fields need to correspond to the internal name NOT the display name of the
      columns that you want to make searchable. Column internal names are explained very well here.
  • Step Five: Save the file once you’ve made your amendments and your page should reload looking something like the below, with a basic but list-specific search engine at the top of the page

Further usage

There are probably some things that you can do to take this further if so desired. Some of the tweaks I’ve made include: –

  1. Styling the buttons according to branding requirements
  2. Keeping this code in a separate HTML file and linking it within a CEWP
  3. Hiding all but the first selection field to force searching within only one column

How to update Parent Folders Timestamps when Child contents have been modified

Something that SharePoint professionals occasionally get asked is whether it is possible to update a parent folder when child documents within it have been altered. Whilst my first response is to encourage the use of metadata and flatter file structures, it’s fair to assume that this isn’t always achievable. Some teams and personnel are comfortable with folders and don’t see a reason to change.

This blog post shows how you would achieve this using Documents Sets and SharePoint Designer. Document Sets are a bit more flexible than folders. As such this approach doesn’t lend itself well to existing folder structures: –

  1. Create a Site Column called DocSetName. Make it a Single line of text data type
  2. Create a LastModified column. Make it a Date/Time data type
  3. In the document library, where you want to make these changes, activate the management of content types via Document Library Settings à Advanced Settings à Content Types
  4. Click “Add from existing site content types” and add the Document Sets
  5. In the content type section, click on Document Set à Add from existing site or list columns and add DocSetName and LastModified
  6. Next (still within the Document Set Content Type Settings) click on Document Set Settings and scroll down to Shared Columns. Select DocSetName
  7. Next, within SharePoint Designer, create a new workflow at the document library level
  8. Set this workflow to automatically start when an item is created or changed. Using the Update List Item (update item in current list) action set the “LastModified” column to the current document item “Modified” column value. What this means is that any new document “Modified” column will be update the LastModified field of its parent Document Set.
  9. Back in your library, create a view that sorts by LastModified (descending) and you’ll see that the Document Set with the most recently edited item will be on top

The caveat

There is one trade off to getting this working and it’s this. Any new items created within a Document Set MUST have the name of the Document Set manually entered into the DocSetName column. If this isn’t done than the workflow will error out. The reasoning behind this is explained below.

What does the workflow do?

This idea is that each Document Set shares the DocSetName column value with any document contained within it. As set up in step 3 any document that gets created or get modified will trigger the workflow. The workflow effectively goes to find the item whose “Name” column value is equal to current document item “DocSetName” column value. Subsequently it will always find the parent Document Set item and update its “LastModified” column with the current document modified date.

This means that each document set “LastModified” value is always going to be equal to the modified time of one of the child documents within it. Without the DocSetName column on the document level being manually filled, the workflow cannot make the association and will return an error.

That about covers it but let me know if you have any questions, suggestions and so on.

Tutorial: Using the SharePoint List Field Manager

After I’d written the tutorial for the Seadragon Web part, I hit upon the idea of making short introductory guides an additional part of the CodePlex Corner Series. In the course of my playing around with the goodies on offer, I’m typically taking notes for my own records. It’s not really a huge leap to tidy them up and make them available for publication.

I don’t really have a specific format in mind but I’d like to try and make these tutorials as inclusive as possible, especially as some of the projects might not have terribly detailed literature with them. Any part that’s not relevant for more experience readers can always be skipped.

With that in mind, let’s get you started with the SharePoint List Field Manager. This is an easy tool to use, so the tutorial will be brief. We will cover web part installation, then activation and will look at some best practice ideas around it.

Installing the SharePoint List Field Manager

  1. Create a folder on your root drive called Web Parts. This should be something like C:\Web Parts
  2. Download the ListFieldManager.wsp file into this folder
  3. Open the SharePoint 2010 Management Shell. Typically this is Start à All Programs à Microsoft SharePoint 2010 Products à SharePoint 2010 Management Shell. Run this as the administrator
  4. Use the following PowerShell Command to install the wsp file. Add-SPSolution “C:\Web Parts\ListFieldManager.wsp”. Please note that the double quotation marks are needed for the file path. Otherwise, you may generate the positional parameter error message below.
  5. As PowerShell will helpfully tell you the solution is deployed but not installed. Installing the solution is what will make it available for use.
  6. Use this PowerShell command, making sure to change the http://YourApp URL to your own Web Application. This should install with no issues
  7. Once this command has completed the List Field Web Part will be available for use

     

Activating & using the SharePoint List Field Manager

The List Field Manager is a site collection feature and should be activated as such. It activates with no problems. This will be the same for both SharePoint 2007 & SharePoint 2010. The end product is a web part that you deploy and use to configure your lists: –

  1. Navigate to Site Actions à Site Settings à Site Collection Features and activate the web part. It is listed under SharePoint List Field Manger.
  2. Now that the web part is available it will be in the Web Part Gallery. It will appear under the SharePoint Management category
  3. Once the web part has been added to a web part zone you can feed it the URL of the site where you want to manage the lists. Please be aware that you cannot access lists in other sites if you are using the SharePoint 2010 SandBox deployment. Either way click on Display Lists
  4. The web part reloads with a List drop down, which is populated with all available lists for the site that was selected. Select a list and then click on Display Fields
  5. This will reload the web part again with a second drop down list from which you can select the field that you want to modify. Make the appropriate choice and then click Display Field Settings
  6. The web part reloads again with all available options for that field. The end configuration will look like this

Best Practice / Suggestions

These are some ideas and thoughts that struck me as I was using the SharePoint List Field Manager as things that I’d do when introducing the web part into any of my deployments. My current suggestions are: –

  1. Customising a View field to act as an List Admin Page

Best Practice #1: Setting up a List Admin Page

A useful trick I’ve found is to place the List View Manager within a page that’s associated with its usage. This simply consists clearing out the contents of a View Page and adding the web part in its place.

  1. Within your list or library enter the List Settings and scroll down to the Views Section
  2. Click on Create view. This loads a new page where you select the view format
  3. Click on Standard View
  4. This loads a new page where the view is configured. Forget about configuring anything here; just call the view something like List Field Admin Page. This can also be set up as a personal view. Click Ok. This loads a new page with the standard view
  5. On this page, get into the page editing mode via Site Actions à Edit Page
  6. Edit the web part from this view and set the hidden field under the Layout options
  7. Add the List Field Manager and move this to the top of the page
  8. You will now have an administration view with the List Field Manager present for future configuration

The CodePlex Corner: SharePoint List Field Manager

The link to the Project is https://listfieldmanager.codeplex.com/

This edition of the CodePlex Corner turns its attention to a product called the SharePoint List Field Manager. At the time of its launch, it was created as a value-add product for CorasWorks customers and has been developed by their VP of Technology, Adam Macaulay. In May 2010 the company decided to release the product into the SharePoint community via CodePlex. The List Field Manager currently comes in three flavours: –

  1. SharePoint 2007
  2. SharePoint 2010
  3. SharePoint 2010 Sandbox

The List Field Manager does one thing but it does it very well. It allows you to set the Boolean properties on any column within a SharePoint list or library. In plain English, it partially addresses one of the perceived gaps of SharePoint. That’s the lack of granular permissions insofar as column/view level security is concerned. Once this product is installed and activated it allows you to configure, on a field by field basis, the following settings: –

  1. Hidden: This sets whether a field can be displayed in the list
  2. Read Only: This controls whether a field can be modified by the users
  3. Show in Display Form: This controls if a field is displayed in the DisplayForm.aspx
  4. Show in Edit Form: This controls whether a field is displayed in the EditForm.aspx
  5. Show in New Form: This controls whether a field is displayed in the NewForm.aspx
  6. Show in List Settings: This controls whether a field can be modified via List Settings
  7. Show in Views: This controls if a field is visible within List Views
  8. Allow Deletion: This controls whether a field can be deleted or not
  9. Show in Version History: This controls whether a field is displayed within an items Version History

These properties can also be accessed and changed in PowerShell and the SharePoint Manager, as seen here. Their only configurable options (in true Boolean style) are True or False. The List Field Manager simply provides a more accessible interface for accessing them.


More information on the Field Properties is available on MSDN on this link.

Let’s think about some of those options for a moment and the power that they provide. What other major SharePoint technology gives us the alternative to work with columns in such a way? InfoPath forms. Whilst the List Field Manager isn’t (and was never intended as) as a substitution for InfoPath, it does provide a great “no cost” alternative. This means that you can use things like calculated columns for various effects (such as calendar colour coding) and hide them from various .aspx forms and views. This allows either the Foundation or Standard versions of SharePoint to be extended and manipulated in simple but powerful ways.

Post installation the List Field Manager is available in the Web Part Gallery and allows you to select any list from a provided URL once it’s been activated. You can then select the field and set as appropriate. Compare some of the options below to the earlier screenshot from SharePoint Manager and you’ll see the same properties.

I was also curious as to whether this worked with the forms generated with External Content Types. So I set up the AdventureWorks Community samples, built an external content type and an external list from the customers table. All the typical CRUD operations were defined with the end form looked like this.

With a few grammatical tweaks to the labels this would make a workable list but that Demographics field really doesn’t serve any purpose being surfaced within SharePoint. The List Field Manager picked it up just fine but wasn’t able to tap into any of the properties that we can manipulate with SharePoint Lists.

Link to SharePointReviews.com product review

The link to the SharePointReviews Product category is to be located under Content Management à Lists and Libraries on the following URL: http://www.sharepointreviews.com/sharepoint-lists/1988-sharepoint-list-field-manager

“End User – Developer” scale

Working on the basis that an Administrator will have installed this web part in the appropriate fashion; the List Field Manager is fairly straightforward to use. I can see this product presenting an acceptable alternative to InfoPath form development. On that basis, I’m rating this product at Power User level. Administrators & developers shouldn’t have that many problems with the List Field Manager in return for the functionality it provides them.

Potential pitfalls / problems

I’ve only been able to test this version against SharePoint 2010 so I can’t comment conclusively on any problems that the 2007 edition might encounter. The only potential problems that I could see for this are: –

  1. Limitations of Sandbox Deployment: Sandbox 2010 Deployment doesn’t allow cross site list management (this is referenced in the CodePlex documentation however)
  2. Settings not added to Site Settings: As this is a web part, not a link in the site settings, an administrator might potentially forget where this web part has been deployed. In a potential workaround, you could possibly set up a dummy view page called Admin, delete the list view and add this web part to it
  3. Hidden vs. Read Only Fields: The differences between the Hidden & Ready Only properties are confusing. Read-Only won’t surface a column but then lock it for editing, it removes it from the form.
  4. Internal Content Types Only: Doesn’t work on external content types

Conclude and add any relevant links

In closing out the article, I think this is a great tool. It provides an awful lot of utility and is something that can conceivably be farmed out to well-trained or experienced users which removes a small dependence on IT or the SharePoint professionals.

The links below are my reference list: –

  1. CodePlex List field Manager
  2. Corasworks Community: List Field Manager
  3. Field Properties
  4. SharePoint Reviews: SharePoint List Field Manager
  5. AdventueWorks Community Database

SharePoint 2007: Title, Description & Properties page inaccessible even with full permissions

A recent job change has taken me back to playing with SharePoint 2007. Whilst it took some getting used too, I’ve quickly gotten back into the swing of things. Until something peculiar happened.

Even with full permissions I wasn’t able to access the Title, Description, and Properties page. I had full site collection rights and everything looked like it was in place. I was stumped.

I tried direct linking it via its layouts page (_layouts/prjsetng.aspx) and it worked. The page let me straight in.

After a little poking about, it seems that a previous SharePoint CU applied to the farm had the side effect of disabling access to this page via the Admin GUI in Site Settings. I’ve yet to ascertain which one it was but I’ll be sure to post an update if I find out which one it was.

So, lesson for today. Even if SharePoint says NO, try direct linking via the _layouts page if you think you should have access to something. It may just work.