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

[Bug 26344] New: Move translatable strings out of templates into patrons.js
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26344 Bug ID: 26344 Summary: Move translatable strings out of templates into patrons.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 21156 Strings defined in templates for use in autocomplete/patrons.js can now be wrapped in the new translation function. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 27354] New: Translate JavaScript in intranet-tmpl/js
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27354 Bug ID: 27354 Summary: Translate JavaScript in intranet-tmpl/js Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Blocks: 26344 Currently JavaScript files in intranet-tmpl/js are not processed for translation. This makes it impossible to leverage the new I18N tools created by 21156. I don't think there's any reason why this directory should be excluded. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26344 [Bug 26344] Move translatable strings out of templates into patrons.js -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 27028] New: Transfers: hold warning doesn't display patron's name and their branch
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27028 Bug ID: 27028 Summary: Transfers: hold warning doesn't display patron's name and their branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 113641 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=113641&action=e… screenshot-of-the-issue == Test plan == 1. Place a hold (record level in my example) 2. Try a transfer 3. Get a hold warning 4. It doesn't display (at least, not checked everything) the patron's name and their branch. See screenshot-of-the-issue.png The code confirms that it should: Reserve found for [% name | html %] (<a href="/cgi-bin/koha/members/moremember.pl?borrowernumber=[% borrowernumber | uri %]">[% borrowernumber | html %]</a>). [...] [% IF ( reserved ) %]Set reserve to waiting and transfer book to [% branchname | html %]: [% END %] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 19375] New: Show message when transfer is finished by checking in
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19375 Bug ID: 19375 Summary: Show message when transfer is finished by checking in 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: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When book is in transfer and is in transfer and is checked in in target library, the transfer is finished by this operation. It would be nice to have some message about that. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35503] New: Increase 'status' column size in bugslist
by bugzilla-daemon＠bugs.koha-community.org 24 Apr '24

24 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35503 Bug ID: 35503 Summary: Increase 'status' column size in bugslist Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Bugzilla Assignee: jonathan.druart+koha(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com The status column is very narrow and some of our status's start with the same 4 characters which makes it hard to distinguish between them in search results. Could we extend the column width. Reported by Aude and Caroline recently, but also spoken about on IRC a few times -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 31184] New: Add default permissions by patron category
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '24

23 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31184 Bug ID: 31184 Summary: Add default permissions by patron category 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It could be useful to assign default permissions by patron category. (This was pointed out to me by a librarian who had similar functionality in a previous system.) Alternatively, I suppose we could create "permission profiles" and assign those at patron creation time I suppose. The idea being that you set up permissions for certain staff categories (like cataloguing or circulation) and then the staff automatically have their permissions set up and don't require you to manually check all the right checkboxes on a per-user basis. (I suppose role/group-based authorization would cut down even further on having to manually manage so many permissions...although this probably more of a problem for large libraries than small libraries...) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29348] New: GetOtherReserves fails to mark holds as waiting or in-transit
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29348 Bug ID: 29348 Summary: GetOtherReserves fails to mark holds as waiting or in-transit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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 ModReserveCancelAll is called when a hold is cancelled from the waiting holds list This in turn calls GetOtherReserves GetOtherReserves then calls ModReserveMinusPriority which sets the priority to 0 and then calls _FixPriority The problem is that 'found' is still null for the holds - so it is processed by _FixPriority and has its' priority increased by 1 - this prevents it from being marked waiting or in transit by subsequent code This leaves holds in an odd state where they have an itemnumber, but no status - okay for an item level hold - but bad for bib level To recreate: 1 - Place a bib level hold for 3 different patrons on the same bib The first two should be picked up at logged in branch, the third elsewhere 2 - Check-in and confirm the hold 3 - Go to Circulation->Holds awaiting pickup 4 - Cancel the hold - you get a popup asking you to check in the item to process the hold 5 - View the biblio - see that hold has an itemnumber, but no status 6 - Check in the item, confirm the hold, cancel from waiting reserves 7 - View the biblio - third hold has the itemnumber, but no status While we do say in the message "Check this in to process the hold" the code indicates it will start the transfer or set the hold waiting. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21059] New: callback function in OPAC
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21059 Bug ID: 21059 Summary: callback function in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: kyle(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Work to be done: Add the ability to define a callback function when adding an item to an order Define a callback function in intranetuserjs/OPACuserjs to remove items from the cart upon placing an order -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 35565] New: Authority Linker not properly including subfields
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35565 Bug ID: 35565 Summary: Authority Linker not properly including subfields 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: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Not sure if this is a mapping or linker problem. Two authors with the same names, but one has a $c - Titles and other words associated with a name $aHarris, Ken $aHarris, Ken $c(Writer on railroads) In this case the linker is linking titles to Ken Harris that should have been linked to Ken Harris (Writer on railroads) because it did not look at the subfields. To further complicate, the only authority record in the system is for Ken Harris. No authority record exists for Ken Harris (writer on railroads). In other words, the linker should not have linked this particular bibliographic record to anything because it did not appropriately match the existing authority of Ken Harris. These settings are in place: LinkerModule: Default LinkerOptions: broader_headings AutoCreateAuthorities: don't generate RequireChoosingExistingAuthority: don't require AuthorityMergeMode: loose -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 35785] New: Edit search add quotes
by bugzilla-daemon＠bugs.koha-community.org 22 Apr '24

22 Apr '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35785 Bug ID: 35785 Summary: Edit search add quotes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching 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: 22605 Search for e http://localhost:8081/cgi-bin/koha/catalogue/search.pl?q=e Click "Edit this search" Keyword is surrounded with quote "e" Click "Search" => No results match your search for 'kw,wrdl: ""e""'. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22605 [Bug 22605] Adding the option to modify/edit searches on the staff interface -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2