Comment 13 for bug 677074

I see where you are coming from, and I think that would work wonderfully in a small system with one or two libraries.

I don't think it would scale to 5, 10, 25, 50, 100, 200, or more libraries easily, especially as you have included a weighting to begin with. Your proposal would walk up the org tree, which means that the org tree has just become weighted, ignoring all else in the process.

That is the kind of weighting I want to get rid of, and both permission group and org unit do that without my patch.

Speaking of walking up the org tree, there are a number of trees involved in the matchpoints, and my patch will add one more to the circ matchpoints.

Ignoring holds for the moment, circ has or will have:
The "Context" OU, where the circ is happening
The Copy Owning Library, where the call number is located
The Copy Circ Library, where the item circulates from
The User Home Library, where the user is based
The User's Permission group, as assigned in the user profile

Each of those can match a rule exactly or by being a parent to the actual value. More than one can be set, and they may match differently. Static ordering can't easily take into account distance on those values, especially if they refer to a different part of the trees than the library owning the rules. Walking up all the trees would be very difficult to do code-wise for static ordering, and thus you have to pick and choose which trees to walk up first or only pick certain trees to walk up (and in what order). This is, again, partially how the current code works, walking up the permission tree and then the org tree. Copy owning and circ libraries are considered equally, but walked up together in a way.

All of this amounts to something being weighted before static numbering comes into play, unless I have overlooked something about how static numbering would allow for all of this to be accounted for without driving an admin or set of admins insane.