[Koha-bugs] [Bug 33568] Use the REST API to display items on the biblio detail view

Tue Oct 31 08:58:24 CET 2023

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

--- Comment #51 from Jonathan Druart <jonathan.druart+koha at 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.
