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

[Bug 38396] New: Revert transit status on a hold does not work
by bugzilla-daemon＠bugs.koha-community.org 13 May '25

13 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38396 Bug ID: 38396 Summary: Revert transit status on a hold does not work Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Click the "revert transit status" on a hold allows you to change the pickup location of the item, but the item stays in transit. To recreate: 1. Place a hold for pickup at a different location. 2. Check in the hold to trigger the transfer to the pickup location. 3. Go to the holds table and click "revert transit status" on the hold. Change the location if you wish. 4. Return to the record and note that the item still says it's in transit to the original location. Checking in the location does transfer it properly, but the transit status should actually reset. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 34191] New: Record overlay rule to protect 942 with asterisk being ignored with z39.50 overlay
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34191 Bug ID: 34191 Summary: Record overlay rule to protect 942 with asterisk being ignored with z39.50 overlay Change sponsored?: --- Product: Koha Version: 22.11 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 recreate: 1. Create multiple Record overlay rules with Source, z39.50, TAG, protect, skip, skip, skip, skip. 2. Create Record overlay rule Source, *, 942, Protect, skip, skip, skip, skip. 3. Find a bib record and make sure it contains a 942 with selected item type. 4. Replace record via z39.50 (using the basic editor) 5. Edit the bib and change the protected tags in the overlay rules for z39.50. 5. Attempt to save the record. If 942 is a required field, you must select the item type. If that happens, select an alternate item type. The record will save and restore the tags protected through the z39.50 overlay rules. But the record will also save the alternate item type and not protect/restore the 942 tag to the previous item type. The asterisk should protect the 942 tag regardless of the cataloging process. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17643] New: The bug 3333 breaks intranet search results in column Location
by bugzilla-daemon＠bugs.koha-community.org 12 May '25

12 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17643 Bug ID: 17643 Summary: The bug 3333 breaks intranet search results in column Location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: christophe.croullebois(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org The Bug 3333 corrects in Opac by setting notforloan=1. But it has a side effect on intranet search result page due to the use of authorized value on 'notforloan'. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 30723] New: Allow for notices to have custom header/footer includes
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30723 Bug ID: 30723 Summary: Allow for notices to have custom header/footer includes 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries like to add the same custom header/footer to many notices/slips. It would be handy if there was a way to set a custom header/footer and then call on it in each notice/slip where you'd like to have them. That way you would not have to add the same header/footer content to each notice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 27730] New: Innocent changes to framework silently delete bibliographic data
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27730 Bug ID: 27730 Summary: Innocent changes to framework silently delete bibliographic data Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: ian.bays(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you copy and change a framework and either delete a subfield in the new framework or mark the subfield tab as "ignore", then any bib data with data in that subfield, when saved in the new framework will be silently destroyed with no option to undo. Test Plan to confirm behaviour: 1. Create bib record in default framework with minimal data, but add tag 365 (as it has a number of subfields all visible) and populate subfields a through h with "fa" through "fh". Save the record and with sql check the contents of the metadata. (I found this SQL gives enough information substituting the correct bib number of the saved record: select tagfield, tagsubfield, frameworkcode, tab, hidden, (select ExtractValue(metadata, '//datafield[@tag="365"]/subfield[@code>="a"]') from biblio_metadata where biblionumber = 37002 and (select frameworkcode from biblio where biblionumber = 37002) = marc_subfield_structure.frameworkcode) tv from marc_subfield_structure where frameworkcode in ('', 'TEST') and tagfield = '365'; ) 2. Copy the default framework to a TEST framework and set (say 365$b to tab ignore and delete 365$d). (I used export the default framework to a csv, create new TEST framework and import from the saved default csv) 3. Edit the bib record and change framework to TEST framework (settings > change framework) and save the record. 4. Run the SQL again and observe the data from subfields b and d have both disappeared from the metadata. If you were to rerun these tests you may need to reload memcache to ensure the newly changed frameworks are picked up. I understand it has been broadly known by some long-term Koha users that deleting a subfield from the framework has this effect, but both these situations potentially cause bib data to be silently and permanently delated from the database. Many users will be unaware and may not discover the problem for some time. Potential solutions might include: a) For subfields not in the framework or with tab "ignore" allow the data to be saved as is on saving for edit; b) When selecting "change framework" detect if data would be lost and alert the user with an option to back out of the change without losing data; c) Do not allow deletion of a subfield from a framework and do not allow the "ignore" option for the tab. If a field is to be ignored but hidden there are plenty of visibility options in the framework. NB: The current delivered default framework has 13 subfields set to the "ignore" tab. I cannot see what purpose these serve as no data can survive within them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 35581] New: ILL Koha classes are not consistent
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35581 Bug ID: 35581 Summary: ILL Koha classes are not consistent Change sponsored?: --- Product: Koha Version: master 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: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 127

[Bug 35083] New: Koha::Illbatchstatus should be kosher
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35083 Bug ID: 35083 Summary: Koha::Illbatchstatus should be kosher Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The following methods should just be overloading their counterparts and follow what we do everywhere else: * create_and_log => overloaded store * update_and_log => overloaded store * delete_and_log => overloaded delete Also, tests need to be placed in t/db_dependent/Koha/Illbatchstatus.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 35082] New: Koha::Illbatch should be kosher
by bugzilla-daemon＠bugs.koha-community.org 09 May '25

09 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35082 Bug ID: 35082 Summary: Koha::Illbatch should be kosher Change sponsored?: --- Product: Koha Version: unspecified 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The following methods should just be overloading their counterparts and follow what we do everywhere else: * create_and_log => overloaded store * update_and_log => overloaded store * delete_and_log => overloaded delete Also, tests need to be placed in t/db_dependent/Koha/Illbatch.t -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26500] New: Automatic renewals show incorrect count of renewals allowed when CircControl is set to "the library you're logged in at"
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26500 Bug ID: 26500 Summary: Automatic renewals show incorrect count of renewals allowed when CircControl is set to "the library you're logged in at" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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 When CircControl is set to "the library you're logged in at," the Renew column in the patron checkouts table will show the count of permitted renewals based on the library you're logged in at. This is correct for manual renewals, since those are the rules that will be enforced. However, for automatic renewals this can mean we're showing the user an incorrect number. To recreate: - Create an All Libraries rule that allows 10 renewals - Create a rule for branch A that allows 1 renewal - Creare a rule for branch B that allows 99 renewals - Check an item out from Branch A, set to auto-renew - While logged in as Branch A, confirm Koha tells you you have 1 renewal available - Log in as Branch B, see you have 99 renewals - Log in as Branch C, see you have 10 renewals - Set No Renewal Before to allow renewal immediately - run the auto_renew cron, item renews once - run the auto-renew cron again, confirm too_many error because only 1 renewal is allowed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 37995] New: (Bug 29948 follow-up) Make display author information more configurable
by bugzilla-daemon＠bugs.koha-community.org 08 May '25

08 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37995 Bug ID: 37995 Summary: (Bug 29948 follow-up) Make display author information more configurable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29948 There is a problem with displaying author's identifiers while OPACAuthorIdentifiersAndInformation is on for 024$2$a. At the current, the list of identifiers source is closed and hardcoded. So if it happens that in an authority record a 024 field exists with $2 from outside the list (like wikidata or other from the official list https://www.loc.gov/standards/sourcelist/standard-identifier.html) an empty bullet with no information is being displayed. This could be corrected either by filtering out the 024 fields in Koha::Authority::get_identifiers_and_information, or by correcting the template (authority-information.inc). However, this would only be a halfway solution. A more appropriate solution might be to introduce a sub-preference containing the triplets: source code ($2), label, URI prefix. E.g.: wikidata, Wikidata, http://www.wikidata.org/wiki/ Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29948 [Bug 29948] Display author information for researchers -- You are receiving this mail because: You are watching all bug changes.

1 4