Comment 9 for bug 925776

Dan, I like your idea. As an added bonus, we can simply switch on/off the #staff modifier based on that checkbox instead of based on whether we detect that we're running inside XULRunner. Should be a simple switch.

As for whether located uris are acting properly in this context, that's a sticky question, really. The idea of them is to act almost like copies, but not quite. Consider:

 * scoping on copies should show you records /at or under/ you ranged scope. That is, it's simply broadening the cone through which you're looking
 * scoping on located URIs, however, should show you records that you're /authorized/ to see based on the ranged scope. That is /only when your cone (ranged scope) is small enough to confirm(ish) your authorization/ and not broader. Stated differently, where your ranged scope is contained within the at-or-below list of the OU of the located URI.

So, a consortium-scoped search shouldn't show system or branch scoped located URIs, but a branch scoped search /should/ ... I hope that doesn't muddy the waters...

The tests are (in practice, essentially) the same, but parameters are reversed.

Dan's proposed checkbox (at least, based on my interpretation and implementation proposal) would be a great first step in making this work well for most (if not all) workflows, I think. Having a (maybe staff only) "restrict based on located uri" checkbox might get us all the way there, assuming the logic above is sound, and indeed implemented that way (now or in the future).

--miker