May 2023 - Koha-bugs - lists.koha-community.org

[Bug 18397] New: Sent notices for...: Display email address ( including which field it's taken from)
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18397 Bug ID: 18397 Summary: Sent notices for...: Display email address (including which field it's taken from) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org Display in Home > Patrons > Sent notices for... the email address and the field where it is taken from. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 31923] New: 'Ignore' tab description is misleading
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31923 Bug ID: 31923 Summary: 'Ignore' tab description is misleading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you are modifying a MARC bibliographic framework, you can choose in which tab a particular subfield appears, or 'ignore' it. The description under this choice is 'Ignore means that the subfield does not display in the record editor' Which is true, but it doesn't mention that the subfield is completely removed from the record. This can cause data loss. If you're not aware of this, the 'Ignore' description is a bit misleading. I always instruct system administrators to use the 'Editor' checkbox if they do not want to see a particular subfield in the editor, and use only 'Ignore' if they really want to flush that subfield completely. I think the description could be improved to add that values will be deleted from the subfield as well. Maybe 'Ignore means that the subfield does not display in the record editor and that it's value, if any, is deleted from the record' -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 18885] New: Onsite Checkout has a weird behaviour concerning sticky due date
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18885 Bug ID: 18885 Summary: Onsite Checkout has a weird behaviour concerning sticky due date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you perform an onsite checkout, the next checkout is pre-setted as follows: - Specify due date => today - Onsite checkout => not checked I don't think this is is a correct behaviour: according to me there are 3 solutions, but I don't know which is the best: - Maintaining "onsite checkout" checked - Don't change duedatespec in interface when onsite checout is clicked and process it in the intranet part - Remove the duedatespec on the new checkout page loading This part of the code is really hard for me since it were patched and re patched and I'm not sure of the expected behaviour of all lines, so I would like some expert opinion before coding a solution -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 25560] New: Exclude itemtypes from UpdateNotForLoanStatusOnCheckin
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25560 Bug ID: 25560 Summary: Exclude itemtypes from UpdateNotForLoanStatusOnCheckin Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently the UpdateNotForLoanStatusOnCheckin syspref will update the items.notforloan value of ALL items checked in regardless of itemtype. It would be useful to be able to exclude specific itemtypes. This enhancement will add a checkbox 'Update not for loan status on check-in' to the administration item types page (Administration > Item types). When the UpdateNotForLoanStatusOnCheckin syspref contains content and this checkbox is unticked then that itemtype is excluded from having its items.notforloan changed upon checkin. -- You are receiving this mail because: You are watching all bug changes.

1 142

[Bug 30403] New: Update notforloan status also on check put
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30403 Bug ID: 30403 Summary: Update notforloan status also on check put 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: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We currently have syspref UpdateNotForLoanOnCheckin which updates notforloan status when item is checked in. We should also have same kind of syspref for check outs. This would be useful if for example library has item in exhibition with status "In exhibition, available for loan". When patron check outs the item notforloan status can be changed to 0, informing staff that the item is back on circulation and not longer present in the exhibition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 33464] New: Report "Orders by fund" is missing page section on results
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33464 Bug ID: 33464 Summary: Report "Orders by fund" is missing page section on results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: Academy Severity: trivial Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The Orders by fund report is missing the page section on its results table. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 33244] New: Do not show lists in OPAC if OpacPublic is disabled
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33244 Bug ID: 33244 Summary: Do not show lists in OPAC if OpacPublic is disabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: data-27FC05A3CB97(a)office-dateien.de QA Contact: testopia(a)bugs.koha-community.org Koha will still show public lists next to the logo in OPAC even when OpacPublic is disabled, i.e. patrons are required to login to access anything. This can be a privacy issue, since list names may contain things that are not meant to be public and are intended to been seen only by registered patrons. Also it is not useful anyway, as clicking on a list list name does not actually bring up that list and just shows the login form. The whole list tab should be hidden when OpacPublic is disabled and a user is not logged in. -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 33117] New: Patron checkout search not working if searching with second surname
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33117 Bug ID: 33117 Summary: Patron checkout search not working if searching with second surname Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: isabel.pineda(a)ds.edu.sv QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We are running Koha 22.11.03 in Spanish, and today I have found a problem if I search for a patron in the staff interface with the “checkout” search (“préstamo”). In Spanish speaking countries, people usually have 2 surnames. When I create a new user, I write both surnames in the “surname” field and both given names in the “First name” field. If I enter the name or parts of it in the “checkout” search, without hitting Enter, I get a list of results where I can choose from. It used to be possible in previous versions to search for patrons using the first name and the second surname. Today I found that this is not possible anymore. For example, if there is a patron with the name “Carla María Ramírez Hernández”, I find her if I search with “Carla Ramírez”, but not if I search with “Carla Hernández”. It doesn´t work either if I search with the second given name and first surname (“María Ramírez”). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 118

[Bug 30660] New: Add cancellation reason to holds delete endpoint
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30660 Bug ID: 30660 Summary: Add cancellation reason to holds delete endpoint Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: johanna.raisa(a)koha-suomi.fi CC: tomascohen(a)gmail.com The holds delete endpoint is missing cancellation reason. Should be able to add it also via REST API. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 17628] New: Move bibliographic related code to Koha::Biblio
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17628 Bug ID: 17628 Summary: Move bibliographic related code to Koha::Biblio Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 31