June 2022 - Koha-bugs - lists.koha-community.org

[Bug 15050] Nonpublic note searchable from OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '22

08 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050 --- Comment #17 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > Deeply I think MARC datas should always be public ;) I agree to a point. The problem is, that we have no way to store item specific internal information outside of MARC. I think this might be the missing feature that would resolve a lot of those issues. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15050] Nonpublic note searchable from OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '22

08 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #16 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Fridolin Somers from comment #15) > With Elasticsearch only MARC field defined with a search field are in > default search field. > Maybe fields for OPAC and for staff can be configured separately. > > Deeply I think MARC datas should always be public ;) With Zebra, we could be using the "ViewPolicy" filter with the RecordProcessor, although that would mean those non-public things would also not be searchable on the staff interface either. Probably not realistic to have different indexes for OPAC and Staff Interface for Zebra at least. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24153] New: Add a confirm flag to the cleanup_database.pl cronjob
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '22

08 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24153 Bug ID: 24153 Summary: Add a confirm flag to the cleanup_database.pl cronjob Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz That will allow to make it run in dry-run mode with a useful verbose output -- You are receiving this mail because: You are watching all bug changes.

1 56

[Bug 23407] New: XSLT Details pages don't use items, we shouldn't pass them
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '22

08 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23407 Bug ID: 23407 Summary: XSLT Details pages don't use items, we shouldn't pass them Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org C4::XSLT::XSLTParse4Display calls buildKohaItemsNamespace() for all displays For IntranetDetails and OPACDetails there is no item processing. Removing this call can save us time -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 15050] Nonpublic note searchable from OPAC
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '22

08 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15050 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers(a)biblibre.co | |m --- Comment #15 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- (In reply to Katrin Fischer from comment #11) > So since we switched to DOM indexing, the any (keyword) index will include > all information from the bibliographic record and the item records. This can > lead to confusing results in search: > > - internal note is searchable > - A gift from someone that also appears as author will be found (the name > was stored as bookseller in the item) > > It causes confusion. Is there any way around it? With Elasticsearch only MARC field defined with a search field are in default search field. Maybe fields for OPAC and for staff can be configured separately. Deeply I think MARC datas should always be public ;) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30919] New: Search on any order status
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '22

07 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30919 Bug ID: 30919 Summary: Search on any order status Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org Sometimes when searching for an ordernumber, we don't know what is its status. It could be helpful in advanced search for orders to add an option on the 'Order status' dropdown to allow searching on any status. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 8688] Add a recall button to the biblio record details page.
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '22

07 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8688 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |david(a)davidnind.com Status|Failed QA |RESOLVED --- Comment #33 from David Nind <david(a)davidnind.com> --- Recalls implemented in bug 19532 - changed status to resolved. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30676] New: View all ... preferences links don't work for translations
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '22

07 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30676 Bug ID: 30676 Summary: View all ... preferences links don't work for translations Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When you search for a preference, you can see a link "View all x preferences" with x being the heading related preferences are listed under. The problem is, that while the link uses the English ID, the ID on the heading gets translated, so the links are broken. Example: View all self check-in preferences https://elk-wue.bsz-bw.de:8080/cgi-bin/koha/admin/preferences.pl?tab=circul… But the heading translated is: <h3 id="Selbstr_ckgabe"><i class="fa fa-caret-down"></i> Selbstrückgabe</h3> (There also appears to be an encoding issue) This is because the heading and the ID get translated by Pootle and it's the same string for description and ID: https://translate.koha-community.org/de/21.11/translate/de-DE-pref.po#unit=… It's sad, because the feature is so nice :( -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8352] Add automatic printing of 'hold to pull' notices
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '22

07 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8352 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=25579 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 30682] New: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '22

07 Jun '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30682 Bug ID: 30682 Summary: Indicate in addbiblio.pl when an edit will not be saved due to Overlay Rules Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 14957 The new MARC overlay rules can prevent edits to certain MARC fields. We don't give any indication when that's happening. To recreate: - set a rule on marc-overlay-rules.pl for module=source, filter=Staff client MARC editor, tag=020, preset=protect - find a record with an 020 - edit the record, delete the 020, save. confirm the interface allows all of this - confirm the 020 is still there, but no indication of why Something here should inform the user of what's going on. Highlighting of the tag within the edit interface? A popup on saving? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 [Bug 14957] Write protecting MARC fields based on source of import -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1