I've got various issues around the filtered views, one of the biggest problems is that I have a library that was indexed after it reached the threshold, meaning that any filtered views I create will not work (with the exception of created/modified dates). Therefore, it's difficult for me to test any theories. I have mirrored the problematic library and succesfully indexed and filtered the mirror (which has <5000 items) - I still don't have a solution, it just means I know that's one of my problems when testing.
The other issue is that the architecture as it stands has one document set CT and therefore only one available filtered view. Working to the assumption that this won't change (and I accept that this may well be the only option) I'm trying to come up with a solution that is sustainable. Without solving this issue, the amount of CT's I'd need to create would be very large and unmaintanable when my current contract ends and there is no ongoing support for the dept.
I've added a hidden column "Document Set Name" as a shared hidden field in the doc set and a workflow that gets/sets.
My current thinking is that if I could somehow pass the document set name to the filtered view then it would allow me to filter on the indexed hidden column. Resolving the issue on a long term basis.
My questions:
Will I be able to avoid the 5000 limit error by purely putting the FilterField into the url? (I can't test this at the moment and can't find the answer)
If I could use that url, how would I go about updating the lists to pass the parameter (presumably by some jslink customisation)
Aside from redesigning the library's (which I don't want to do) am I missing any obvious solutions. I want to avoid any html/js customisation that would require ongoing support when new elements are added (lookup references to projects, programs, etc).
