Comment 7 for bug 1781480

Hi Kathy,

I'll use your (great) example consortium and theoretical location group.

The decision to make the behavior different came down to the fact that location groups are collections of copy locations that are not necessarily related in a hierarchical way, and are not limited to a single "context" value the way that the site() filter is. In your example, the contents of the group spans three branches and two systems. It's unclear in the example is who owns the academic-themed group, but I'll posit that the top org unit owns the group for our purposes here.

Looking at things from the layer closest to the data, there are basically four choices when it comes to asking who's badges to show when we have a location_groups() filter but no site() filter:

 1) The badges belonging to the owners of the location groups requested via the location_groups() filter. This is what we do today.
 2) My suggested change, which was to include badges belonging to the ancestors of the group owners as well, though in this example that wouldn't make a difference because the top org unit owns the group.
 3) The badges belonging to the owners of the copy locations /within/ the groups requested.
 4) The badges belonging to the owners of the copy locations, as in (3), along with their ancestors. This would pull in badges from all the academic libraries, the systems, and the top of the tree.

Adjusting the example a little to consider a "Children's materials" group in a large public consortium, (4) could very well pull (basically) duplicated badges from /all/ libraries in a consortium. Maybe that's fine.

I'm fine with changing the location-group-search badge scoping to any of 2-4, or leaving it at 1. The nice thing about 1 is that one does have the ability, through configuration of badges at specific org units matching group owners, to control what is displayed more directly, but that may not be useful or necessary in practice.

Thanks, Kathy!