https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |paul.derscheid@lmscloud.de |ity.org | Patch complexity|--- |Small patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 --- Comment #2 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 204051 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204051&action=edit Bug 43370: Do not display an empty holdings column The holdings table hides the columns that have no value on the current page, but update_columns_visibility() applies the user's visibility choices after that pass, so a column the user turned on is displayed, empty, on the pages where it has none. - Apply the user choices before the empty-column pass - Keep the user choice untouched, only the display of the current page is affected Test plan: 1. Have a record with more than 20 items, for instance: kj build 42 items with biblionumber=4 2. Give a call number to 20 of the items, and none to the others. UPDATE items SET itemcallnumber = NULL WHERE biblionumber = 4; UPDATE items SET itemcallnumber = CONCAT('CN-', itemnumber) WHERE biblionumber = 4 ORDER BY itemnumber LIMIT 20; 3. Go to /cgi-bin/koha/catalogue/detail.pl?biblionumber=4 4. Sort the table by "Call number", descending, so that every item with a call number is on the first page and the later pages have none. Do not rely on the default order. 5. In the column visibility menu, turn "Call number" off, then on again. Observe it is displayed on the first page. 6. Go to page 2. Observe the "Call number" column is displayed and empty for every row. 7. Apply the patch and reload the page. 8. Repeat steps 4 to 6. Observe the column is now hidden on page 2. 9. Go back to page 1. Observe the column is displayed again, so the user choice has been kept. Assisted-by: Opus 5 (Anthropic) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #3 from David Nind <david@davidnind.com> --- I didn't notice any change in behavour before and after the patch, so maybe I'm not testing correctly. In addition, I'm not sure that I agree with the behavour (both before and after the patch). I think a column in the holdings table should be shown if: 1) It is selected under columns AND 2) If ANY items have a value, not just the items shown on the current results page. Rationale: - It is jarring changing between result pages and the columns shown change - You can't sort based on the column if the column header is not shown Testing notes (using KTD): 1. When I go the record details page, the "Call number" column is shown by default as the items shown first (based on the default order) have a call number 2. If I click the sort order column for call number, the call number column disappears (and Columns > Call number has no tick) 3. Then I can't sort all the items the reverse order, as the column has disappeared (as the items now shown have no call number) 4. So that you can correctly sort all items, then I think the column should be shown if ANY of the items for the record have a value in the column -- not just what is shown in the current results page. 5. Also, form a user perspective, I find columns "randomly" appearing and disappearing when you page through result pages incredibly jarring. That is, the user interface and columns change every time you paginate. (Also, I'm not sure what the line in step 1 is about - I don't think that is a standard KTD feature: kj build 42 items with biblionumber=4) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #5 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to David Nind from comment #3)

I didn't notice any change in behavour before and after the patch, so maybe I'm not testing correctly.

In addition, I'm not sure that I agree with the behavour (both before and after the patch).

This is a very complex table, and the column visibility is working differently than other tables. This is because there are a lot of columns, and we only want to display those that contain data.

I think a column in the holdings table should be shown if:

1) It is selected under columns

Almost all columns are selected by default, so we would display all of them.

AND

2) If ANY items have a value, not just the items shown on the current results page.

Yes, in an ideal world, but this is not possible. We will need to fetch all items for that, and that would be a performance killer. This is what we want to avoid with the server-side processing and the pagination. For now we are trying to simply make it works like I think it is best. And it's already not easy :D Then we will discuss further improvements ;) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 --- Comment #6 from Jonathan Druart <jonathan.druart@gmail.com> --- The patch works as expected for me. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43370 Frédéric Demians <f.demians@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |f.demians@tamil.fr --- Comment #7 from Frédéric Demians <f.demians@tamil.fr> --- Cypress patch requires a rebase. I agree to hide a column with no value on this specific table. -- You are receiving this mail because: You are watching all bug changes.