Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

May 10 2013

05:40

Using Filter Web Parts to search a SharePoint List / Library View's entire directory hierarchy (incl. sub-folders)

So, this is a fairly common use-case and requirement that FilterZen easily delivers a workable solution for. (I think we have this topic covered in a forum thread or two, but a quick "authorative" blog post on this can't hurt.)

Here's your situation:

  • you have a SharePoint List View (or Library View) with folders shown. Easy, simple, your users know how to work with that.
  • you have it connected to a Filter Web Part so that users can easily "search" locally within that List View, without needing SharePoint's Search UI.
  • your users appreciate the display of folders, but also would like to be able to "search in all folders" when they begin specifying filter criteria.

By default, this won't happen... here's how to make it happen.

May 06 2013

06:24

Rare errors #1: "Root element is missing"

Our license files are sent out as XML text files. Under very rare circumstances, you may get the following error message when attempting to apply your license file: System.Xml.XmlException: Root element is missing. Here's how to work around this uncommon issue.

September 11 2012

07:04

September 25 2011

15:41

Using User Profile Property Values for List Filtering in SharePoint

Every other month or so, we receive an enquiry like the following:

Is it possible to filter (using FilterZen) a standard Document Library by a specific user profile field such as Department, where Department is also a field in the List / Library? I cannot see a way of doing it like the out-of-the-box Current User Filter Web Part.

Can do! With a few tweaks. Truth be told, we've been meaning to roll out first-class native FilterZen support for the SharePoint Server (MOSS / SPS) User Profiles model for a bit now. We expect to finalize an update for this by early October 2011, ie. in the next 1-2 weeks.

But that's no excuse not to implement such a requirement in FilterZen right now, with the current version you have now available. Of course, if you're on MOSS 2007 / SPS 2010, you could just use the out-of-box Current User Filter Web Part right away and skip FilterZen entirely — but if you have other filters for your List or Library you'd like to apply with FilterZen, integrating a User Profile Property into your main FilterZen Web Part is an understandable need and this is how you do it:

Let's work from the original enquiry above. You have a List View / Library View Web Part on your page (or you work directly on a View Page for that Library) and the Library contains a Department field. We want to filter so that only documents are shown that apply to the current user's Department, as stored in the corresponding User Profile Property.

For now there are no other Web Parts on the page. Add to it an out-of-box Current User Filter Web Part, a FilterZen Transformer Web Part and a FilterZen Filter Web Part, in that order. Do not connect any Web Parts at this point. Since you can freely re-arrange the order of Web Parts on the page interactively, be sure we have the following Web Part order:

  1. Out-of-box Current User Filter Web Part
  2. FilterZen Transformer Web Part
  3. FilterZen Filter Web Part
  4. Your Library View Web Part

1. The Current User Filter Web Part

  • For Filter Name, specify TempDepartment
  • Under Select value to provide, pick Department
  • Under Advanced Filter Options, tick the Send Empty if there are no values check-box option

2. The FilterZen Filter Web Part

Apart from any other filters your FilterZen Filter Web Part may contain, you will add a Text Filter named Department. This filter name refers not to the User Profile Property but to the target Library Field it is filtering! Apart from the name, the only other setting you need to set for this Text Filter is the default value which you will set to {$TempDepartment$} (or whatever name you used in step 1.)

3. Web Part Connections

Only now do you connect all Web Parts on the page, exactly as follows and exactly in this order:

  • From the Connections sub-menu of the FilterZen Transformer Web Part, select ICellConsumer (Get Cell From) and then pick your Current User Filter Web Part.
  • From the Connections sub-menu of the FilterZen Transformer Web Part, select IRowProvider (Send Row To) and then pick your FilterZen Filter Web Part.
  • From the Connections sub-menu of the FilterZen Filter Web Part, select Send Filter Values To and then pick your List View / Library View Web Part.

At first glance, this possibly looks more complicated than it really is — in fact, it's a fairly straightforward sequence of simple steps, really! With the next FilterZen, as usual things will be even easier and even faster to implement. But even now, FilterZen's core flexibility let's you combine the (very few) remaining not-yet-fully-absorbed skills of out-of-box Filter Web Parts with its many rock-solid and tremendously useful capabilities already provided.

This was just one example of how experimentation with core building blocks and re-using basic capabilities can take you far beyond the myriad of built-in, "typical" turn-key use-cases. So keep exploring!

September 17 2011

19:16

Manual installation / deployment of our SharePoint WSP Solution Packages

All our Web Parts and SharePoint solutions come with a deploy.exe Windows-based installation+deployment wizard to achieve streamlined installation and deployment. This wizard works smoothly and pleasantly for 99% of users.

Except when it doesn't. With a growing user base, a tiny minority of edge-case users or misconfigurations that prevent the wizard from completing are to be expected, and this article applies only to them.

Always try deploy.exe first. As a reminder, when you download one of our SharePoint tools, you get a roxority_<Product>Zen.zip file, ie. roxority_FilterZen.zip, roxority_PeopleZen.zip etc.

Copy it to your SharePoint server (or in a multi-server farm environment, to the primary web front-end server, ie. the one hosting your SharePoint Central Administration) and extract this ZIP setup package on there.

Now, don't just double-click deploy.exe to run it: instead, right-click it and depending on the Windows Server version, you'll see either a 'Run as administrator' or a 'Run as...' option.

  • If it's the latter ('run as...'), pick that option and then specify a user account that (A) has administrative rights on the machine AND (B) is also a member of the SharePoint Farm Administrators group (review it in Central Administration if unsure). Both conditions should be met for best results. (Better yet, you're already logged in to your Windows Server as such as user account.)
  • If the former ('run as administrator'), be sure you're logged in to the server as a user account that (A) has administrative rights on the machine AND (B) is also a member of the SharePoint Farm Administrators group (review it in Central Administration if unsure). Both conditions should be met for best results.

Things should be smooth sailing from here, but if you belong to the less-than-1% of users where the deploy.exe wizard does not complete successfully, read on.

Manual step 1 — install via STSADM:

If you are about to install one of our add-ons, we have to assume you're already at least remotely familiar with the STSADM tool that ships out-of-box with every SharePoint installation. No need to be a command-line ninja, you'll just need one command:

  • STSADM -o addsolution -file c:\fantasypath\<WspFileName>.wsp

Replace c:\fantasypath with the full directory path of the extracted setup package, which will contain between 2 and 4 WSP files. For <WspFileName>.wsp, substitute the WSP file appropriate for your environment:

Product SPF 2010 SPS 2010 WSS 3.0 MOSS 2007 roxority_ExportZen_… …xiv.wsp …xiv.wsp …xii.wsp …xii.wsp roxority_FilterZen_… …xiv.wsp …xiv.wsp …xii_wss.wsp …xii.wsp roxority_PeopleZen_…   …xiv_wss.wsp …xiv.wsp …xii_wss.wsp …xii.wsp roxority_PrintZen_… …xiv.wsp …xiv.wsp …xii.wsp …xii.wsp roxority_UploadZen_…   …xiv_wss.wsp …xiv.wsp …xii.wsp …xii.wsp

Manual step 2 — deploy via Central Administration:

In SharePoint 2007 (WSS 3.0 or MOSS 2007), go to Central Administration / Operations / Solution Management — in SharePoint 2010, go to Central Administration / System Settings / Farm Management > Manage Farm Solutions.

Next, select the WSP file you just installed in step 1 with STSADM. Click Deploy Solution and follow the on-screen instructions. Do this repeatedly UNTIL you have fully deployed the WSP to:

  • all your content Web Applications applicable for this WSP
  • the Central Administration Web Application (MANDATORY!)
  • all Shared Service Provider (SSP) and Shared Resource Provider (SRP) Web Applications (MANDATORY!)

Manual step 3 — enabling, and then IISRESET:

Using farm-administrative credentials (best to follow the recommendations from the beginning of this article regarding deploy.exe), open any one page linked under the <Product>Zen Studio section on the Central Administration / Site Settings page. This should "enable" the software for full use in this SharePoint server farm, AND notify you about the success of this "enabling" operation too.

The software will not work unless and until this "enabling" procedure has been completed (just opening any <Product>Zen Studio page under Central Administration as per above should do this) and all web front-end servers in the SharePoint server farm have been IISRESET afterwards.

Manual step 4 — activate Site Collection Features:

In the root Web Site of your content Site Collection, go to the Site Settings page. In the Site Collection Administration section, click Site Collection Features (NOT Site Features!) and on the next page, activate the Site Collection Feature(s) you need.

Uninstalling our SharePoint WSP Solution Packages

Just like installation, your best choice for uninstallation is our deploy.exe wizard that is part of the downloaded roxority_<Product>Zen.zip setup package. But if you need to uninstall the solution package manually:

  • first perform manual step 4 above, but instead of activating the Site Collection Features, deactivate them.
  • then perform manual step 2 above, but instead of choosing Deploy Solution, repeatedly Retract Solution until it is no longer deploy to any Web Application.
  • then perform manual step 2 above, but instead of choosing Deploy Solution, click Remove Solution.
  • IISRESET all web front-end servers in the SharePoint server farm

 

April 06 2011

09:40

SharePoint "Unknown Error": How to Show All the Details

Every couple of months, we receive a support request that goes something like this: "when I attempt to do X, SharePoint says Unknown Error". Of course there is no way we can fix an "unknown error". Yet these errors are not unknown, by default SharePoint simply does not show their inner details — presumably the user experience designers at Microsoft presumed that a real error message is too scary for SharePoint end users, but an "unknown error" is somehow so much more reassuring... or maybe there really are too many 3rd-party developers who as a matter of habit always include sensitive passwords in their error messages.

Anyway, if you do encounter an Unknown Error (this has become spectacularly rare fortunately as our software has grown ever more stable over the last 2 years), then we need you to turn on Detailed Error Messages in your SharePoint environment. This is easy to do and absolutely non-dangerous, plus typically you will be reporting your issue from your QA, test or dev server rather than production. Here is what we need you to do.

March 19 2011

01:25

Hi, Ryan Wheeler, developer of "Pentalogic FilterPoint"!

First off, congrats to getting a Filter Web Part developed and to market. As we know too well, this takes skills of all kinds, countless man-months once the first version is scrutinized by real world enterprise users with the most complex and fickle requirements, much debugging and hair-pulling...

December 25 2010

17:51

SharePoint 2010 List View AJAX Options and Filter Web Parts

A FilterZen user reported the following issue:

I have tried to set up the Filter Web Part with an Issue List on SharePoint Server 2010 and everything seemed to work flawlessly except the List 'unfilters' every time it is auto-refreshed.

I have tried putting the filters in a Web Part on the List and applying it to a List in a Web Part where AJAX Options Asyncronous Refresh is enabled with the same result: the List unfilters every time it is auto-refreshed.

The strange thing is that it seems to work OK when AJAX Options Manual Refresh is applied to a List in a webpart?!

We could reproduce the issue, but now the much bigger question was how to fix this. First off, to summarize the issue:

  • In SharePoint 2010, List Views give you a tool-pane section with so-called AJAX Options:
    • the Show Manual Refresh Button option lets end users refresh the List data shown in the List View Web Part without reloading the entire page.
      • This AJAX refresh mode works just fine even with filters applied from connected Filter Web Parts such as FilterZen or the out-of-box Filter Web Parts.
    • the Enable Asynchronous Automatic Refresh option seemingly performs the above background data refresh periodically and automatically, without the end user having to click a button.
      • This AJAX refresh mode simply does not respect filters applied from connected Filter Web Parts, neither FilterZen nor the out-of-box Filter Web Parts!
  • Since the out-of-box Web Parts exhibit the same problem as FilterZen, this did not seem to be a bug in our product, but nevertheless wouldn't it be neat if this could be made to work, at least for FilterZen users?

We looked "long and hard" in SharePoint's unintelligible heap of client JavaScripts to figure out why the first AJAX background data refresh mode seemed to work but the second wouldn't, with respect to filters applied from connected Web Parts.

There may be an easy fix waiting to be discovered, but we couldn't figure it out. Rather than give up completely on the issue, we added the same "hack" to FilterZen that we figured we would also apply as SharePoint devs / consultants, would we face the issue in a real-world project:

  • the AJAX refresh called from the button works while the periodical background refresh doesn't (with respect to connection-provided filters)
  • hence:
    • deactivate the Enable Asynchronous Automatic Refresh option,
    • activate the Show Manual Refresh Button option and
    • add JavaScript to the page that periodically invokes the Manual Refresh button to "emulate" the automatic refresh, but in the way that has been shown to work (via the refresh button).
  • optionally also include script to hide the Manual Refresh button if this should not be made available to end users.

The above logic is now included directly in FilterZen so you won't need to script the above yourself, starting from build 3.8.0.34 and we tested this, it works! This affects all List Views on the page that have both Enable Asynchronous Automatic Refresh disabled and Show Manual Refresh Button enabled:

August 23 2010

01:35

Augment Search Result Pages with Filtered Document Library / List Views

While SharePoint's Search features present a great deal of configurability and customizability, it sometimes cannot be tweaked enough to support every need. We received the following request:

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.

August 19 2010

00:53

Lost Web Part Connections on SharePoint 2010 List View Pages (Windows 7)

This is just a short notice on what has to be one of the most curious little bugs we have come across in SharePoint 2010 so far:

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.

July 31 2010

15:13

June 30 2010

13:13

Adding an "Advanced Search" interface to any List or Web Part in no time -- with the new on-the-fly Filters

We just introduced an outstanding new feature to FilterZen: the Dynamic Ad-Hoc Filters that give you a full-fledged Advanced Search user interface for any connected Web Part, and fully pre-populated with applicable fields for any SharePoint List:

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:

May 29 2010

10:14

List Filtering: Highlighting Partial Matches in Search Results

Just a quick update: users of FilterZen, the ultimate Filter Web Part for SharePoint 2010 and 2007, can now greatly improve the end-user usability with a simple check-box option we just newly introduced: highlighting of filter values (ie. search phrases) in the connected consumer List View "search results":

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.

May 27 2010

20:08

Filtering SharePoint Lists using nested AND / OR operator precedence hierarchies

A few days ago we pushed out a silent minor update to FilterZen that finally gives you ultimate control over how to combine multiple SharePoint List filters. As the array of available operator options is now quite broad, this article provides a summary overview on how filters and values can be logically combined when filtering SharePoint Lists.

May 24 2010

15:53

Missing the List View selector tool-bar drop-down menu in SharePoint 2010? Introducing the new List View Picker.

In SharePoint 2007 and WSS 3.0, whenever you were on a List View page (or added a List View Web Part or List-bound Data View Web Part), you always got (or could easily enable) a nice out-of-box View selector drop-down in the List tool bar. Switching Views was simply a one-click affair. In 2010, this is often no longer the case: you don't get an easy one-click View selector as soon as you add a second Web Part to an out-of-box View page, and you also don't get one when re-using the List as a Web Part on other pages.

April 23 2010

16:15

Sprechen Sie Deutsch? We certainly do! (French, too.)

We're all about simplification and making things easier, particularly all things SharePoint. Now we made it even easier for all German speaker — ja, auch Sie! — to explore our software: we just launched our first non-English site at ROXORITY.de.

April 05 2010

15:08

Populating text box filters with URL query string parameter values

One easy way to pre-populate a single SharePoint FilterZen filter of yours via the page URL query string is using the parameter name filter_DefaultValue after having ticked the Override Web Part settings from URL parameters check-box option in the Filter Web Part's settings tool pane.

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

  • For each Text Filter to pre-populate, add one corresponding URL Query String Filter.
  • Give it any name you wish but this should be different from the corresponding Text Filter — for example, assuming your Text Filter is named City, then name your URL Page Request Filter CityParam or simply C or any other name.
    • Important: disable your helper URL / Page Request Filters so that their values do not get sent to connected Web Parts directly, but are only used to pre-populate your Text Filters! Simply un-tick the This filter is enabled check-box option for each URL filter.
  • For the default filter value option of the Text Filter, specify {$CityParam$} or {$C$} or whatever URL / Page Request Filter name you picked in the previous step.
  • Now you can use the respective URL query string parameters, for example: page.aspx?CityParam=London or page.aspx?C=Berlin.
    • If you want the URL parameter name to be different from your URL filter name, then simply set that filter up accordingly by following the GUI instructions.

March 31 2010

12:01

Enabling CAML Filtering Mode for Data View Web Parts

Our CAML Filtering Mode brings many outstanding filtering capabilities to SharePoint Filter Web Parts targeting out-of-box Document Library and List Views, such as operators, wild-cards, value-range, date-spans, cascading drop-down List filters and much more.

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.

March 17 2010

12:09

"Exceeded data fetch limit" on DispForm pages with List View connections: the work-around

The following is a desirable scenario in many SharePoint projects:

  • 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.

March 08 2010

19:31

Filtering SQL Data View Web Parts in SharePoint

SharePoint's XSLT Data View Web Parts do support incoming Web Part Connections, but they are a fragile bunch. Connecting a Filter provider Web Part to List View Web Parts is straightforward. Connecting to a List-bound XSLT Data View can be a tad more tricky depending on circumstances, but still fairly easy. Connecting to an SQL-bound Data View requires a few Serious Setup Steps. This walkthrough helps you through it.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl