| 2016-04-29 15:27:47 |
Jason Boyer |
description |
Bug 1481441 (https://bugs.launchpad.net/evergreen/+bug/1481441) calls attention to the fact that it is difficult to determine the actual reason that a hold was not placed or a circ not allowed. I believe this could be fixed by adding a custom_error field to both config.circ_matrix_matchpoint and config.hold_matrix_matchpoint, and including it in the output of the find_*_matrix_matchpoint functions for each.
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_error='Limited Access Accounts aren't permitted to circulate R-Rated DVDs' then both the circulate and custom_error fields are copied into the result, with the custom_error text eventually reaching the staff client (or opac for holds, etc.)
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|hold)_matrix_matchpoint calls. Also, if multiple error messages are desired special care has to be taken to stop 'catting the error messages after a matchpoint defines circulate=true, even if result.circulate is false or it will be confusing to users and staff.
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.) |
Bug 1481441 (https://bugs.launchpad.net/evergreen/+bug/1481441) calls attention to the fact that it is difficult to determine the actual reason that a hold was not placed (staff have similar issues when a circ is not allowed). I believe this could be fixed by adding a custom_error field to both config.circ_matrix_matchpoint and config.hold_matrix_matchpoint, and including it in the output of the find_*_matrix_matchpoint functions for each.
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_error='Limited Access Accounts aren't permitted to circulate R-Rated DVDs' then both the circulate and custom_error fields are copied into the result, with the custom_error text eventually reaching the staff client (or opac for holds, etc.)
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|hold)_matrix_matchpoint calls. Also, if multiple error messages are desired special care has to be taken to stop 'catting the error messages after a matchpoint defines circulate=true, even if result.circulate is false or it will be confusing to users and staff.
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.) |
|
