Summary: | HOLDPLACED email goes to patron branch rather than item branch | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Circulation | Assignee: | Bugs List <koha-bugs> |
Status: | REOPENED --- | QA Contact: | Testopia <testopia> |
Severity: | minor | ||
Priority: | P5 - low | CC: | gmcharlt, kyle.m.hall, marie-luce.laflamme |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26477 | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
David Cook
2022-12-19 22:57:51 UTC
What if there are multiple items from several branches? Maybe pick-up library could be an alternative? But I get a feeling that this might need a configuration option. (In reply to Katrin Fischer from comment #1) > What if there are multiple items from several branches? I think one email goes out per item but interesting point (In reply to Katrin Fischer from comment #2) > Maybe pick-up library could be an alternative? But I get a feeling that this > might need a configuration option. I thought about pick-up library, but that might still be the patron's library, rather than the library that actually holds the item. Yeah, I thought about getting it to obey CircControl, but "the library you are logged in at" is a bit problematic. I don't love relying on global variables and there would be no easy way to pass it in. -- I was thinking the current behaviour has been around for many years, so configuration option probably makes sense. (In reply to David Cook from comment #3) > (In reply to Katrin Fischer from comment #1) > > What if there are multiple items from several branches? > > I think one email goes out per item but interesting point I think the idea about patron library is that one library can take care of the hold process - seeing who needs to get contacted, what you might want to recall (not quite there yet I think), etc. Sending to multiple does seem more prone to create chaos. (In reply to Katrin Fischer from comment #5) > (In reply to David Cook from comment #3) > > (In reply to Katrin Fischer from comment #1) > > > What if there are multiple items from several branches? > > > > I think one email goes out per item but interesting point > > I think the idea about patron library is that one library can take care of > the hold process - seeing who needs to get contacted, what you might want to > recall (not quite there yet I think), etc. Sending to multiple does seem > more prone to create chaos. But wouldn't the email be going to the library that holds the item, so they'd just need to be concerned about their own holdings? I admit I don't know why folk would want "emailLibrarianWhenHoldIsPlaced" enabled. For a busy library, it would be information overload. For a small library, I suppose it could allow for quick action on holds... (In reply to David Cook from comment #6) > (In reply to Katrin Fischer from comment #5) > > (In reply to David Cook from comment #3) > > > (In reply to Katrin Fischer from comment #1) > > > > What if there are multiple items from several branches? > > > > > > I think one email goes out per item but interesting point > > > > I think the idea about patron library is that one library can take care of > > the hold process - seeing who needs to get contacted, what you might want to > > recall (not quite there yet I think), etc. Sending to multiple does seem > > more prone to create chaos. > > But wouldn't the email be going to the library that holds the item, so > they'd just need to be concerned about their own holdings? But if you have 10 libraries owning the same item, which can well happen with popular ones, you will have 10 librarians potentially running to the shelf to get it... doesn't seem very effective. I was assuming the worst case: record level hold with multiple branches holding it. (In reply to Katrin Fischer from comment #7) > But if you have 10 libraries owning the same item, which can well happen > with popular ones, you will have 10 librarians potentially running to the > shelf to get it... doesn't seem very effective. > > I was assuming the worst case: record level hold with multiple branches > holding it. Ahhh yes that would explain it. I forgot that not all holds are item-level holds. Since a hold could be either record-level or item-level, I don't think there's a consistent way of handling the email except emailing the patron's branch. Maybe the pickup library like you suggested before, but the current behaviour has been around for many years, and I think you've explained well why that's the case here. Would the transport cost matrix help? This feature normally predict where holds are filled from. Is there a way it could select where to send the email? The cost matrix is optional, item allocation for holds can be random, static, branch transfer rule driven, cost matrix driven etc. maybe the method used for filling the holds queue could be used somehow, but it would probably be a bigger code change and as some libraries run the jobs only a few times a day, then it would not be an immediate notification. Some of our large medical library clients are rarely dealing with hold requests, and when they do, it’s mainly to request specialized items from a different branch. In this case, it would be ideal if Koha could send the email to the item’s library. But, the question is: how to deal with record level holds? (In reply to Marie-Luce Laflamme from comment #11) > Some of our large medical library clients are rarely dealing with hold > requests, and when they do, it’s mainly to request specialized items from a > different branch. In this case, it would be ideal if Koha could send the > email to the item’s library. But, the question is: how to deal with record > level holds? I think that you'd have to email every library that holds the item, but you'd probably need a different email template, which would say something along the lines of "This patron has placed a record-level hold on this record. All libraries with an item are being contacted to see if they can make this item available for the patron." We have medical libraries who are also interested in this. Just wanted to point out that this issue is still happening in version 23.05+ and the master branch. Maybe adding a new system preference to control where emails are sent could be a great solution. One idea could be that for item-level holds, the email goes to the specific library, while for record-level holds, as David suggested, it could be sent to every library that holds the item, ensuring that no hold request is left out. It would make a big difference for our medical libraries. Thanks for considering this! |