Bug 38122

Summary: Cannot sort holdings table by status
Product: Koha Reporter: Lucas Gass (lukeg) <lucas>
Component: CirculationAssignee: Bugs List <koha-bugs>
Status: In Discussion --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: baptiste.wojtkowski, bowens, bwsdonna, bywater, chlee, gmcharlt, hammat.wele, hattara, jonathan.druart, kbecker, kebliss, kkrueger, koha, kyle, marie-luce.laflamme, mathsabypro, mnero, mreid, mspinney, nick, p50226253, rcoert, sam.sowanick, sbcornell, sspohn, tom.rice
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37334
GIT URL: Initiative type: ---
Sponsorship status: --- Crowdfunding goal: 0
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Bug Depends on: 37334, 33568    
Bug Blocks:    
Attachments: Bug 38122: Add the ability to group holdings by status
Bug 38122: Sort holdings table by status
Bug 38122: (follow-up) Fix grouping of holdings by status when sorting
Bug 38122: (follow-up) Make "Group by status" and "Ungroup by status" translatable

Description Lucas Gass (lukeg) 2024-10-08 14:50:02 UTC
Bug 37334 will bring filtering to the holdings table status column. This bug is for the sorting of the status column.
Comment 1 Kristi Krueger 2024-10-31 15:17:48 UTC
Our staff are anxious to have this restored! They use the sort on bibs that have more than 20 items, some that have over 100.
Comment 2 Nick Clemens (kidclamp) 2024-11-07 15:45:43 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2024-11-07 16:01:13 UTC
(In reply to Kristi from comment #1)
> Our staff are anxious to have this restored! They use the sort on bibs that
> have more than 20 items, some that have over 100.

Can you detail your use case please?
Comment 4 Kristi Krueger 2024-11-08 14:41:19 UTC
We have several use cases:

1.Branch staff sort by status to see if they can identify an available copy and the branch it’s located at.

2. Our acquisitions team uses it to see how many viable (not missing, lost, withdrawn) copies are left on something that has high holds. Popular titles can have over 100 items.

3. Technical services uses it when looking at items that need to be called in to see if they are checked out, marked missing, etc.

4. We have wi-fi hotspots that are very popular and have several hundred items on the bib for each model. A lot of them are marked damaged, others are long overdue (Lost), some are Missing. These different statuses can make it confusing to know what should be circulating, so our staff use the status sort to eye up what is damaged, missing, etc.
Comment 5 Jonathan Druart 2024-11-13 10:12:01 UTC
Don't you think bug 37334 would help in most of those situations?
Comment 6 Kristi Krueger 2024-11-13 13:58:47 UTC
For use cases 1 and 2 especially, the sort rather than the filter would be the preferred method.
Comment 7 SamSowanick 2024-11-25 18:21:23 UTC
Our staff would love this feature back too. They find it easier to quickly scan the items over filtering. But ideally there is room for both :). Upvoting.
Comment 8 Jonathan Druart 2024-11-26 08:36:47 UTC
I prefer to be honest with you, there is very little chance to see the sort implemented in a near future. It was an limitation of bug 33568 that has been announced since day 1.

I will do my best to provide alternative solutions that can potentially answer your needs however.

(In reply to SamSowanick from comment #7)
> They find it easier to quickly scan the items over filtering.

Can you detail what you mean here please?
Comment 9 SamSowanick 2024-11-26 18:49:02 UTC
The sort function is a way to group the items allowing scanning over all the items at one time, allowing seeing proportions of items status on one bib. Filtering accomplishes this but requires you to know what status you are looking for; while also hiding other items not in the searched status.

I also just realized that you can SHIFT + CLICK to sort two fields at the same time, so it is fully possible that I am missing an alternate something.

I will see if I can get more context from our staff.

Thank you for highlighting the context to the limitations for this bug.
Comment 10 Donna 2024-12-19 20:47:57 UTC
Sorry - I'm not fluent in all the tech stuff, so it might be something obvious.  But if all the other columns on the holdings table are sortable, why is status the only one that is not?
Comment 11 Jonathan Druart 2025-01-06 10:23:26 UTC
(In reply to Donna from comment #10)
> Sorry - I'm not fluent in all the tech stuff, so it might be something
> obvious.  But if all the other columns on the holdings table are sortable,
> why is status the only one that is not?

Because it's calculated, not stored in DB like other attributes.

If you want to sort by status you will need to calculate the status for all the items then display the 20 you want to display.
Comment 12 Lucas Gass (lukeg) 2025-01-13 21:38:53 UTC
(In reply to Jonathan Druart from comment #8)
> I prefer to be honest with you, there is very little chance to see the sort
> implemented in a near future. It was an limitation of bug 33568 that has
> been announced since day 1.


Unfortunately this is not an option. Before Bug 33568 one could sort by statuses, this is a regression and many libraries cannot live without it.
Comment 13 Lucas Gass (lukeg) 2025-01-13 21:39:43 UTC
I can work on this after we get Bug 37334 pushed.
Comment 14 Jonathan Druart 2025-01-14 05:04:47 UTC
(In reply to Lucas Gass (lukeg) from comment #13)
> I can work on this after we get Bug 37334 pushed.

What are you plans?
Comment 15 Marie-Luce Laflamme 2025-01-14 17:28:16 UTC
Please bring back the "sort by statuses" option.
Comment 16 mreid 2025-01-22 20:22:32 UTC
Please restore ability to sort the holdings table by status. This is particularly an issue for our bibs with large holdings (up to 150 items) across multiple branches. Staff appreciated being able to sort by status to quickly eyeball the list and determine which branch has available items; we also have use cases similar to those listed by Kristi on 11/8/24, particularly with our hotspots and laptops.
Comment 17 Lucas Gass (lukeg) 2025-01-22 20:58:13 UTC
(In reply to mreid from comment #16)
> Please restore ability to sort the holdings table by status. This is
> particularly an issue for our bibs with large holdings (up to 150 items)
> across multiple branches. Staff appreciated being able to sort by status to
> quickly eyeball the list and determine which branch has available items; we
> also have use cases similar to those listed by Kristi on 11/8/24,
> particularly with our hotspots and laptops.

Have a look at Bug 37334. Filtering by available and then sorting by branch may solve your problem.
Comment 18 Kristi Krueger 2025-06-03 17:40:50 UTC
While filtering will be welcome, sorting is needed when staff are reviewing more than one status at a time. For example, to see how many copies on a bib are checked out or available to determine how many "live" copies there are as opposed to missing, damaged, etc.

Our branch staff were accustomed to using the sort and continue to ask when this functionality will be restored.
Comment 19 Emily Lamancusa (emlam) 2025-06-27 13:17:55 UTC
*** Bug 39921 has been marked as a duplicate of this bug. ***
Comment 20 Jonathan Druart 2025-07-04 10:10:15 UTC
Created attachment 183789 [details] [review]
Bug 38122: Add the ability to group holdings by status

This is a quite ugly solution, but that may answer end-user needs.

It add the option the group items by status on the bibliographic record
detail page.

However it will have VERY bad impact on performances for record with a
lot of items, as we are going to determine the status of each items of
the record.
Comment 21 Jonathan Druart 2025-07-04 10:10:31 UTC
Patch for discussion, it is not ready for inclusion.
Comment 22 Lucas Gass (lukeg) 2025-07-15 15:09:19 UTC
Using k-t-d, I tested some performance using the "Group by status" button, I created items with various status's set:

80 items - 1348ms
200 items - 1463ms
500 items - 1995ms
1000 items - 2635ms
Comment 23 Baptiste Wojtkowski (bwoj) 2025-07-16 13:52:57 UTC
Hi,
Is the provided patch supposed to be working or is is just an illustration of what we should do ? I had to tweak a lot to have it working, and I still cannot have it working well I think.

I can provide my changes but there is one point I don't get, why do we order by Id at the end of the group search ? I cannot find the place where it is ordered by group after this.  

> order_by => [ \[ sprintf( "field(me.itemnumber, %s)", join( ', ', map { qq{'$_'} } @item_ids ) ) ] ]
Comment 24 Jonathan Druart 2025-07-17 06:57:38 UTC
(In reply to Baptiste Wojtkowski (bwoj) from comment #23)
> Hi,
> Is the provided patch supposed to be working or is is just an illustration
> of what we should do ? I had to tweak a lot to have it working, and I still
> cannot have it working well I think.

It is supposed to work. Which problems did you face?

> I can provide my changes but there is one point I don't get, why do we order
> by Id at the end of the group search ? I cannot find the place where it is
> ordered by group after this.  
> 
> > order_by => [ \[ sprintf( "field(me.itemnumber, %s)", join( ', ', map { qq{'$_'} } @item_ids ) ) ] ]

We are ordering by itemnumbers, but using the array @item_ids that defines a specific order.
Comment 25 Baptiste Wojtkowski (bwoj) 2025-07-17 09:09:43 UTC Comment hidden (obsolete)
Comment 26 Baptiste Wojtkowski (bwoj) 2025-07-17 09:11:20 UTC Comment hidden (obsolete)
Comment 27 Hammat wele 2025-07-23 12:57:41 UTC
Created attachment 184550 [details] [review]
Bug 38122: Sort holdings table by status

To test:

    1. Apply the patch
    2. Go to a record details page Example: http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=285
    3. Add several items to the record (with different statuses)
    3. Click the Status column header in the holdings table to sort
       ---> items are correctly sorted by status (ascending and descending on repeated clicks)
Comment 28 Jonathan Druart 2025-07-23 13:31:11 UTC
(In reply to Hammat wele from comment #27)
> Created attachment 184550 [details] [review] [review]
> Bug 38122: Sort holdings table by status
> 
> To test:
> 
>     1. Apply the patch
>     2. Go to a record details page Example:
> http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=285
>     3. Add several items to the record (with different statuses)
>     3. Click the Status column header in the holdings table to sort
>        ---> items are correctly sorted by status (ascending and descending
> on repeated clicks)

Please explain because I don't understand what this patch is supposed to do.
Comment 29 Jonathan Druart 2025-07-23 13:45:41 UTC
(In reply to Hammat wele from comment #27)
> Created attachment 184550 [details] [review] [review]
> Bug 38122: Sort holdings table by status

This patch does not work if you don't have all the items display.


Example: I have 223 items, 4 are lost:
Show first 20 items order by desc status:
https://snipboard.io/9HWmp8.jpg (available first)

Show first 20 items order by asc status:
https://snipboard.io/vMmn9b.jpg (available first)

Show all order by desc status (ok)
https://snipboard.io/XZ8uqi.jpg
Comment 30 Jonathan Druart 2025-07-23 13:46:55 UTC
The initial patch is far from perfect and not ready for inclusion (at the minimum tests are missing).

If you want to move this forward I would suggest to first help this first patch being pushed, then we can iterate on top of it.
Comment 31 Jonathan Druart 2025-07-23 13:47:59 UTC
Another problem with sorting by status like you did is that it's going to be translated and the ordering won't make any senses.
Comment 32 Mathieu Saby 2025-09-26 12:13:40 UTC
We are currently upgrading to Koha 24.11 and have discovered this regression. It must be fixed.
Comment 33 Jonathan Druart 2025-09-26 14:42:49 UTC
(In reply to Mathieu Saby from comment #32)
> We are currently upgrading to Koha 24.11 and have discovered this
> regression. It must be fixed.

(In reply to Jonathan Druart from comment #30)
> If you want to move this forward I would suggest to first help this first
> patch being pushed, then we can iterate on top of it.
Comment 34 Hammat wele 2025-10-01 23:57:07 UTC
Created attachment 187227 [details] [review]
Bug 38122: (follow-up) Fix grouping of holdings by status when sorting

When 'Group by status' is enabled, sorting on other columns is ignored to ensure that items remain correctly grouped by status.

To test:

1. Apply the patch
2. Run yarn build
3. Create a record with multiple itemss having different statuses.
4. Click on «Group by status» button
   ---> items are grouped by status
5. Sort on other colunms
   ---> items are still grouped by status
6. Click on «Ungroup by status» button
   ---> items are no more grouped by status
Comment 35 Hammat wele 2025-10-03 16:12:21 UTC
Created attachment 187410 [details] [review]
Bug 38122: (follow-up) Make "Group by status" and "Ungroup by status" translatable
Comment 36 Jonathan Druart 2025-10-07 13:20:10 UTC
*** Bug 40944 has been marked as a duplicate of this bug. ***
Comment 37 Mathieu Saby 2025-10-14 13:09:53 UTC
Is that bug ready to be sign off, or still "in discussion"?
Comment 38 Jonathan Druart 2025-10-14 14:12:22 UTC
(In reply to Mathieu Saby from comment #37)
> Is that bug ready to be sign off, or still "in discussion"?

A first step would be to test the patch and tell us if it works for you.

It's not ready for inclusion yet.
Comment 39 Mathieu Saby 2025-10-15 09:19:08 UTC
I'm testing it out. Two related ideas came to me while playing around with the copy table: 

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41023

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41022
Comment 40 Mathieu Saby 2025-10-19 16:36:35 UTC
I tested on a sandbox, and it seems to work. But honestly, I'm not sure that it really meets the needs of libraries—maybe, maybe not... Other people should test it.

As this is not specified in your test plan, could you please clarify how sorting is supposed to be performed by your patch? Based on the value of "_status" returned by the API? Will "available" items appear first (it seems so from my test)?

From a librarian's point of view, this "grouping" does not seem very different from a "sort", except that you can't reverse the order. But if I understand correctly, it would be really technically complicated to control this feature with an arrow in the column header like for the other columns?
Comment 41 Jonathan Druart 2025-10-20 08:04:21 UTC
(In reply to Mathieu Saby from comment #40)
> I tested on a sandbox, and it seems to work. But honestly, I'm not sure that
> it really meets the needs of libraries—maybe, maybe not... Other people
> should test it.

What are your needs?

> As this is not specified in your test plan, could you please clarify how
> sorting is supposed to be performed by your patch? Based on the value of
> "_status" returned by the API? Will "available" items appear first (it seems
> so from my test)?

available, checked_out, local_use, in_transit, lost, withdrawn, damaged, not_for_loan, on_hold, recalled, in_bundle, restricted

> From a librarian's point of view, this "grouping" does not seem very
> different from a "sort", except that you can't reverse the order. But if I
> understand correctly, it would be really technically complicated to control
> this feature with an arrow in the column header like for the other columns?

It can eventually be implemented later, but it's not within the scope of this bug. Any other changes must be on separate bug reports.
Comment 42 Jess 2025-10-20 14:38:57 UTC
I work in a school Librabry and sorting by status is very helpful for me as I can see all the students who still have copies out under their name at the top of the list. This is helpful because we have many copies of the same manuel. Seeing all the names of the kids who still have their copy all together makes it easier for me to see who i need to chase down.... hope that makes sense
Comment 43 Jonathan Druart 2025-10-20 14:43:39 UTC
(In reply to Jess from comment #42)
> I work in a school Librabry and sorting by status is very helpful for me as
> I can see all the students who still have copies out under their name at the
> top of the list. This is helpful because we have many copies of the same
> manuel. Seeing all the names of the kids who still have their copy all
> together makes it easier for me to see who i need to chase down.... hope
> that makes sense

Please test the patch and tell us if it works for you.
Comment 44 Jess 2025-10-20 14:49:46 UTC
I dont know how to test patches... I don't think I have Admin access to our system unfortunetly. I just wanted to share the bug because its been there for a long time now and my higher up said that we have to wait until we go to the next version of KOHA, that was almost a year ago... 

we're still running on 24.05.05.000