October 2024 - Koha-bugs - lists.koha-community.org

[Bug 1889] Virtual shelves leave blank field in staff intranet when BIB is deleted
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1889 Martin Renvoize (ashimema) <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 1889] Virtual shelves leave blank field in staff intranet when BIB is deleted
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

1 0

[Bug 37705] New: Use REST API for patron_holds_table ( reserve/request.pl )
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37705 Bug ID: 37705 Summary: Use REST API for patron_holds_table ( reserve/request.pl ) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With a large amount of holds the patron_holds_table ( reserve/request.pl ) is very slow to load. REST API + pagination would help solve this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 32467] New: ExpireReservesAutoFill should send to the holding library when notifying of a hold in transit
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '24

19 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32467 Bug ID: 32467 Summary: ExpireReservesAutoFill should send to the holding library when notifying of a hold in transit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When an expired hold is cancelled and set to auto fill, if the next hold requires transit the email is sent to the receiving library. This means the holding library is not notified that the hold should be removed from the hold shelf. I believe the notice should either be sent to the holding library, or both libraries. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 15728] New: Hide component parts from search result
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '24

19 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15728 Bug ID: 15728 Summary: Hide component parts from search result Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: larit(a)student.uef.fi QA Contact: testopia(a)bugs.koha-community.org Add an option to hide component parts from search results. When searching for a song, we may want to see album results only (albums where the song appears). This option would help the process of seeing if a song is on an album that is available. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 38215] New: Unable to clear "records with available items" limit by clicking "show all records"
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '24

19 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38215 Bug ID: 38215 Summary: Unable to clear "records with available items" limit by clicking "show all records" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org Limiting to records with available items using facet and then attempting to reset it by pressing "Show all records" does not reset/clear the limit. To test: 1. Set system preference SearchEngine => Zebra 2. Search (allrecords,AlwaysMatches='') (staff or OPAC, doesn't matter) 3. From facets, click "Limit to records with available items" 4. Click "Show all records" 5. Observe search box: Expected result (allrecords,AlwaysMatches='') Actual result ccl=(allrecords,AlwaysMatches='') and (( (allrecords,AlwaysMatches='') and (not-onloan-count,st-numeric >= 1) and (lost,st-numeric=0) )) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38006] New: Advanced editor not applying frameworks when editing
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '24

18 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38006 Bug ID: 38006 Summary: Advanced editor not applying frameworks when editing Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To replicate: 1. Ensure there is a complete default framework and a brief framework like fast add. 2. Find a bibliographic record where there are many fields used (so it is obvious whether the fast add framework has been applied or not). 3. Edit the record in the advanced editor. 4. Take note of the fields. Go to settings and select Fast Add as the framework. 5. Notice nothing happens, all the fields are still showing. 6. Save the record, see all the fields are retained. 7. Click on View to view the bibliographic detail and see the record appears unchanged. 8. Notice the bibliographic detail shows the framework as Fast Add, even though it displays all the fields. 9. Edit the record again in the advanced editor, check framework setting and save. Notice no changes. 9. Edit the record again in the advanced editor and see all the fields. Switch to the basic editor. See that the fast add framework is now applied and fields that shouldn't be there are now removed. The basic editor applies framework changes immediately upon changing. This is problematic if a framework is applied in the Advanced Editor and the changes are not properly applied. It could be a bit of surprise if the example record is edited in the future and data disappears when the basic editor opens. While the basic editor is doing what it is supposed to do, the advanced editor should also replicate the behavior when applying a new framework. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 38213] New: Fix problems with MARC21 003 being mandatory
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '24

18 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38213 Bug ID: 38213 Summary: Fix problems with MARC21 003 being mandatory Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: katrin.fischer(a)bsz-bw.de, m.de.rooy(a)rijksmuseum.nl In the MARC21 frameworks we ship, 003 is mandatory in Default and thus in the optional frameworks like BKS since they copy mandatory from Default. However, the optional frameworks set 003 to hidden = -6, which is visible in the OPAC and staff interface but not in the (basic) editor. That means that if you create two records in BKS in the basic editor, you cannot set a value for 003, and then if you try to merge them you will not be able to merge, because 003 is mandatory but not present in either record and merging records enforces mandatories. We could fix that for future installations by not setting hidden to -6 in the optional frameworks, so that they would require setting 003 just like Default does. Or, we could fix it by not setting 003 mandatory. 003 is the marcorg code for the organization whose control number is in 001, but we don't set 001 as mandatory so we require a code for the organization which set the control number '' so that '(code)' will be a globally-unique control number, which is nonsense. It also creates nonsense when you import a naughty record which has a 001 but no 003, since then you will click in the 003 and have marc21_orgcode.pl fill in your marcorg code, saying that the control number is yours when in fact it's from someone unknown. What we really mean by having 003 mandatory is '[ ] Mandatory for newly created records if 001 has a value', a checkbox which doesn't currently exist in frameworks and wouldn't be useful to add, since 003 is the only MARC21 field which is meaningless on its own and only exists as a prefix for another field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38168] New: Records always opening in default framework
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '24

18 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38168 Bug ID: 38168 Summary: Records always opening in default framework Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: isabel.pineda(a)ds.edu.sv QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Following bug 38082, @Janusz Kaczmarek recommended to file a new bug for the problem: Since Koha version 24.05.04: When opening an existing record that was saved with a specific framework (not the default one), the record always opens in the default framework. When opening the select field "Preferences", the original framework is still checked. In version 24.05.03 and before it was working normally. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 37401] New: Wrong i index of inputs for 'Unlimited' values
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '24

18 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37401 Bug ID: 37401 Summary: Wrong i index of inputs for 'Unlimited' values Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: stalkernoid(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6