[Bug 39011] New: Unable to search the holdings table (except home/holding libraries and barcode)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Bug ID: 39011 Summary: Unable to search the holdings table (except home/holding libraries and barcode) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs@lists.koha-community.org Reporter: caroline.cyr-la-rose@inlibro.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com When using the search box in the holdings tab on a record details page in the staff interface, you can only find holdings with the home or holding library. You can't search for the item type or anything else. To recreate: 1. Go to a record details page in the staff interface (e.g. http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=285) 2. Add an item with a different itemtype 2.1. Click New > New item 2.2. Change the itemtype to Music (or another itemtype) 2.3. Click Add item 2.4. Click Normal to go back to the record details page 3. Try to search for the itemtype in the holdings 3.1. Using the small search box right above the holdings table, search for the new itemtype (Music) --> No results 4. Optionally, search using other text in the holdings table - "Book" --> NOT OK does not find the items with the itemtype "Books" - "Midway" --> OK finds the items with the home or holding library "Midway" - "General" --> NOT OK does not find the items with the location "General stacks" - "Reference" --> NOT OK does not find the items with the collection "Reference" - "2477" --> OK finds the item with the barcode 39999000012477 With git bisect, I was able to retrace that it was ok before bug 33568 and not after, but I don't know which commit exactly causes the problem since the holdings table doesn't load if I'm somewhere in the middle of all the 33568 commits. -- 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=39011 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33568 Severity|enhancement |normal Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 [Bug 33568] Use the REST API to display items on the staff biblio detail view -- 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=39011 --- Comment #1 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- I noticed that when searching for BK or MU, it finds the items with those itemtypes. I'm guessing it's a similar problem to bug 37334 (??) of the table using the codes instead of the labels. However, home/holding libraries are searchable both by code and by name. I don't see why it couldn't be the same for item types. - "CPL" --> OK finds items with Centerville home or holding library - "Center" --> OK finds items with Centerville home or holding library - "FPL" --> OK finds items with Fairview home or holding library - "FAIR" --> OK finds items with Fairview home or holding library -- 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=39011 --- Comment #2 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- There are no itemcallnumbers in KTD by default, but I found that those work fine, like the barcodes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38130 --- Comment #3 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Caroline Cyr La Rose from comment #1)
I'm guessing it's a similar problem to bug 37334 (??) of the table using the codes instead of the labels.
No, it's similar to bug 38130. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #4 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 177465 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177465&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com, | |pedro.amorim@ptfs-europe.co | |m, tomascohen@gmail.com Status|NEW |Needs Signoff --- Comment #5 from Jonathan Druart <jonathan.druart@gmail.com> --- Settings to "Needs signoff" so Caroline can test. But I would like feedback from other people close to this code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |jonathan.druart@gmail.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucasm@moravian.edu -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|lucasm@moravian.edu | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #6 from David Nind <david@davidnind.com> --- I tested, and this is working for me (both the code and the full name) for: - Current library (holding library) - Home library (home library) - Collection (collection code) It is not working for me for item type, for example BK or Books shows no results. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #177465|0 |1 is obsolete| | --- Comment #7 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 177553 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177553&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #8 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to David Nind from comment #6)
I tested, and this is working for me (both the code and the full name) for: - Current library (holding library) - Home library (home library) - Collection (collection code)
It is not working for me for item type, for example BK or Books shows no results.
Indeed, code and description were swapped. I also fixed the search on holding branch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #177553|0 |1 is obsolete| | --- Comment #9 from David Nind <david@davidnind.com> --- Created attachment 177556 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177556&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes and improves release notes| |searching the holdings | |table for columns that use | |an authorized or coded | |value. You can now use | |either the codes or the | |description when searching | |for item type, current | |library, home library, and | |collection columns. For | |example, searching for BK | |or Books now works as | |expected. --- Comment #10 from David Nind <david@davidnind.com> --- (In reply to Jonathan Druart from comment #8)
(In reply to David Nind from comment #6)
I tested, and this is working for me (both the code and the full name) for: - Current library (holding library) - Home library (home library) - Collection (collection code)
It is not working for me for item type, for example BK or Books shows no results.
Indeed, code and description were swapped. I also fixed the search on holding branch.
Thanks Jonathan! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38110 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #177556|0 |1 is obsolete| | --- Comment #11 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Created attachment 177620 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177620&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Nick Clemens (kidclamp) <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #12 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- Added 150 branches and 900 items, this performed as well as or better than the previous method for searching libraries and the new searches all worked in my testing. Asking Lucas to give a final stamp here as he has been working on these issues -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #13 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Now we have a situation where there are two "filters". The dataTables default one ( #dt-search-0 ) above the table and one for each column after clicking 'Show filters'. With collection code these two now behave differently with this patch. The dataTable filter can filter by collection code or description. The one directly above the column only searches on code. That behavior should probably be consistent OR the filter above the column should become a dropdown like item type/home branch/holding branch? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #14 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Lucas Gass (lukeg) from comment #13)
Now we have a situation where there are two "filters". The dataTables default one ( #dt-search-0 ) above the table and one for each column after clicking 'Show filters'.
With collection code these two now behave differently with this patch. The dataTable filter can filter by collection code or description. The one directly above the column only searches on code. That behavior should probably be consistent OR the filter above the column should become a dropdown like item type/home branch/holding branch?
However, this is probably a seperate bug/issue so I'm willing to PQA here. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #15 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Ignoring the QA complaining about a console.log, as I assume that is wanted. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #177620|0 |1 is obsolete| | --- Comment #16 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Created attachment 177702 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177702&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |lucas@bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |ASSIGNED --- Comment #17 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Lucas Gass (lukeg) from comment #14)
(In reply to Lucas Gass (lukeg) from comment #13)
Now we have a situation where there are two "filters". The dataTables default one ( #dt-search-0 ) above the table and one for each column after clicking 'Show filters'.
With collection code these two now behave differently with this patch. The dataTable filter can filter by collection code or description. The one directly above the column only searches on code. That behavior should probably be consistent OR the filter above the column should become a dropdown like item type/home branch/holding branch?
However, this is probably a seperate bug/issue so I'm willing to PQA here.
I will have a look. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #18 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 177725 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=177725&action=edit Bug 39011: Apply the pre-process to column filters -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff --- Comment #19 from Jonathan Druart <jonathan.druart@gmail.com> --- Please have a look at the second patch. It is supposed to apply the pre-process step to the values of the column filters. I have not tested it a lot, I am a bit hesitant to change the core of our datatable code without providing Cypress tests. But unfortunately I don't have time right now to provide them. Feel free to have a look and test it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@libriotech.no Status|Needs Signoff |Patch doesn't apply --- Comment #20 from Magnus Enger <magnus@libriotech.no> --- $ git bz apply 39011 Bug 39011 - Unable to search the holdings table (except home/holding libraries and barcode) 177702 - Bug 39011: Pre-process coded values when building the query 177725 - Bug 39011: Apply the pre-process to column filters Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 39011: Pre-process coded values when building the query Using index info to reconstruct a base tree... M koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc M koha-tmpl/intranet-tmpl/prog/js/datatables.js Falling back to patching base and 3-way merge... Auto-merging koha-tmpl/intranet-tmpl/prog/js/datatables.js CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/js/datatables.js Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc error: Failed to merge in the changes. Patch failed at 0001 Bug 39011: Pre-process coded values when building the query -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #177702|0 |1 is obsolete| | Attachment #177725|0 |1 is obsolete| | --- Comment #21 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 178033 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178033&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #22 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 178034 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178034&action=edit Bug 39011: Apply the pre-process to column filters -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178033|0 |1 is obsolete| | --- Comment #23 from David Nind <david@davidnind.com> --- Created attachment 178118 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178118&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178034|0 |1 is obsolete| | --- Comment #24 from David Nind <david@davidnind.com> --- Created attachment 178119 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=178119&action=edit Bug 39011: Apply the pre-process to column filters Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl Status|Signed Off |Failed QA --- Comment #25 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Not sure about this change. Seems like we want something from DataTables that it simply does not offer. Resulting code looks complexer than needed? Harder to maintain? We create an inconsistency here too. I can look for the coded values with homebranch, searching for CPL. But I can not look for an item type with BKS. If we would go for the descriptions that are shown, we should remove searching on the branch codes imo. This is a result of a join somewhere iiuc (not checked)? Needs feedback. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|lucas@bywatersolutions.com |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #26 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Marcel de Rooy from comment #25)
Not sure about this change. Seems like we want something from DataTables that it simply does not offer. Resulting code looks complexer than needed? Harder to maintain? We create an inconsistency here too. I can look for the coded values with homebranch, searching for CPL. But I can not look for an item type with BKS. If we would go for the descriptions that are shown, we should remove searching on the branch codes imo. This is a result of a join somewhere iiuc (not checked)?
Needs feedback.
The inconsistency you mentioned should be fixed. Will removing the ability to also search by a code really be a problem? If we can we should leave it. Searching by descriptions is very important to librarians but I know some still like to search on code. Why do you think it is so complex? It doesn't seem so bad to me. Do you have a simpler solution in mind? If so, great! But if not I don't think we should block this because it is too complex. This is a bad bug for many libraries and a fix is needed ASAP. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #27 from Jonathan Druart <jonathan.druart@gmail.com> --- Searching by item type works for me, using BK for Books. I've tried to make this generic enough to have it applied to other tables easily. The main idea is to make the job client-side and avoid unnecessary joins on the server. Here you will need to have 1 extra join per column with a dropdown filter which will result in monstrous SQL queries. I personally think it's quite elegant :D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Passed QA --- Comment #28 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to Jonathan Druart from comment #27)
Searching by item type works for me, using BK for Books.
I've tried to make this generic enough to have it applied to other tables easily.
The main idea is to make the job client-side and avoid unnecessary joins on the server. Here you will need to have 1 extra join per column with a dropdown filter which will result in monstrous SQL queries.
I personally think it's quite elegant :D
I re-tested, itemtype works for me also. This is a pretty big blocker for many of our libraries. In my opinion this cannot be held up any longer so I am going to set it back to PQA. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Signed Off --- Comment #29 from Jonathan Druart <jonathan.druart@gmail.com> --- Sorry, Lucas, but we have a QA member with doubts about the approach. I’d like to request another QA review, either Marcel needs to be convinced, or another member should approve it or suggest an alternative approach. I’ll ask Tomas since he’s familiar with the DataTables.js code. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #30 from Jonathan Druart <jonathan.druart@gmail.com> --- s/DataTables.js/datatables.js -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |39315 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39315 [Bug 39315] Missing tests for KohaTable search on coded value's description -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #31 from Jonathan Druart <jonathan.druart@gmail.com> --- Tests for those changes will be on bug 39315. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|m.de.rooy@rijksmuseum.nl |martin.renvoize@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #32 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- I think this is actually pretty clear and, importantly, performant, code. My one caveat is that I'd like to see an update to the JSDoc to highlight the usage option this introduces so other developers can make use of it in the future. I'm currently working on that as a followup, but I generally feel this is a pass once we have that. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178118|0 |1 is obsolete| | --- Comment #33 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 180264 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180264&action=edit Bug 39011: Pre-process coded values when building the query When a column contains authorised/coded values, it is not possible to search on the description. It is confusing for the user as the description is the value displayed in the table. We have discussed this already on bug 38130 and decided to fix the problem by doing a new SQL join. But this can lead to performance issues, especially for tables like the items table where a lot of coded values are displayed. This patch suggests to do a pre-processing step, before the query is sent, to let the client build the query it needs. An alternative approach would be to do the same job server-side, and allow this kind of processing for all the attributes with a object using columns_to_str. But we will certainly reach performance problems. This is still not perfect, but it's fixing a regression quite easily, and will open the door to more fixes for tables using coded values. This patch revert one we have done on bug 38130, and use this new mecanism for home library, holding library, item type and collection code. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #178119|0 |1 is obsolete| | --- Comment #34 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 180265 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180265&action=edit Bug 39011: Apply the pre-process to column filters Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #35 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 180266 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180266&action=edit Bug 39011: (follow-up) JSDoc Add some initial JSDoc for the enhancments to datatables we introduce here. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #180266|0 |1 is obsolete| | --- Comment #36 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 180267 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=180267&action=edit Bug 39011: (follow-up) JSDoc Add some initial JSDoc for the enhancments to datatables we introduce here. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |Main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |25.05.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #37 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Pushed for 25.05! Well done everyone, thank you! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37334 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 --- Comment #38 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 182175 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182175&action=edit Bug 39011: (follow-up) Update selenium tests We alter how the options are added to the patrons_search datatables search bar, but we didn't update the selenium test to match. Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |additional_work_needed Status|Pushed to main |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|additional_work_needed | --- Comment #39 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Follow-up for selenium was pushed to main. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Bug 39011 depends on bug 33568, which changed state. Bug 33568 Summary: Use the REST API to display items on the staff biblio detail view https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568 What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m Version(s)|25.05.00 |25.05.00,24.11.08 released in| | Status|Pushed to main |Pushed to stable --- Comment #40 from Fridolin Somers <fridolin.somers@biblibre.com> --- Pushed to 24.11.x for 24.11.08 Very useful ;) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Arthur Suzuki <arthur.suzuki@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40904 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40904 [Bug 40904] Unable to search items by location -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |41341 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41341 [Bug 41341] Some filters do not use the exact match in detail.pl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wainuiwitikapark@catalyst.n | |et.nz Status|Pushed to stable |Needs documenting --- Comment #41 from Wainui Witika-Park <wainuiwitikapark@catalyst.net.nz> --- Not backporting to 22.11.x as it wasn't backported to 24.05.x -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs documenting |RESOLVED Resolution|--- |FIXED --- Comment #42 from Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> --- Bug fix to restore expected behaviour. Noting to add or edit in the Koha manual. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org