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

[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 12 Nov '24

12 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

[Bug 23305] New: Add ability to append to item notes in batch item modification
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23305 Bug ID: 23305 Summary: Add ability to append to item notes in batch item modification Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It'd be useful to be able to append new text onto the end of itemnotes and itemnotes_nonpublic when performing a batch item modification, rather than simply overwriting any existing notes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 28757] New: Allow users to place a reservation when their account is restricted
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28757 Bug ID: 28757 Summary: Allow users to place a reservation when their account is restricted Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: s.graham4(a)herts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Could a new syspref be added to Koha that would allow a user to place a reservation/hold if the user is restricted? We have a lot of students who on placement, and only come on-campus occasionally.They tend to return and collect books at the same time during their visits to campus. If they have a restriction on their account (because they need to return an overdue item) then this stops them from requesting a hold at the same time, and forces them to come on-campus twice (once to return the book, and then next time to collect their reservations) when ideally it could be done with one visit. Stephen -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29697] New: Excessive use of StripNonXmlChars
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29697 Bug ID: 29697 Summary: Excessive use of StripNonXmlChars 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+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We are using C4::Charset::StripNonXmlChars from different places of the code to remove characters that should not be part of the MARC::XML Historically we were removing them every time we were fetching the record. However, since we are starting to use Koha::Biblio::Metadata ($biblio->metadata->record) to retrieve the xml stored in the biblio_metadata table, such characters will not be removed and a degraded view will be displayed on the bibliographic detail page (see bug 23846). We didn't get a lot of complains, and it's part of Koha since 19.05.05. Shouldn't we start to use $biblio->metadata->record where GetMarcBiblio is actually used? Either we assume the MARC::XML that is stored is correct, or we need to add more StripNonXmlChars calls. -- You are receiving this mail because: You are watching all bug changes.

1 171

[Bug 16264] New: Confirm message on deleting an authority framework subfield
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16264 Bug ID: 16264 Summary: Confirm message on deleting an authority framework subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Just using this as an example because it appears in many places on the intranet Is there a reason that we navigate to a new page to confirm or cancel a delete rather than just using a Javascript confirm message? A JS message would use much less code. I realise that in the past we had a rule that everything had to work without JS enabled but a lot of stuff on the intranet wouldn't work at all without JS so I'm not sure how much that applies anymore. Anyway, just wondering if these extra pages for confirm or cancelling a delete are still necessary or if we can do this via JS now :) -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 30194] New: Adapt Koha for JSON::Validator@5.x
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30194 Bug ID: 30194 Summary: Adapt Koha for JSON::Validator@5.x 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: tomascohen(a)gmail.com CC: tomascohen(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 146