* Update: The official description to this problem can be found in the Knowledgebase Article KB2596519. There is also a hotfix avaliable that can be downloaded here. A big thanks to the Microsoft Support Team. *
One of my customers stumbles upon a strange bug in SharePoint that relies on the list views in combination with meta data and the meta data Navigation. In a special case the list view returns a false result.
The Problem
To reproduce this problem a standard document library is needed. This library has two managed meta data columns named “Color” and “Horse Power”. Both columns allow multiple values, which make sense for car descriptions to find cars by different colors and different horse power.
The values for the colors are:
- Dark
- Black
- Black / White
- Black / Green
- Black / Red
- Black / Pink
- Black / White
- Black
- Darkblue
- Darkgreen
- …
- Light
- …
- Metallic
- …
The values for horse power are:
- Less than 50
- 50 – 100 PS
- 101 – 200 PS
- 201 – 300 PS
The document library contains more than 170 items, which has all metadata assigned. The document library has metadata navigation enabled. The document library looks like this:
In general there is no problem browsing the documents and paging. The filtering also works correct but not in all cases. The problem occurs if specific values for colors with all descendants and horse power will be selected. The result will then look like this:
The item count of the view shows that 507 items will be returned by SharePoint but only seven items will be displayed. Paging also is not present because the view only displays seven items. The problem with this query is that the item count doesn’t count the returned items. Instead the returned terms of the metadata store will be counted and displayed. The correct result for this query should be 141 items. The calculation to get to 507 returned item looks like this.
141*3+84 = 507
141 by 3 is because they have all the same meta-data assigned plus 84 items has additional terms assigned. Simple calculation but a wrong result in any case.
Filtering by using metadata navigation is one possibility, but the same thing happens if the filtering will be done using the view headers. The result looks then the same:
A combination of list view header and meta-data navigation filtering will also output the same false result.
The Reason
The problem has nothing to do with the meta-data navigation control, the meta-data or the XSLT List View itself. The reason for this is that SharePoint executes a wrong SQL query against the database and returns then a wrong result back to the SharePoint user interface. I think there must be somewhere a wrong join in the Database. The values here don’t match to a real world scenario but filtering like this is a requirement in one of my SharePoint Applications. I think filtering like this is a common task in a document management system and should work.
The Resolution
The good news is that Microsoft confirms this as an offically bug and the solution is scheduled for the October CU. The lesson I learned from this is: Always open bug report like this to Microsoft and don’t let it be just a bug. The people at Microsoft were really helpful in this case. Cannot wait to get October CU. Currently the solution will be excessively tested.
So good I stumbled up on this description Stefan, great description.
We happen to have a similar issue with metadata navigation and key filters, in 2010 except ours is inherent to a Custom List.
3 managed metadata columns of (single value,multiple value,multiple value)type, the item count vs. returned items are messed up as soon as a combination of metadata navigation and filtering is applied and paging is gone as well in most cases.
When the view definitions themselves contain a filter, then a metadata filter applied on top of the view as well invokes the same issue.
I have not been able to work out how the calculation goes wrong as nicely as you did, but I hope the root cause may be similar and we may be able to have it fixed based on your trail.
Glad that i could help actually there are also some other small problems with manage meta data. With more an more filter applied to the view, the url gets longer and longer. If it gets to long then the view is broken too. I think could check this too. You will find some good information about that in the technet.
The best way to filter would be if SharePoint sends a post request but currently its the GET Methode.
Thanks, the technet article is useful too. Fortunately the length restriction does not apply to the parameters, and they are URL encoded as well.
The views do handle 10+ values in combined metadata filters, at least they render, but the displayed result is incorrect regardless of the complexity of the filter parameters.
I really hope that this CU has not yet been applied to our environment, because then it may be fixed quickly by deploying it or, by our SP patch arriving still in April. Fingers crossed.