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

[Bug 31912] New: When enforcing 2FA we should alert the user
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31912 Bug ID: 31912 Summary: When enforcing 2FA we should alert the user Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org After bug 30588 the staff can set 2FA as forced - when this set we should notify the user of this setting both on: 1 - Their 2FA setup page in the staff interface/user account 2 - The login screen when sending them to setup 2FA -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22581] New: Include the Verovio library to show musical incipits
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22581 Bug ID: 22581 Summary: Include the Verovio library to show musical incipits Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Marc tag 031 includes the musical incipit (first compases of a melody) as code. Musical catalogs such as MUSCAT (http://muscat-project.org) use this information to display the incipit in musical code and to allow to search for incipits. Since it is possible to export MUSCAT data and import it in Koha, for music libraries it would be very helpful to display the incipit in the OPAC. MUSCAT uses an external libray, Verovio (https://www.verovio.org/) to do this. If the tag 031 is present, Verovio should be used to show the incipit in musical notation. -- You are receiving this mail because: You are watching all bug changes.

1 44

[Bug 31354] New: Clarify options for 'Change messaging preferences to default for this category?' popup
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '24

15 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31354 Bug ID: 31354 Summary: Clarify options for 'Change messaging preferences to default for this category?' popup Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The options for the 'Change messaging preferences to default for this category?' popup that appears when editing a patron's category are Cancel and OK, but I think No instead of Cancel and Yes instead of OK would be clearer. A library could reasonably think that Cancel refers to cancelling the change in category, and No would make it clearer that refers to the preferences only. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 17798] New: Checking out an item on hold for another patron prints a slip but does not update hold
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '24

14 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17798 Bug ID: 17798 Summary: Checking out an item on hold for another patron prints a slip but does not update hold 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: Place a hold for patron A Do not confirm the hold Checkout that item to Patron B See the options including 'Don't checkout and print slip' Print the slip Check the item record The hold has not been confirmed and the item 'last seen' is not updated For consistency printing should confirm the hold as well and mark the item waiting or initiate a transfer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 22042] New: BlockReturnofWithdrawn Items does not block refund generation when item is withdrawn and lost
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '24

14 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22042 Bug ID: 22042 Summary: BlockReturnofWithdrawn Items does not block refund generation when item is withdrawn and lost Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If BlockReturnofWithdrawnItems is set to block and an item that is both withdrawn and lost is checked in, Koha will not mark the item as returned but will mark it as found and generate a refund if circ rules allow refunds. To test: - Set BlockReturnofWithdrawnItems to Block - Set BlockReturnofLostItems to Don't Block - Set Default lost item fee refund on return policy to Yes - Check out an item with a replacement cost to a patron - Mark the item as lost - Mark the item as withdrawn - Note that the patron now has a charge for the replacement fee - Check the item in - Note that the patron now has a credit for the replacement fee -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 26611] New: Required match checks don't work for authority records
by bugzilla-daemon＠bugs.koha-community.org 14 Nov '24

14 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26611 Bug ID: 26611 Summary: Required match checks don't work for authority records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The code specifically ignores these for authorities, I am not sure why? While we could easily disable the feature for authority matching to follow current behaviour, I believe we need this functionality to be able to match correctly. Match points check only the first 20 records (see bug 21972) so can only target unique or unique-ish values Match checks allow you to compare specific fields and can verify that matches above are correct. For example: Importing records and checking the 010a - which matches the LC-card-number index can have false matches because the index also contains the 010z - the match check would allow us to compare the specific fields in the records as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 26586] New: Koha should return a SIP2 64 response to a 63 request for fee items
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '24

13 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26586 Bug ID: 26586 Summary: Koha should return a SIP2 64 response to a 63 request for fee items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com At the moment, we're supporting SIP 2.0 for the 63 Patron Information Request, but the 3M SIP2 Protocol Extensions outlines a 7th position "fee items". If a SIP2 client sents a Y in that position, Koha will close the connection. At the very least, it should just return a 64 response and just not send any fee item info back. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 17318] New: Make 'Normalization rule' configurable on matchpoint definition
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '24

12 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17318 Bug ID: 17318 Summary: Make 'Normalization rule' configurable on matchpoint definition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, there's a free text field on matchpoint definition, that is of no use, as the code does some default normalization no matter what you put there (se screenshot). As pointed out on 17304 and other bugs, this normalization routine is counter productive. The purpose of this bug is to introduce a way for defining the normalization rules we'd like to apply. IT will make use of bug 17302 to have a small (but useful) list of normalization routines. This could be expanded if needed, or we could even make plugins do it (that'd certaintly belong to another bug report). I don't think removing the 'feature' is a good move now, but we could consider it with broader discussion. Someone should rise it in koha-devel, meetings, etc. This will provide a way out, until we end that fine-grained discussion. -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 20558] New: typo mts_authorized_value vs mts_authorised_value in admin/marctagstructure.pl
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '24

12 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20558 Bug ID: 20558 Summary: typo mts_authorized_value vs mts_authorised_value in admin/marctagstructure.pl 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org What are the consequences of this? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22258] New: Elasticsearch - full record is not indexed in plain text
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '24

11 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22258 Bug ID: 22258 Summary: Elasticsearch - full record is not indexed in plain text Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Target Milestone: --- This is to start a discussion - at some point we dropped the inclusion of the full record in plain text in the ES index A consequence is that data in a field that is not specifically indexed is no longer searchable. This is a change from zebra I believe where the entire record can be searched. I am not sure of the affect on relevancy, but I think we need t o find a way to support full record searching. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32