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

[Bug 35925] New: Port default purchase suggestion notices to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35925 Bug ID: 35925 Summary: Port default purchase suggestion notices to Template Toolkit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Keywords: roadmap_24_05 Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Blocks: 15278 The following notices relating to purchase suggestions all need to be updated to use Template Toolkit syntax: ACCEPTED AVAILABLE NEW_SUGGESTION ORDERED REJECTED TO_PROCESS Most of these messages are very similar and access the same data, so it makes sense to do them all together. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 [Bug 15278] [Omnibus] Port default slips and notices from bespoke syntax to Template Toolkit -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 14907] Item search: Call Numbers in Item search results are ordered alphabetically
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 37587] New: Wrong priority when placing multiple item-level holds
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37587 Bug ID: 37587 Summary: Wrong priority when placing multiple item-level holds Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: emily.lamancusa(a)montgomerycountymd.gov Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 15565 When placing multiple item-level holds at once, the first hold that is processed is added to the end of the line, but the other holds default to priority 2. They should all be getting added to the bottom of the holds list, not the top. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15565 [Bug 15565] Place multiple item-level holds at once for the same record -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 38409] New: Split expandedSearchOption between OPAC and stafff interface
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38409 Bug ID: 38409 Summary: Split expandedSearchOption between OPAC and stafff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org ExpandedSearchOptions can insert a lot of parameters in Opac for users who just want to display options at staff. ExpandedSearchOptions should be split between StaffExpandedSearchOptions and OPACExpandedSearchOptions to allow user not to complexify OPAC when they need advanced options. ExpandedSearchOptions name should probably be changed by the way. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31312] New: Remove GetItemsInfo from misc/migration_tools/rebuild_zebra.pl
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31312 Bug ID: 31312 Summary: Remove GetItemsInfo from misc/migration_tools/rebuild_zebra.pl 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 Depends on: 31306 Blocks: 27272 Bug 27272 is going to remove C4::Items::GetItemsInfo in favour of Koha::Items->search_ordered. Here we are going to deal with misc/migration_tools/rebuild_zebra.pl Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27272 [Bug 27272] Move C4::Items::GetItemsInfo to Koha namespace https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31306 [Bug 31306] Add Koha::Items->search_ordered method -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[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 38405] New: restrict_patrons_with_failed_notices.pl cronjob should take a --days parameter
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38405 Bug ID: 38405 Summary: restrict_patrons_with_failed_notices.pl cronjob should take a --days parameter Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz The new restrict_patrons_with_failed_notices.pl cronjob uses a Koha::Notice::Messages->get_failed_notices subroutine which takes days as a parameter, but the script hardcodes to 7 days. We should enable the script to take and ues a --days parameter -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 14180] Make "Always show checkouts immediately" a global setting
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '24

08 Nov '24

1 0

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

08 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