https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 --- Comment #51 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Katrin Fischer from comment #50)
Problems: 1) One of the commit messages needs to be fixed Two were kept for history, I removed them from the branch.
NOT OK - QA script still complains: * Commit title does not contain 'follow-up' correctly spelt - fd8d8f5ba2 (Bug 33568: (folow-up) Restore filters)
Indeed, I missed that one, fixed now.
* We also got some perltidy complaints on top.
It's too late now. It is too time consuming to fix inline, and I don't like the big "tidy" patches...
4) Table configuration doesn't appear to be used as expected. I checked: Catalog > holdings_table has only holdings_issues and holdings_renewals hidden by default. But the table keeps appearing with only a minimum number of columns and a lot of them hidden. Unfortunately the hidden column also includes much neded ones like callnumber. Any changes I make don't seem to stick.
The table is hiding empty columns. So if the x items displayed on the page do not have callnumber, then the column will be hidden, even if other pages have items with callnumber. Is that what you are seeing? See commit message "Bug 33568: Hide empty columns". It is what we are doing already on master, but here we don't want to fetch all the items to know if data exist for each each column...
DISCUSS - Yes, confirmed - the column visibility is determined by the value savailable on the first visible page.
I think this could be problematic, I'd really like to get more opinions, favourably from daily Koha users on this.
As explained, I didn't find an alternative.
5) SpineLabelShowPrintOnBibDetails: the callnumber print on longer opens in small size modal. This also has the effect, that there is no way to close this window without printing.
Fixed in "Bug 33568: Fix popup behaviour for SpineLabelShowPrintOnBibDetails"
NOT OK - I yarn build, restart_all... but the modal is not 'modaling' for me. I still opens full size in a new tab.
You don't need to rebuild. It seems ok for me however, the pop-up opens in a new window. Could you try to add a console.log there: diff --git a/koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc b/koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc index acda1e9edd4..e24e6deb661 100644 --- a/koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc +++ b/koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc @@ -818,6 +818,7 @@ [% IF ( SpineLabelShowPrintOnBibDetails ) %] $(".print-label").on("click", function(e){ + console.log("click"); e.preventDefault(); link = $(this).attr("href"); openWindow(link,"Print spine label",400,400); open the console and see if you see the "click" when you click on the "Print label" button?
6) The status column is no longer sortable. It's sortable in 22.11 and works well there. Alos: I can't activate a filter for this column and the normal filter doesn't find the contents of the column. There is no way to find the 'checked out' or 'ordered' items in that list.
See commit message for "Bug 33568: Status" """ See the FIXME in the code, we are losing the ability to search on the status, but this is really impossible to implement if we are not storing the status (DB or search engine). """
DISCUSS - So the problem here is that we are storing different numeric values and therefore cannot sort on anything useful... is that it?
I believe that could be an issue for a lot of libraries, as it stands now for the before and after:
Before * Can sort on status * Can search on status using column filter * Can search on status using the top table search field (overall search)
After * Can't do any of that.
It's definitely something that we need to get more eyes on again as it could be seen as quite disruptive.
Yes, it has been advertised since the beginning.
Crazy idea: could we collect the status appearing in the data (all of them) and provide a pull down for limiting somehow? A multi select maybe?
Maybe, but it's definitely not for now neither here. We need to move the "status" logic from the template to a module. That is something we need to do, but it is outside the scope of this bug.
8) hidepatronname doesn't seem to have any effect.
I think this is a bug in js-patron-format.inc, it should be reported separately.
I double-checked in current master: hide: Checked out to 42 : due 04.11.2023 don't hide: Checked out to koha (42) : due 04.11.2023 So it does look like it's related to this patch set somehow. Sorry.
It is a bug in js-patron-format.inc, but we were not using it before (patron-title.inc). I finally decided to fix in a follow-up here. Fixed in "Bug 33568: Fix patron_to_html display". Read the commit message, there are more fixes in this one.
9) Using the single search box on top of the table: "checked" doesn't find the checked out items. In 22.11 that works.
If we want that we need a filter at the top of the page. That should be a separate bug.
I was talking about the filter on top of the table - are we talking about the same thing?
Yes. This is the same as the "status" problem. "checked" is not in a DB column. We can have this quite easily (without the other statuses however), but it's not a simple patch.
11) NEW: Column filters for item type and current library don't show as a pull down. Holding branch does.
I do see a select there. Can you retest or provide more steps to recreate? This is what I am seeing after a reset_all on /catalogue/detail.pl?biblionumber=4, click "Show filters" https://snipboard.io/9E0VwH.jpg
2) Right now we see all items immediately in the table, one the page has loaded. Now we only see the first 20. Libraries might feel this is a too low default setting. It would be great if we could have that configurable in table settings from the start.
It should be very easy to implement. I will do it when this reaches master.
I filed it separately as: Bug 35191 - Make entries per page configurable for items table on staff detail page
I will have a look. If I understand correctly, this is "in discussion". I need to know if people still wants it for 23.11, do I spend more time on it today or do we postpone the remaining work to next month/year? -- You are receiving this mail because: You are watching all bug changes.