At the moment there is no way for the library to have a look at the list of serials that have routing lists attach. A search option or checkbox for this would be a nice addition.
This is for the advanced search form in the serials module: https://staff.next.bsz-bw.de/cgi-bin/koha/serials/serials-home.pl We'd like to have an option there to filter on subscriptions that are linked to a routing list. This could be realized as a checkbox or similar.
Created attachment 160094 [details] [review] Bug 26567 WIP
Created attachment 160095 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
Tested this and the search does return results. I added 7 patrons to a routing list for one serial. When I search the serials, I didn't fill out any fields but checked the routing list box. The search results are unexpected. My serial was listed 7 times. I would have expected only one search result because only one serial had a routing list Is this search supposed to return serial titles with a routing list? If this is the case, there should have only been one search result. Or is the search intended to list patrons on a routing list and the associated title? If this is the case, the patron name should have be included in the table of search results.
Hi Esther, thanks for testing! The subscription should only appear once in the list as we only want to check for "has a routing list". We'll also be needing unit tests for the change in SearchSubscriptions. I am also pondering if we should rename the search option... Maybe: "Has routing list"? This could make it clearer that we are not looking for routing lists, but for subscriptions still.
Created attachment 161617 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
Created attachment 161618 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Have fixed the bug where multiple results were showing for one subscription, have done testing with subscriptions that have differing numbers of patrons added to the routing list. Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
An error occured when trying to add two or more patrons to the routing list. Error trace C4::Serials::addroutingmember(): DBI Exception: DBD::mysql::st execute failed: Duplicate entry '2-19' for key 'subscriptionid' at /kohadevbox/koha/serials/routing.pl line 69 at /usr/share/perl5/DBIx/Class/Exception.pm line 77
I'll take it back. I'll verified it without the patch, this error has nothing to do with the patch.
Created attachment 161718 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists unit tests have now been written for the SearchSubscription subroutine. Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg
Created attachment 161750 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Adds a search option to the advanced search in the serials module that allows to limit search on subscriptions with routing lists. Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to 5. Run unit tests: prove t/db_dependent/Serials.t Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Perltidied changes to make QA test tools pass.
Created attachment 161751 [details] [review] Bug 26567: (follow-up) Update label and add check for RoutingSerials The system preference RoutingSerials controls if the routing list feature is available in the staff interface or not. If routing lists are deactivated, the search option should not show. Also updated the label to read: "Has routing list" Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
q| INNER JOIN (SELECT DISTINCT subscriptionid FROM subscriptionroutinglist) srl ON srl.subscriptionid = subscription.subscriptionid|; This looks a bit odd? Couldnt you LEFT JOIN subscriptionroutinglist AND GROUP BY subscriptionid and WHERE srl.subscriptionid IS NOT NULL ? Or without a GROUP BY something like: LEFT JOIN subscriptionroutinglist srl ON srl.routingid = ( SELECT routingid FROM subscriptionroutinglist WHERE srl.subscriptionid=subscription.subscriptionid LIMIT 1 )
Isn't in Discussion a bit harsh for a question? ;) Can you explain why the group or limit 1 is better than using a distinct?
(In reply to Katrin Fischer from comment #14) > Isn't in Discussion a bit harsh for a question? ;) > > Can you explain why the group or limit 1 is better than using a distinct? Isnt Failed QA a bit hard too? lol. Had no reason to fail here. Counter question: q| INNER JOIN (SELECT DISTINCT subscriptionid FROM subscriptionroutinglist) srl ON srl.subscriptionid = subscription.subscriptionid|; Doesnt this looks a bit odd? Joining a subselect. Probably we c/should compare performance on the various constructs. But I gladly get a response from the author of doing that all by myself ;)
(In reply to Marcel de Rooy from comment #15) > (In reply to Katrin Fischer from comment #14) > > Isn't in Discussion a bit harsh for a question? ;) > > > > Can you explain why the group or limit 1 is better than using a distinct? > > Isnt Failed QA a bit hard too? lol. Had no reason to fail here. > > Counter question: > q| INNER JOIN (SELECT DISTINCT subscriptionid FROM subscriptionroutinglist) > srl ON srl.subscriptionid = subscription.subscriptionid|; > > Doesnt this looks a bit odd? Joining a subselect. Probably we c/should > compare performance on the various constructs. But I gladly get a response > from the author of doing that all by myself ;) You will have to deal with me I am afraid. Our sponsorship for this has run out.
What construct would you prefer? I can try and provide a follow-up.
(In reply to Katrin Fischer from comment #17) > What construct would you prefer? I can try and provide a follow-up. Hi Marcel, did you have another chance to take a look yet?
(In reply to Katrin Fischer from comment #18) > (In reply to Katrin Fischer from comment #17) > > What construct would you prefer? I can try and provide a follow-up. > > Hi Marcel, did you have another chance to take a look yet? On my list still, thx for your attention :)
Created attachment 166489 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Adds a search option to the advanced search in the serials module that allows to limit search on subscriptions with routing lists. Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to 5. Run unit tests: prove t/db_dependent/Serials.t Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Perltidied changes to make QA test tools pass.
Created attachment 166490 [details] [review] Bug 26567: (follow-up) Update label and add check for RoutingSerials The system preference RoutingSerials controls if the routing list feature is available in the staff interface or not. If routing lists are deactivated, the search option should not show. Also updated the label to read: "Has routing list" Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Created attachment 166491 [details] [review] Bug 26567: Allow to limit subscription search to subscriptions with routing lists Adds a search option to the advanced search in the serials module that allows to limit search on subscriptions with routing lists. Test plan: 1. Apply this patch 2. Create two subscriptions, one with a routing list and one without 3. Navigate to Serials home and tick the checkbox labeled "Search routing lists only:" 4. Confirm that the only search result to appear is the subscription you added the routing list to 5. Run unit tests: prove t/db_dependent/Serials.t Sponsored by: Bibliotheksservice-Zentrum Baden-Wuerttemberg Signed-off-by: Christian Stelzenmüller <christian.stelzenmueller@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Perltidied changes to make QA test tools pass. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 166492 [details] [review] Bug 26567: (follow-up) Update label and add check for RoutingSerials The system preference RoutingSerials controls if the routing list feature is available in the staff interface or not. If routing lists are deactivated, the search option should not show. Also updated the label to read: "Has routing list" Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Katrin Fischer from comment #16) > (In reply to Marcel de Rooy from comment #15) > > (In reply to Katrin Fischer from comment #14) > > > Isn't in Discussion a bit harsh for a question? ;) > > > > > > Can you explain why the group or limit 1 is better than using a distinct? > > > > Isnt Failed QA a bit hard too? lol. Had no reason to fail here. > > > > Counter question: > > q| INNER JOIN (SELECT DISTINCT subscriptionid FROM subscriptionroutinglist) > > srl ON srl.subscriptionid = subscription.subscriptionid|; > > > > Doesnt this looks a bit odd? Joining a subselect. Probably we c/should > > compare performance on the various constructs. But I gladly get a response > > from the author of doing that all by myself ;) > > You will have to deal with me I am afraid. Our sponsorship for this has run > out. Still do not really like the construct, but have no formal argument. Running out of sponsorship as a reason for not replying does not sound good to me btw. The author has a moral obligation too. Welcome to open source.
Pushed for 24.05! Well done everyone, thank you!
(In reply to Marcel de Rooy from comment #24) > (In reply to Katrin Fischer from comment #16) > > (In reply to Marcel de Rooy from comment #15) > > > (In reply to Katrin Fischer from comment #14) > > > > Isn't in Discussion a bit harsh for a question? ;) > > > > > > > > Can you explain why the group or limit 1 is better than using a distinct? > > > > > > Isnt Failed QA a bit hard too? lol. Had no reason to fail here. > > > > > > Counter question: > > > q| INNER JOIN (SELECT DISTINCT subscriptionid FROM subscriptionroutinglist) > > > srl ON srl.subscriptionid = subscription.subscriptionid|; > > > > > > Doesnt this looks a bit odd? Joining a subselect. Probably we c/should > > > compare performance on the various constructs. But I gladly get a response > > > from the author of doing that all by myself ;) > > > > You will have to deal with me I am afraid. Our sponsorship for this has run > > out. > > Still do not really like the construct, but have no formal argument. > Running out of sponsorship as a reason for not replying does not sound good > to me btw. The author has a moral obligation too. Welcome to open source. This comment was unnecessary.
Not backported to 23.11.x