Bug 32499 - HOLDPLACED email goes to patron branch rather than item branch
Summary: HOLDPLACED email goes to patron branch rather than item branch
Status: REOPENED
Alias: None
Product: Koha
Classification: Unclassified
Component: Circulation (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-19 22:57 UTC by David Cook
Modified: 2023-04-02 23:50 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2022-12-19 22:57:51 UTC
The HOLDPLACED email is sent out if "emailLibrarianWhenHoldIsPlaced" is enabled. 

Currently, it is sent to the patron's branch, but it seems to me (and my librarians) that it would make more sense to be emailed to the item's branch, since that's the branch where the librarian is going to be able to do something about it.
Comment 1 Katrin Fischer 2022-12-19 23:21:17 UTC
What if there are multiple items from several branches?
Comment 2 Katrin Fischer 2022-12-19 23:26:18 UTC
Maybe pick-up library could be an alternative? But I get a feeling that this might need a configuration option.
Comment 3 David Cook 2022-12-20 00:59:54 UTC
(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
Comment 4 David Cook 2022-12-20 01:02:05 UTC
(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.
Comment 5 Katrin Fischer 2022-12-20 09:12:09 UTC
(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.
Comment 6 David Cook 2022-12-20 22:35:56 UTC
(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...
Comment 7 Katrin Fischer 2022-12-27 21:53:29 UTC
(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.
Comment 8 David Cook 2023-01-02 22:24:29 UTC
(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.
Comment 9 Marie-Luce Laflamme 2023-03-24 14:45:37 UTC
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?
Comment 10 Katrin Fischer 2023-03-24 18:23:57 UTC
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.
Comment 11 Marie-Luce Laflamme 2023-03-31 15:34:22 UTC
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?
Comment 12 David Cook 2023-04-02 23:50:34 UTC
(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.