Bug 26925

Summary: Pickup library list should be in alphabetical order
Product: Koha Reporter: Andrew Fuerste-Henry <andrew>
Component: Hold requestsAssignee: Nick Clemens (kidclamp) <nick>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: gmcharlt, jonathan.druart, kyle
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Bug 26925: Sort pickup locations for biblio
Bug 26925: Sort pickup locations for biblio
Bug 26925: Sort pickup locations for biblio

Description Andrew Fuerste-Henry 2020-11-04 13:44:05 UTC
When we fetch the list of valid pickup locations for placing a hold on the staff client, we grab a separate list of valid locations for each item on that bib, put each of those sub-lists in alphabetical order, and then string them together. We need to alphabetize the entire list at the end.
Comment 1 Nick Clemens (kidclamp) 2020-11-04 14:24:45 UTC
Created attachment 112995 [details] [review]
Bug 26925: Sort pickup locations for biblio

Currently we fetch the pickup locations for each item on the biblio, then
we remove duplicates. Each items locations are sorted alphabetically, however, we don't
ensure the final list is ordered

To test:
1 - Find a title with items from two different libraries
2 - Create two library groups and select 'is local hold group'
3 - Place the libraries of the items in separate groups with differing libraries
4 - Attempt to place a hold for the title in the staff client
5 - Note the "Pickup at" list is not in alphabetical order
6 - Apply patch
7 - Restart all and reload
8 - Pickup locations are now sorted correctly
Comment 2 Andrew Fuerste-Henry 2020-11-04 15:08:12 UTC
Created attachment 113005 [details] [review]
Bug 26925: Sort pickup locations for biblio

Currently we fetch the pickup locations for each item on the biblio, then
we remove duplicates. Each items locations are sorted alphabetically, however, we don't
ensure the final list is ordered

To test:
1 - Find a title with items from two different libraries
2 - Create two library groups and select 'is local hold group'
3 - Place the libraries of the items in separate groups with differing libraries
4 - Attempt to place a hold for the title in the staff client
5 - Note the "Pickup at" list is not in alphabetical order
6 - Apply patch
7 - Restart all and reload
8 - Pickup locations are now sorted correctly

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Comment 3 Andrew Fuerste-Henry 2020-11-04 15:37:08 UTC
Oh, missing a step in the test plan. One must set one's hold pickup branch policy to Item's Hold Group.
Comment 4 Andrew Fuerste-Henry 2020-11-04 15:46:58 UTC
a jQuery bandaid in the meantime:

if ( $('#circ_request').length ) {
    var select = $('#pickup');
    select.html(select.find('option').sort(function(x, y) {
      return $(x).text() > $(y).text() ? 1 : -1;
    }));
}
Comment 5 Andrew Fuerste-Henry 2020-11-04 21:04:18 UTC
Created attachment 113017 [details] [review]
Bug 26925: Sort pickup locations for biblio

Currently we fetch the pickup locations for each item on the biblio, then
we remove duplicates. Each items locations are sorted alphabetically, however, we don't
ensure the final list is ordered

To test:
1 - Find a title with items from two different libraries
2 - Create two library groups and select 'is local hold group'
3 - Place the libraries of the items in separate groups with differing libraries
4 - Attempt to place a hold for the title in the staff client
5 - Note the "Pickup at" list is not in alphabetical order
6 - Apply patch
7 - Restart all and reload
8 - Pickup locations are now sorted correctly

Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>

Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Comment 6 Katrin Fischer 2021-01-03 14:52:29 UTC
Patch no longer applies, please rebase!
Comment 7 Nick Clemens (kidclamp) 2021-05-05 18:55:01 UTC

*** This bug has been marked as a duplicate of bug 28202 ***