Comment 1 for bug 1576754

Revision history for this message
Thomas Berezansky (tsbere) wrote :

I had some thoughts on doing something similar to this. My method was, however, going to be allowing custom failure codes (and removing the current script-based mappings to split up some combined ones). My main headache was defining those codes for use as all the descriptions and such currently live in the filesystem, not the database.

Overall, my thought was:

1. Add a "error code" field that, if circulate/holdable = false will be the failure reason. As we already return one *or more* rows we don't have to do much there. I was hoping to have this be a FK to a table containing code and description so they could be custom-defined.
2. Add a "override context" field that defines where the override permission for the error code needs to be granted at. I was thinking this would be a fixed list of values, such as "Context OU", "Item Owning OU", "Item Circ OU", "Patron Home OU".
3. Teach the find function to stop adding error codes/context locations when circulate/holdable would have been "true" (when fallthrough is involved, anyway) as beyond that point the answer would have been "yes, the item is circulatable/holdable" anyway.
4. Teach the circulation code to look for those codes and use them instead of just "the circ matrix said no" (which I would have as the default code when none is specified by a rule as that is what the current circulation code assumes anyway).

Note that we already return an array of matching rule IDs from find_circ_matrix_matchpoint, returning a matching array of failure codes/context location identifiers would be trivial (push nulls on for rows that don't have circulate set to false). And as I believe the circ/hold test functions return one or more rows already *anyway* we can iterate over the array(s) with the various reasons that came up.

A benefit of my method is that the list of reasons is better defined. A downside is that someone has to define a reason before it can be used.

I feel that the biggest benefit my method has is allowing custom override permissions to come into play. For example: "Local Use Only patrons can only check out items belonging to their library" could be set to be overridden by staff for their library's items but not for another library's items.