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

[Bug 12044] Checkout should be clearly disallowed before inputting item barcode if a patron's fines will block the transaction
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12044 Andrew Fuerste-Henry <andrewfh(a)dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Checkout should not be |Checkout should be clearly |possible if a patron's |disallowed before inputting |fines will block the |item barcode if a patron's |transaction |fines will block the | |transaction -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31700] New: Do not consider variable strings as translatable strings
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31700 Bug ID: 31700 Summary: Do not consider variable strings as translatable strings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N 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: frederic(a)tamil.fr Some variable strings are present in the .po files and on Pootle, but they should not be translated. I was wondering if there was a way for them not to appear in the translating files/tools. Examples of strings that should not be translated: in xx-XX-staff-prog.po "%s, "dt_created_on": "%s", "dt_modification_time": "%s", "dt_action": "%s" }%s,%s %s ] } %s %s %s %s %s %s [%%~ action_block = ' ' ~%%] %s %s [%%~ action_block = action_block _ ' %s", "dt_owner": " -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 3514] Returning items through patron Details tab doesn't activate all circulation functions
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3514 pierre.genty(a)biblibre.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pierre.genty(a)biblibre.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31697] New: Show patron category names rather than codes on overdue notice & status triggers
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31697 Bug ID: 31697 Summary: Show patron category names rather than codes on overdue notice & status triggers 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: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org On /cgi-bin/koha/tools/overduerules.pl we list patron categories by code and do not show the category names. In most other places we either show both values or just show the name. I'd like to just show the category name on this page. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28287] New: reports execution should stop on execute_query errors
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28287 Bug ID: 28287 Summary: reports execution should stop on execute_query errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org nbe_rows is computed even if execute_query return an error. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 28804] New: 500 Error when running report with bad syntax
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28804 Bug ID: 28804 Summary: 500 Error when running report with bad syntax Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: jstallings(a)tsas.org QA Contact: testopia(a)bugs.koha-community.org In previous versions, running an SQL report with an error (typo, bad syntax) would yield an error page with the problem syntax highlighted. 21.05 returns only a 500 error. Excerpt from plack-intranet-error.log here: https://pastebin.com/0UCYkU46 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 20627] New: Prevent leakages of user permissions to api access tokens
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20627 Bug ID: 20627 Summary: Prevent leakages of user permissions to api access tokens Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, dpavlin(a)rot13.org, julian.maurice(a)biblibre.com, katrin.fischer(a)bsz-bw.de, oleonard(a)myacpl.org, tomascohen(a)gmail.com Depends on: 20568 Blocks: 20612, 20624 Bug #20568 allow users to create API access tokens, but it always associates all a users permissions with that access token and additionally if that user comes to have more permissions down the line those additional permissions are automagically added to the access token as well. This is generally bad practice for access tokens as in general, they should be of a definite scope and any time additional privileges are required the client application should have to ask for them and receive a new token with the additional privileges assigned to it. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20568 [Bug 20568] Add API key management interface for patrons https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20612 [Bug 20612] Make OAuth2 use patron's client_id/secret pairs https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20624 [Bug 20624] Allow switching off the OAuth2 client credentials grant -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 7826] Standardize link for triggering plugins and auto-entry
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '22

06 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7826 --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Maybe as a first small step we could replace the ... with the icon used in the cataloguing editor? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15500] Add FRBRized View to OPAC & Staff Interface Results
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15500 --- Comment #4 from Heather <heather_hernandez(a)nps.gov> --- Oh, Jason, your thoughts are so cataloging-tastic!! (Please note, all my remarks are MARC21-centric.) Authority records have long had a role in this sort of clustering, e.g., see this authority record for The Hobbit by Tolkien: https://lccn.loc.gov/n79102640 And the work record here: http://experiment.worldcat.org/entity/work/data/449428 Every expression of this work will have the authorized 100 field for Tolkien and a 240 10 Hobbit With the 245 field reflecting the transcribed title of the expression. The 100/240 pairing is used (with the cross references in the authority record to facilitate searching) to cluster the expressions (and manifestations) under the work record. (With the 1XX in the bib having the $9 containing the record number of the author/title authority record? And/or the 240 having this $9? I'm not sure how it's currently working--I could look into it & experiment if it's helpful.) But not all works have authority records, and authorities can be a big learning curve. And not all bibs with a 1XX/240 pairing have authority records. If Koha could use the pre-RDA (and early RDA) 1XX/240 pairings to cluster, that would be fabulous. If this could be a simple matter of developer magic, that would be lovely! But, yes, 7XX Linking Entry Fields are wonderful and can also be used!!! It's what they are there for, and where RDA is going--they're going to be used more and m ore. All linking entry links in Koha would have to be functional, but that's another bug(s) and soapbox...:) A 775 is perfect for actual other editions (you cataloger, you, Jason!), but you would sometimes have a 776 ("Additional Physical Form Entry") for ebooks of a book, audiobooks of a book, etc.--that is, e.g., an audiobook would have the 776 linking back to the print book from which it was read, and also a 775 back to the work record--so a bib record would have to be created for the work. This is really easy to do, and I think it would be easier for a lot of libraries to do than to wade into authorities. Because you have to have something to put into the $w of the 775--a record number (for OCLC libraries, its typically an OCLC record number in the corresponding 001 bib record). It would be very possible to automate this--once a bib record set is created of the expressions, and a work bib record is created, the identical 775 could be placed in all the manifestations of the bib. But, then again, wouldn't it be nice if there could be some developer magic that would allow the library to set the matching threshold, and then a search would just cluster the similar bibs together, based on matching 1XX and/or 24X fields? (And absolutely clustering those bibs that have an authority record with corresponding 1XX/240, or 130, or those bibs with 1000% matching 775s?) Cheerio! h2 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 29719] New: onloan dates are cleared from items when importing and overlaying
by bugzilla-daemon＠bugs.koha-community.org 05 Oct '22

05 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29719 Bug ID: 29719 Summary: onloan dates are cleared from items when importing and overlaying Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Check an item out to a paron 2 - Export the item using Tools->Export data 3 - Stage the record for import 4 - Match on 999c and replace items 5 - Import the batch 6 - View the record and note item is checked out and Available 7 - In the DB note the onloan value is now null -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21