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

[Bug 36111] New: 856$h should not appear as a link in detailed record
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36111 Bug ID: 36111 Summary: 856$h should not appear as a link in detailed record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org The newish MARC21 field 856$h is used to store non-functioning urls. However, if a record has data in 856$h (or any 856 subfield), a link "Click here to access online" appears in the results list and detailed record in the opac and the staff interface. To replicate: 1. Add 856$h to MARC editor 1.1. Go to Administration > MARC bibliographic frameworks 1.2. Next to Default framework, click Actions > MARC structure 1.3. Search for field 856 1.4. Click Actions > Edit subfields 1.5. Click h 1.6. Check the Editor box 1.7. Click Save changes 2. Catalog a new record with a random URL in 856$h 2.1. Go to Cataloging 2.2. Click New record 2.3. Fill out the mandatory fields (000, 003, 005, 008, 040$c, 245$a, 942$c) 2.4. Go to tab 8 and enter a value in 856$h 2.5. Click Save (No need to add an item) 3. Search for the title in the staff interface (a large enough search to have more than one result) --> Notice it says "Online resources: Click here to access online" 3.1. Try to click the link --> Blank page 4. Access the detailed record in the staff interface --> Notice it says "Online resources: Click here to access online" 4.1. Try to click the link --> Blank page 5. Search for the title in the opac (a large enough search to have more than one result) --> Notice it says "Online resources: Click here to access online" 5.1. Try to click the link --> Blank page 6. Access the detailed record in the opac --> Notice it says "Online resources: Click here to access online" 6.1. Try to click the link --> Blank page I don't think 856$h should trigger the link to appear. I managed to hide it from the OPAC by making 856$h invisible in the OPAC, but the link is still there in the staff interface and still leads nowhere... In my opinion, if 856$h is to be displayed, it should only appear in the staff interface detailed record (not results list or opac), and only be regular text, not a link, with the mention (non functional). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 106

[Bug 33925] New: Improve translation of title tags: Serials
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33925 Bug ID: 33925 Summary: Improve translation of title tags: Serials Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 33906 This patch will modify serials templates in the staff client so that translatable strings in the <title> tag are wrapped in the correct translation function, e.g. [% t('Translate me') %] Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33906 [Bug 33906] [OMNIBUS] Improve translation of title tags -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 36054] New: Setting MARC 005 as not required causes save error in Advanced Editor and not Basic Editor
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36054 Bug ID: 36054 Summary: Setting MARC 005 as not required causes save error in Advanced Editor and not Basic Editor Change sponsored?: --- Product: Koha Version: unspecified 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 This requires having some bib records where the 005 is blank or missing. To recreate: 1. Edit the default framework and uncheck the mandatory box for the 005 and save. 2. Find a bib record with a missing/blank 005 and edit the record in the basic editor. 3. See that the 005 is blank and is not required. Save The record saves as it should. 4. Now edit the record again and switch to the Advanced Editor. 5. See that the 005 is missing. 6. Save. Save fails and gives an error statement "Record structure invalid, cannot save." Ideally records should have a 005. If this is a truly required field for Koha to function, then the ability to mark the field not mandatory should be disabled. Along with this, the ability to delete the field should be prevented (see bug 35135). Regardless, this is inconsistent behavior where it works in one place and not another. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 30856] New: Remove CanReserveBeCanceledFromOpac
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30856 Bug ID: 30856 Summary: Remove CanReserveBeCanceledFromOpac Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We already have a method that does the same check, Koha::Hold->is_cancelable_from_opac -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 27063] New: Allow changing which record an order is linked to
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27063 Bug ID: 27063 Summary: Allow changing which record an order is linked to Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org At the moment if the basket is still open you can update the bbliographic details of an order or overwrite the existing record via Z39.50, but if you notice that you have used the wrong record, there is no way to fix this. It would be great if it was possible to change the record an order is linked to while the basket is still open. This should explicitly allow to use a record that is already in the catalog. -- There is also a use case here for libraries using standing orders for tracking electronic resources such as series. They usually place the order on the series record. When the volumes arrive they'd like to change it so the acq information is tied to the volume. But without using items (which is not the case here for electronic resources), this is not possible. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 39

[Bug 32722] New: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional.
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32722 Bug ID: 32722 Summary: Mandatory subfields from Unimarc framework shouldn't block the creation of a bib record when field itself is optional. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibault.keromnes(a)univ-paris8.fr QA Contact: testopia(a)bugs.koha-community.org Created attachment 145658 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=145658&action=e… List of mandatory subfields BZ30733 added many mandatory subfields in UNIMARC default framework, following the IFLA manual updates. Thing is, most of those mandatory subfields are within an optional field, so they're supposed to be mandatory only if the field is used. Yet Koha blocks the record's creation with ~60 mandatory subfields. Most practical solution would probably be to remove the mandatory flag to said subfields (the list is attached to the bug). Exception are 100$a and 200$a (the fields being mandatory too it makes sense) Also have a doubt concerning 099$t and 942$c, that are not actually Unimarc, but Koha specifics, storing biblioitems.itemtype. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65

[Bug 32638] New: No reason given for why items ignored during MARC import
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32638 Bug ID: 32638 Summary: No reason given for why items ignored during MARC import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org In the past, if you had a "coded_location_qualifier" that was too long, the whole MARC import would bust (see bug 30739). That's no longer the case anymore. However, if the item has a "coded_location_qualifier" like "ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ123456789", it will now just be ignored without any more information shown on the Web UI or in the worker logs. You wouldn't be able to troubleshoot this issue without writing your own code changes to Koha... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 22881] New: Trying to clear search history via the navbar X doesn't clear any searches
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '25

18 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22881 Bug ID: 22881 Summary: Trying to clear search history via the navbar X doesn't clear any searches Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To Reproduce: 1) Run a few keyword searches on your Opac. You can be logged in or not, the behavior is the same. 2) Go to 'My Search History' the /cgi-bin/koha/opac-search-history.pl page. 3) Delete your past searches by selecting one or multiple searches and clicking the "Remove Selected Searches" button. You'll get an alert pop-up about what you are about to delete. The searches you selected should delete successfully. 4) Look at the little "x" (next to "Search History" in the Navbar). If you click on this "x" it will give you the exact same alert pop-up, however is you say yes, delete my searches, nothing will be deleted. Either the little "x" should not give you the option to delete searches nor the alert message or it should clear all your saved searches; as if you hit select all and Remove. Otherwise patrons who want to delete their history will be incorrectly lead to believe it was cleared if they don't check /cgi-bin/koha/opac-search-history.pl . -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 25996] New: Changes to debarments should be logged
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25996 Bug ID: 25996 Summary: Changes to debarments should be logged Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - verify borrower log is enabled 2 - click Edit on a patron 3 - on the edit page click "add a manual restriction" and enter a debarred comment, save the patron 4 - click Edit again, remove your restriction 5 - go to patron modification logs, see the log of your changes 6 - go back to the borrower checkout page, click to the Restrictions tab 7 - add a restriction 8 - delete the restiction 9 - go to patron modification logs, see there is not a log of your changes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 26170] New: Create "system" patrons that cannot be (easily) deleted via the web ui
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '25

16 Apr '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26170 Bug ID: 26170 Summary: Create "system" patrons that cannot be (easily) deleted via the web ui Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At the moment, the only way to create OAuth2 or Basic Auth credentials is to generate a user. This user can be deleted by a librarian by accident, which will break your API integration with Koha. I propose that we make some system users that cannot be deleted from the Web UI. (Or users that can be deleted by a superlibrarian, but need to be "unlocked" first or maybe have their category changed, and a warning splashed that this will likely break integrations with other systems.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 78