Custom Error Messages for Circ/Hold Matrix Matchpoints
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
Bug 1481441 (https:/
I would suggest structuring it this way (basic circ example, assumes a bit of familiarity with the matrix_matchpoint functions, sorry):
If result.circulate is null and the current matchpoint defines circulate = false and custom_
If result.circulate is already set to false and result.custom_error is null, failure reporting takes place the same as it does now (fail_part, age_protection, ils_event, etc.) Basically only the most heavily weighted matchpoint that first defines the circulate field in the result is allowed to also define custom_error.
I wouldn't advocate for returning multiple custom_error fields, but if it's desired, I'd concatenate them to prevent having to manipulate arrays in single row returns, or having to return multiple rows from the find_(circ|
I haven't started working on this yet and I wanted to see what kind of opinions there are about it before wading in too deep. (Also, if I'm not making sense, now is a good time to tell me that so I can try to explain it again.)
description: | updated |
tags: | added: circ-holds usability |
tags: | added: ux-error-messages |
Changed in evergreen: | |
status: | New → Confirmed |
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. holdable" anyway.
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/
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.