Okay, its pretty easy to tell I’m in the middle of an implementation. I’m finding a whole bunch of little issues and I tend to write a quick not about them here on the blog. It is both useful for me, as it helps me to remember and I hope helpful to you as well.
I’m doing some work around my search scopes. They are funky little guys and have many different facets to them in order for them to work correctly. Things of note:
- Usage Keywords – If you’re building a search scope for general consumption you can use the BasicUI keyword however, for ones that are selectively viewed, you will need to use custom keywords. To make the search scope visible to the selected users, create a set of users who can see it and a set of search scopes that contain the usage keyword. Then create an MPR to give read permission to the search scopes to the set of users who need access.
- Non-Administrative Search Filters – I built out the search filter and it works great but my users complain that its returning incorrect information. You go and find they’re right (and you hate when they are) so you have to fix it. Generally if you look at the attributes in the search scope, you need to remember that you have to add them to the non-administrative search filter. They don’t have administrative rights like your account that the scopes were made with (and most likely tested with too!).
Addendum – September 01
- Read Permissions – Doh! How could I forget this one. If you’ve not granted at least read permissions to the attributes in the search scope, the results may surprise you. (For example, I had an attribute that couldn’t be read and instead of returning no results, the search returned all the objects in that resource type!)