April 2025 - Koha-bugs - lists.koha-community.org

[Bug 38891] New: MARC21 Addition to relator terms in technical notice 2024-10-17
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38891 Bug ID: 38891 Summary: MARC21 Addition to relator terms in technical notice 2024-10-17 Change sponsored?: --- Product: Koha Version: Main 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 https://loc.gov/marc/relators/tn241017rel.html MARC Code List for Relators The following relator has been added to the MARC Code List for Relators list for usage in appropriate fields and elements. Addition: tad [technical advisor] - A person with expertise in a particular field who advises on the convincing portrayal of a subject to add authenticity to a work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 39550] New: RestrictPatronsWithFailedNotices system preference should not be in Patron relationships section
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39550 Bug ID: 39550 Summary: RestrictPatronsWithFailedNotices system preference should not be in Patron relationships section Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I was going to document bug 23295, and noticed the new system preference is under the Patron relationships section. I feel like that's not the right place for it. But there doesn't seem to be a fitting section for it either. Here are some options I thought about 1. Create a "Patron restrictions" section - either with only this one, or we could move a couple of other ones too like useDischarge 2. Place the pref under "General" 2. Place under "Notices and notifications" -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 36431] New: SIP2: Checkin does not show difference between WasTransfered and NeedsTransfer
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36431 Bug ID: 36431 Summary: SIP2: Checkin does not show difference between WasTransfered and NeedsTransfer 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org If you enable AutomaticItemReturn, SIP will trigger an eventual transfer to home branch when checking in. If disabled, it will not but the station receives an alert to notify the user. But the SIP response for both cases is actually the same. The code shows this: if ($messages->{NeedsTransfer}) { $self->{item}->destination_loc($messages->{NeedsTransfer}); $self->alert_type('04'); # send to other branch } if ($messages->{WasTransfered}) { # set into transit so tell unit $self->{item}->destination_loc($item->homebranch); $self->alert_type('04'); # send to other branch } The destination location will be the same in both cases. And the alert number is the same too. How could the SIP station 'know' that the transfer is done already or still needs to? Both SIP responses contains AO holding branch, AQ destination, CT destination and CV 04. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 37273] New: Add ID column to Agreements table in the ERM
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37273 Bug ID: 37273 Summary: Add ID column to Agreements table in the ERM Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Created attachment 168606 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168606&action=e… ERM ID number appended to agreement name When creating an Agreement or License in the ERM, an ID number is added to the agreement or license name. If it is necessary for the ID number to be visible, it should be in a separate column from the name. Having the ID number appended to the name is a little confusing (see example image). Another option is to hide the hide ID number if it is not needed. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 32742] New: Patron's lists are not in alphabetical order
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32742 Bug ID: 32742 Summary: Patron's lists are not in alphabetical order 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the patron module, the list under 'Add to patron list' is not in alphabetical order -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40

[Bug 25019] New: Non standard initialization in ViewPolicy filter
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25019 Bug ID: 25019 Summary: Non standard initialization in ViewPolicy filter Change sponsored?: --- Product: Koha Version: master 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 ViewPOlicy filter has its own method for initializing its values, and then using its variables. This should be homogeneous through the filters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 38647] New: Can't filter holdings table by shelving location
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38647 Bug ID: 38647 Summary: Can't filter holdings table by shelving location Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface 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 In 24.05, libraries can no longer filter the holdings table in the staff interface by shelving location since the Home library column is now a drop-down instead of allowing free text entry. As of 23.11, the filtering was free text instead of a drop-down, which meant that libraries could type a library name *or* a shelving location to filter. Additionally, the holdings table search bar doesn't appear to 'read' shelving locations, so libraries can't use that to pinpoint items with a specific shelving location either. This will likely be moot with Bug 15461 - Add staff equivalent for OpacLocationOnDetail, but in the meantime, it isn't user-friendly for libraries who need that column to filter bibs with many holdings. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 36660] New: Make Authorities 'see from' searches more specific
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36660 Bug ID: 36660 Summary: Make Authorities 'see from' searches more specific Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When searching for an authority, 'see from' unlinked headings show as links that conduct new authority searches. These searches are 'any' and 'contains' searches so they end up being quite wide and unspecific, potentially producing more results than the original search that suggested this 'see from' heading. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 35134] New: cn_browser.pl pop-up size should be configurable
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35134 Bug ID: 35134 Summary: cn_browser.pl pop-up size should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: 1. Use the cn_browser.pl plugin for the 952$o ( call number ) 2. Add or edit an item and select the `...` to the right of the call number field. 3. The pop-up is hardcoded as 500px x 400px pop-up. 4. Some librarians would like to be able to change the size of this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 39540] New: Add a warning in the circ rules page if a plugin overrides rules
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '25

06 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39540 Bug ID: 39540 Summary: Add a warning in the circ rules page if a plugin overrides rules Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Bug 39405 introduces a way for plugins to override Koha's circulation rules-defined calculation. This can be misleading for users looking at the circulation rules matrix but getting different results than expected. There should be some visual sign the rules they are looking at, might not be effective, and the plugin in question should be mentioned. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22