In the simplest form of data filtration, we set up Views on lists or libraries to skim data of interest. Views work on individual lists or libraries and can also be referenced in web parts added to pages.
But, while working in a larger context, a Content Query Web Part is a useful tool to filter aggregated data sources in a site collection.
The configuration capabilities of the CQWP web part are large, however, in the given content, I’ve extended the limit of filtration for document libraries.
The preference of a Content Query Web Part over Content Search Web Part is purely on choice. However, this article specifically deals in context of SP Online or SP 2013.
It is known that in the same site collection, document libraries using the same site columns can be easily filtered using the CQWP. However, by default only 3 basic filter mechanisms are available. To cascade the filter criteria is an effort that requires customizing this web part.
By cascading I mean implementing the following set of requirement, which will be used as an example in this article.
Example:
The given example surely appears very simple, but the limitations of an OOTB CQWP curb its implementation. The following sections simplify the translation of a business requirement in context of its implementation.
How to customize filter of an OOTB CQWP
The process is a sequence of steps beginning with the basic configuration of the web part on the page to trickle down to the selection of the desired data sources. Having done this, the web part should be exported from the flyout menu option.
The main task for building the filtration logic and editing the exported web part file is explained in the following sections.
How to translate a business requirement
In the context of the aforementioned example, the logic is built as elaborated below.
- Identify the number of first level sub-queries.
In the given example, the query can be split into 3 sub-queries that are ANDed
- Split each sub-query into further simplified evaluation criteria. This step is iterative until the query can further be simplified.
In the given example, each sub-query equates the respective site columns to a set of values that are ORed
Having performed the above breakdown process, each sub-query now needs to be implemented to gradually aggregate to the complete requirement set.
How to build the query
Constructing queries require a minimum of following details:
- Names of site columns
- Entourage of values to be evaluated
- Logical operators to match the value criteria
Using logical filters on site columns requires that the columns be addressed by their internal names and not their display names that appear visually. Internal column name can be found in either of the following 2 ways:
- Checking the properties of the column in the list or document library. Right-click the column, and then click Properties. The internal name of a column appears in the Address (URL) property after ‘Field=’
- Using a CAML query tool like the CAMLDesginer2013. Upon selecting display names of selected lists/libraries, the tool displays internal names in the query building section.
My personal preference would be using the query tool, for the reason that the tool addresses the other two requirements of query construction – the list of allowed values for the type of column definition and the match criteria to be applied on them.
e.g.: A multiple choice column ‘ABC’ evaluates its value as ‘multichoice’, while a single choice column ‘DEF’ evaluates the values simply as ‘choice’.
N.B.: All other evaluation types are not listed in this article as they can be discovered from the tool.
Now, having discovered column internal names and the manner in which values can be evaluated, building the logic section is not much of a brainer, though it does require inspecting pair of eyes.The cue here is to disintegrate the required logic into groups of two, starting from the innermost logic and start building upon the aggregation.
The aforementioned example, can be targeted from the top most sub-query. Construct a logic for matching the site column for one from the given set of values and couple it with another set of value.
Step# 1
The construct of the build is to create evaluation logics for site columns and values and then proceed with coupling groups of two such matches with logical operators.
Here, the column ‘Artefact Type’ (internal name ‘Artefact_x0020_Type’) is of the type Choice, allowing only single values. In the given context, this column has to be evaluated to be equal at least one from the given 3 values – ‘Assessment’, ‘Case Study’, ‘Solution Description’ or ‘White Paper’, hence the use of the logical operator ‘<Or>’ for the given match criteria ‘<Eq>’.
Having done this, consider this group to generate one logical result ready to be coupled with another match. Hence, the construct is analogous with the text is green an indicator of already accomplished evaluation in the above step.
Step# 2
This gives us enough platform to proceed to the final evaluation of the first sub-query.
Step# 3
Now that the first sub-query is built, consider the entire construct to yield a single logical result. Upon inspecting the business requirement, this result is Anded with that of the another sub-query, which can be built on similar understanding.
Step# 4
The sub-queries at Step# 3 & Step# 4 can now be logically paired as in the given requirement.
Step# 5
Similarly, we proceed further simplifying the third sub-query as below:
Step# 6
And then coupling Step# 5 & Step# 6 in the final stage.
This query can either be tested for execution in the CAML query builder application before or iteratively by editing the downloaded web part and uploading it.
How to customize the web part
In the downloaded web part file (.dwp), search for the property ‘QueryOverride’ and extend it with the constructed logical query as below:
The web part is not ready to be finally uploaded to the page. Follow the successive screen shots as instructions to upload the custom web part.
This web part can now be added to the page like any other OOTB web part. However, it’s worth mentioning that its visibility or presence is limited to the page and not the site. Hence import it to multiple pages across the same site if you need to reuse it.
