Comment 15 for bug 677074

I can't think of a good way to answer them separately without putting a hard-coded weighting in place somewhere or introducing administrative headaches.

If we ask "which org unit's policies apply?" then we may be limiting ourselves to weighting on org units.

If we ask "which permission group's policies apply?" then we may be limiting ourselves to weighting on permission groups.

If we remove some checks from the circ matchpoint table and instead place them in a rules table we are calling those checks less important, across the board, than the checks left in the circ matchpoint table.

I am willing to think about alternate ways of doing it, but I can't think of a decent way that doesn't put more emphasis on some pieces compared to others.

The entire goal of this patch is to ensure that any given consortium, or even any given library system or branch, can decide for themselves what fields in the matchpoint tables are most important to them.

I know there are some groups that consider the user's home library to be more important than their permission group or the current checkout location, for example. Others may think the owning or circ library should trump when possible because the library who owns the item should be the one deciding the policies on it going out.

If you look at some of the commented out portions of the patch you may notice I even have commented out code for making the permission group and org unit pieces optional as well. I wanted to make sure that if someone wanted to do that they had the code in front of them, rather than having to adapt other parts of the function, even if those two being optional may not work out right now in the base code. Some minor schema/IDL changes (I should document those) could make it so that permissions are based on the user home library field instead of the checkout location, for example, for those consortia that put more weight on that.