We have a WSS 3.0 store of documents that we would like to share. They are stored as list items and there are a number of different columns which help describe the documents. Some are quite straightforward, such as document name, document description, division and subdivision within the organisation that created the document. The one that is causing problems is a column called keywords. It takes its values from another list (sample values might be: climate change, air quality, litter prevention, noise pollution control). Since a document might be relevant to a number of areas, multiple keywords can be selected. I found that once multiple selections were allowed, a search scope allowing the user to narrow their search by keyword just wouldn't work. I would like to allow a user to narrow their search by organisational division, which I have done, and I'd like to be able to give them good functionality to filter the results that are returned. The filtering wouldn't just be limited to the keywords; it would also allow users to filter by date and author.

whether we use our own premier SharePoint Filter Web Part or the out-of-box ones, or attempt to create any other kind of Web Part connection:

• on a List View Page (AllItems.aspx etc.)
• in the browser, via the Connections option in any Web Part's edit menu
• in the context of SharePoint Server development deployments installed on physical 64-bit Windows 7 Ultimate machines (the client OS doesn't matter in this discussion, Win 7 in this case is the server OS)

then the connection gets LOST — routinely, repeatedly, reproducably — as soon as the page gets freshly reloaded. Now, as long as you stay in the page state and perform other changes via post-backs, but keep the page view state alive (this is ASP.NET lingo but it'll have to do for now), the connection seems to stay alive, but re-initialize the page fully (not via an F5-postback but by fully re-navigating to it) and the connection is simply gone. All other modifications to your Web Parts and the page seems to have been persisted to the Content Database just fine, except for the connection itself!

Now of course the official recommendation is to use a Windows 2008 Server OS rather than Windows 7 for SharePoint Server deployments, and furthermore from the general design of SharePoint 2010 the customizing of List View pages with further Web Parts or even connections seems to be implicitly discouraged in the overall design — for example, you lose the List View selector drop-down menu in the Browse ribbon tab as soon as you add another Web Part to your List View page, and some indeed argue that such view aggregations and advanced behaviors should be realized in separate pages rather than the mere core View pages — but...

...as usual, theres a work-around to keep going:

quite simply, set up your Web Part connection in SharePoint Designer and it will be persisted for good. Of course now you have a customized, a.k.a. un-ghosted copy of the List View page in your content database (for no particular reason other than SPD always un-ghosting a page when you hit Save, even though the same customizations when done in the browser would not have resulting in such an un-ghosting since Web Parts and connections are neatly stored outside your page mark-up in the DB and are just merged with the page HTML by SPD when it opens it), but neither on your Windows 7 development server nor on most productive systems is this typically really an issue.

Previously, content managers, site designers or admins pre-configured individual filters with the proper settings for their end-users, but those had no way of customizing these. While this is still a valid use-case for many projects, with the new Dynamic Ad-Hoc Filters, end users can arrange and combine their own filters on the fly to search the List, Data View or other Web Part in a way that suits them in their individual, current situation.

• End-users can AND/OR combine multiple filters on the fly.
• The appropriate rich editors (date controls and people pickers) are shown when a field is selected, without a page post-back.
• End users can also search for "any field", for example "show me records where any field contains iron".
• Setting this up is a breeze, and admins can pre-define which fields and operators are allowed:

The highlighting needs to be explicitly enabled in the FilterZen Web Part settings tool-pane (in the Interactive Filters section, see above-right screenshot) and of course you can fully re-style and customize this using CSS: simply use the span.rox-hilitematch selector.

But what should you do if you need multiple parameters for multiple filters, or simply other, custom parameter names? This is actually fairly easy...

The good news is that you can also have all of these benefits for your XSLT Data View Web Parts, if they are bound to a SharePoint List. Unlike out-of-box List Views, this requires just a few setup steps for XSL Data Views.

In this article I'll show you how to make your Filter Web Part Connection to a XSLT Data View.

• You have two related Lists, such as for example Customers and Orders.
• The latter contains a Lookup Column pointing to the Customer of each and every Order.
• On the Display Form (DispForm.aspx) of each and every Customer, you'd like to show all its Orders.

How can you achieve this? Let us find out in this article.

Think about the out-of-box filtering and search capabilities of SharePoint: drilling down into a specific sub-range, whether in date-time terms ("show me data between March and August") or in numeric terms ("show me sales between 100 and 500"), if you don't want to Modify your List View everytime you want to see certain data sub-ranges, then neither the built-in Advanced Search nor the built-in Column header drop-down filter menus will take you there.

FilterZen made this possible, but until today this involved a number of redundant manual set-up steps. The more steps there are, or the more repetetive those are, the more there is scope for mistakes and omissions. As we saw how popular range filters are, we decided to save you even more hassle and time and further streamline the process for you...

I have three SharePoint groups called Branch1, Branch2 and Branch3. What I want to have happen is that when user of Branch1 hit my list they only see Branch1's records. When Branch2 users connect they only she Branch2's records and so on.

An interesting filtering requirement that we wanted FilterZen (our SharePoint Filter Web Part) to support fully. Starting with build 3.6.0.10 (the newest available for download at the point of writing), this can now be achieved with any User Filter.