The "old style" list filters in Sharepoint List views (e.g. when the user clicks on a column to filter or sort on column values) use an http GET, so the filter paramaters are encoded in the page URL.

This makes it easy to copy the URL to use in a link that will show the list with a "canned filter" applied. I.e. if I have a library with documents marked as (say) "draft" or "final", I can easily create a link that shows a list of all the final documents.

The "new style" metadata key filters (the ones that display in the list view sidebar) use POST to communicate with the server.

How can I drive this mechanism through the URL (custom links)?  I'm ok with using Javascript/JQuery to do this, but I don't know where to start on getting a handle on the filtering mechanism.

Looking at the POST data in Firebug there are some visible filter values in there, but there's also a whole slew of other (encoded) form data, and it's not clear how much of it is required for the server to take the POST as a valid filter request.

I would really appreciate a pointer to a description of how to do this.

Regards: colin_e

Hi,

Thank you for your question. I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience. Thank you for your understanding and support.

Thanks,

Linda Li

Hi,

According to your description, I need to do more research and do some test in my lab.

Paul Shui
Microsoft Online Community Support

Please remember to click Mark as Answer?on the post that helps you, and to click Unmark as Answer?if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread

Thanks for looking at this guys.

As an update, after several hours researching this on the net with no luck, and more hours experimenting live in the browser I had a partial breakthrough.

I discovered that sometimes if you pass a "traditional" filter parameter to the list view, you can tip it into a different mode where it WILL use URL path parameters to specify what's called a "ServerFilter", with a parameter at the end of the URL that looks something like "ProcessURLtoCAML=1"   (that may not be the exact name, i'm not in front of the machine at the moment so this is from memory).

Once you have a "magic" URL that triggers this behaviour you can start experimenting with applying metadata filters in the list "Key Filters" area to (hopefully) copy the URLs to use in canned "filtered list" links.

At this point more unpredictable behaviour occurs.

The "...toCAML" parameter seems to tell the view to READ filter values from the URL query string. Whether the server WRITES the new filter values back into the URL as a redirect when you change filters via the UI seems to me to be pretty random, after changing the Key filter settings in this mode, sometimes the query string changes to reflect the new filter, sometimes it doesn't :-}

The only predictable element i've found so far is that (annoyingly) filters on fields of type "Enterprise Keywords" don't seem to be reflected in the query string. They are only passed via the query POST parameters, which as I said in the original question are not easy to fathom.

I haven't found any user-level documentation on this at all so far, and the behaviour seems to be both complex and unpredictable.

I could really do with some pointers to help unravel this stuff.

Hi colin_e_uk,

it's true that POST method may not be passed on the URL as its the design of HTML passing parameter method.

http://sharepoint.stackexchange.com/questions/60543/how-to-search-query-by-enterprise-keywords

as i remember, you may need to put query string first, then add the managed metadata filter, if you put the filter first then query string it may not be work well. so most probably that explains the '...toCAML' part of your descriptions.

if the result not consistent in 2013, i guess we may have some issues here, that we need to debug. Because of limited resources that Forum team have, i suggest that you to open an advisory ticket to us, so we can debug your environment and provide the better workaround/solutions regarding this issue.

>> Because of limited resources that Forum team have, i suggest that you to open an advisory ticket to us, so we can debug your environment and provide the better workaround/solutions regarding t

Hi colin_e_uk,

we have 2 types of pay-based service contract, premier and professional.

if your company have the premier contract, then your company may open the case by contacting your TAM (technical assessment manager), they will help you to do this.

for professional service, you can call our customer representative for more information, the phone number should be stated in support.microsoft.com