https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568
--- Comment #51 from Jonathan Druart <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
