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

[Bug 23475] New: Search context is lost when simple search leads to a single record
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '22

07 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23475 Bug ID: 23475 Summary: Search context is lost when simple search leads to a single record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client 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 Bug 19046 made search terms and dropdown preserve in the staff client, however, if one search for a barcode or something that returns a single record the dropdown and box are cleared -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 54

[Bug 23342] New: Branch Transfer Limits branch_transfer_limits.pl DBI to Koha::Object, fix variable semantics
by bugzilla-daemon＠bugs.koha-community.org 07 Sep '22

07 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23342 Bug ID: 23342 Summary: Branch Transfer Limits branch_transfer_limits.pl DBI to Koha::Object, fix variable semantics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com branch_transfer_limits.pl uses DBI SQL statements in the controller. Replace those with Koha::Objects. change branchcode to fromBranch to clarify what is the purpose of the branchcode. Prepare for more BranchTransferLimit authorised value limiting types. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 25643] New: Remove maxreserves syspref
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '22

05 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25643 Bug ID: 25643 Summary: Remove maxreserves syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Unless someone can explain to me how it's not redundant, I think we should remove the maxreserves system preference. The maximum amount of holds (regardless of patron category and can be set in Circulation and fines rules > Default checkout, hold and return policy > Maximum total holds allowed (count). For upgrades, if there is a value in maxreserves, it should be transferred to circulation_rules > max_holds. Not sure what it should do if there is already a value in max_holds... take the biggest? give a warning in the about page? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 26549] New: Show value of global system preferences on subscription form
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '22

02 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26549 Bug ID: 26549 Summary: Show value of global system preferences on subscription form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com If "Number of issues to display to ...:" input fields in the subscription form are left empty, the global values from the *SerialIssueDisplayCount system preferences are used. It would be nice to display a hint about the pref value on the form to help decide if you want overwrite it or not. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 29113] New: Requires code field for additional contents appears unnecessary
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '22

02 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29113 Bug ID: 29113 Summary: Requires code field for additional contents appears unnecessary Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding a HTML customization there is now a new required "Code" field that has to be filled in. Is this really necessary? * The old news editor didn't require this additional field. * None of the HTML customizations is repeatable. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 26874] New: Exclude label layouts without barcodes from selection when printing a barcode batch
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '22

01 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26874 Bug ID: 26874 Summary: Exclude label layouts without barcodes from selection when printing a barcode batch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 7468 adds a great new feature for printing a batch of barcodes! But part of this process is picking which layout you want to print with. If you select a layout that doesn't include a barcode, you get an error: "Some or all of the barcodes in the range you have selected have no corresponding items. If you are using a layout without barcodes, this may result in missing entries or a blank page" Why not just remove any layouts from the dropdown that do not include a barcode? Even if I enter barcode numbers that are in use, if I try to use this tool to print spine labels for them I get an empty sheet. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 23930] New: No permissions SSO login to staff client should redirect to a custom URL
by bugzilla-daemon＠bugs.koha-community.org 29 Aug '22

29 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23930 Bug ID: 23930 Summary: No permissions SSO login to staff client should redirect to a custom URL Change sponsored?: Sponsored Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Presently if a patron tries to login to the staff client and they have insufficient permissions they are re-directed back to the Koha login page with the message: 'Error: You do not have permissions to access this page'. This is fine when the staff client authentication is the native Koha login, but when you have a SSO implemented then logging in via the Koha login page and then being re-directed to a native koha login form does not make sense. We'd like to implement a syspref InsufficientPermissionRedirectURL which the staff client re-directs to if the authenticating patron does not have permission to view the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 28125] New: All OPAC holds blocked when OPACHiddenItems contains incorrect values
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '22

26 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28125 Bug ID: 28125 Summary: All OPAC holds blocked when OPACHiddenItems contains incorrect values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 Depends on: 15448 >From bug 15448, we're now checking OPACHiddenItems to see if something is hidden before we allow a hold on it. However, the manner in which that check is performed causes a problem if the syspref contains incorrect values. To recreate: - make sure OPACHiddenItems is empty - find a holdable item on the OPAC, confirm you can place a hold on it - enter "itemlost: [AB]" in OPACHiddenItems (an incorrect value because itemlost can only contain 1 bit) - confirm your item is not hidden from the OPAC but you are told it is not available for holds You'll see the same behavior if you use an incorrect field name, like "lost" or "itemtype." Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15448 [Bug 15448] Placing hold on specific items doesn't enforce OpacHiddenItems -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 29094] New: Placing holds via SIP2 does not check if a patron can hold the given item
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '22

26 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29094 Bug ID: 29094 Summary: Placing holds via SIP2 does not check if a patron can hold the given item Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When placing holds via SIP2, there is no holdability check. This seems very incorrect. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 26377] New: Clearly label parts of subscription-add.pl that relate to optional item records
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '22

26 Aug '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26377 Bug ID: 26377 Summary: Clearly label parts of subscription-add.pl that relate to optional item records Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com On the first screen of subscription-add.pl, there are several fields that set values to be applied to created items. They're only needed if you are creating item records when receiving serials. It'd be very helpful to move these so that they are all grouped together and clearly labeled. It might even be reasonable to hide them if not set to create item records. These fields relate to the item record: - Call number - Library - Location - item type - item type for older issues -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25