Pickers should allow for server-side content filtering, not just client-side greying out

[benjaminc]

Currently when you open a picker, such as a content picker or media picker, you can pass a "filter" property on the editor options. This filter property can be a string (which is a comma-separated list of doc type, optionally prefixed by a ! meaning to exclude rather than include those), or it can be an object or function for more advanced filtering. However all that filtering is applied on the client, after paged results are returned from the server, meaning that if you want them to pick specific doc types, they have to manually wade through any not-allowed doc types to find the ones they are allowed to pick. There are certainly use cases for this behavior, such as when the doc type they are allowed to pick might be a child of a doc type they aren't allowed to pick. However, I think there are also use cases where it would be a better user experience if they didn't see documents of types that the developer didn't want them to see.

My proposal would be to keep the existing filtering functionality in place, but add a new property called "limitByContentType", or something like that. This new property would be passed to the umbTreeSearchBox and umbMiniListView directives on the treepicker control, and those directives would in turn pass it to the entityResource.search calls and entityResource.getPagedChildren calls that those directives make. The corresponding EntityController methods would then use this new property to limit the content types that appear in the result sets. Since this limiting is done server side, the paging would still behave as expected by the client, and users would see empty pages or pages with fewer results, like you might get if you tried to do the limiting on the client side.

The developer could then use both the filter and limitByContentType attributes, either separately or in conjunction with each other, to make sure the content editors have the best experience.

Note that to limit the scope of the changes, I am proposing only the code (C# and JS) changes required to enable this feature, allowing developers to use this new functionality. I am not proposing adding new configuration values to the built-in property editors that also use the treepicker, either directly or indirectly, which would allow the those property editors to use this new functionality as well. I'm not opposed to adding new configuration values to the for the built-in property editors, however I think that would be better handled in a separate feature request as it adds scope and complexity to what is needed for this feature to be available to developers who write custom property editors that use the treepicker control.