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

[Bug 35760] New: Separate manage_all_funds permission from which funds are available for ordering
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35760 Bug ID: 35760 Summary: Separate manage_all_funds permission from which funds are available for ordering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some large consortia want the ability for some users to be able to manage all funds but only order from their branch's funds/funds they are owners for. Currently if you can manage all funds, you see everything in the dropdown when ordering, which with large systems can be overwhelming. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29268] New: Query used in Koha::Biblio->get_marc_host is incorrect
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29268 Bug ID: 29268 Summary: Query used in Koha::Biblio->get_marc_host is incorrect 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org After digging through this some more in relation to bug 27507 and bug 11175 I have come to the conclusion that I think the searches performed by get_marc_host are too simplistic/incorrect. First of all, both the 773 field and $w subfield are repeatable.. so we need to iterate for subfields as well as the field. Secondly, I don't think the search for (RCI)CN is correct.. this is what would appear in the 773 of the child, not how the 001 would be constructed in the host. What I believe we really need to do is as follows: 1. Iterate through 773 fields. 2. Iterate through subfield w's and looks for one of the following: 1a. (RCI)Controlnumber where the RCI matches the OrgCode syspref 1b. Fully numeric Controlnumber 3. Once we've found the form we're expecting from above iterations (1a in preference to 1b if both exist) jump out of the loops. 3. Produce the search string 'control-number=Controlnumber' for 1b. or `control-number=Controlnumber AND rci=RCI` if 1a is found. It may also be helpful to add the `OR control-number=Controlnumber` search to 1a to account for cases where OrgCode was added to new children but was is missing from the host? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 37547] New: One should be able to disable sending of element set name in z3950 connections
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37547 Bug ID: 37547 Summary: One should be able to disable sending of element set name in z3950 connections Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We've recently had to set up a new z3950 connection to a provider who doesn't support element set names. Koha sends 'F' for full in the element set name field at connection time and so we're faced with an error 24 for all searches against this provider. We should make it configurable what element set name is used.. F, B or none at all. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 19859] New: Add option to return to the search result in authorities
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19859 Bug ID: 19859 Summary: Add option to return to the search result in authorities 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: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, It is imposible to return to hte result search when you edit an authorities in a record. When we want to edit an authorities in a record, we can clic on the tag editor. That option will open a search page. In this search page you can search authorities. If you clic on edit authorities that action will be open into the authorities module. If you clic on save, you stay in authorities module and you don't return on the search page of the tag editor. Because of that, if you had made some changes in the authoritie, you can't clic on choose for linking to the record. To recreate: Go to a record Edit an authoritie with tag editor Search an authoritie with this plugin Choose an authoritie and clic on edit authorities Clic on Save Notice that you still in the authorities modul and you can’t link this authoritie in your record. For make this link you have to "go back" two times ank clic on choose or make this search another time. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 18595] New: Move C4::Members::Messaging to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18595 Bug ID: 18595 Summary: Move C4::Members::Messaging to Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Bug 17499 adds Koha-objects for messaging preferences. -- You are receiving this mail because: You are watching all bug changes.

1 159

[Bug 36454] New: Staff - Provide indication if a patron is expired when creating an ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36454 Bug ID: 36454 Summary: Staff - Provide indication if a patron is expired when creating an ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, rebecca.bradshaw(a)nnuh.nhs.uk, tomascohen(a)gmail.com Creating an ILL request, when staff adds a patron, there is no indication that the patron is expired, if said patron is indeed expired. Part of the problem tackling this, I believe, is that the 'create form' is ILL backend specific, so this should be tackled at each ILL backend level. Having said that, with bug 35570 in the pipeline, we could perhaps consider adding this little enhancement as a follow-up to that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 37478] New: bulkmarcimport.pl can die on bad records
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '25

05 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37478 Bug ID: 37478 Summary: bulkmarcimport.pl can die on bad records Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz bulkmarcimport.pl will die on xml parsing errors when trying to convert the saved metadata (marcxml) back into a MARC::Record object Two cases we have seen are an invalid characters: :9: parser error : PCDATA invalid Char value 31 <controlfield tag="003">aPGcC</controlfield> and invalid/missing subfield: :91: parser error : attributes construct error <subfield code=""">Among nineteenth-century women's rights reformers, Elizab It turns out MARC::Record can read the incoming file - we can convert it to xml to save as metadata, but only on trying to create the record out of the xml do we die. This may point to a bug in MARC::Record -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 36117] New: Can svc/bib_profile be removed?
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '25

05 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36117 Bug ID: 36117 Summary: Can svc/bib_profile be removed? 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Is this used? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25323] New: Patrons can act as their own guarantor
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '25

03 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25323 Bug ID: 25323 Summary: Patrons can act as their own guarantor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When searching for a patron to act as a guarantor, if the guarantee's record is returned it can be selected, therefore becoming his/her's own guarantor. This makes no sense. To reproduce: 1) Create two users, a parent and a child both with the same surname (for example Parent Smith and Child Smith) 2) Edit the child record and under the Guarantor information, use the "Search to add" button to search for a guarantor. 3) Search for Smith. Both Parent Smith and Child Smith will be listed in the results. 4) Select Child Smith and save the user record. Child Smith is now the guarantor for Child Smith. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 37460] New: Skip Issues Seems to Not Work for Subscriptions Using the Publication Date Parts
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '25

02 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37460 Bug ID: 37460 Summary: Skip Issues Seems to Not Work for Subscriptions Using the Publication Date Parts Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 169512 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169512&action=e… pattern With bug 32392, a user can receive an issue and then skip the next issue or multiple issues. However, this does not seem to be working when using the bug [35646] Allows using the publication date parts for serial numbering. It will not skip an issue as instructed. Using this skip issues option for other numbering patterns does work, such as a simple Volume Number Issue. Attaching my Pattern for more clarification -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1