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

[Bug 18445] New: Tests in t stumble over Auth's BEGIN block
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '22

19 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18445 Bug ID: 18445 Summary: Tests in t stumble over Auth's BEGIN block Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: gmcharlt(a)gmail.com We should be able to run the tests in t without the database. But if some module loads Auth.pm via C4/Serials or Koha/Virtualshelf directly or indirectly, this will trigger execution of Auth's BEGIN block. This block contains three calls for systempreferences (one from Auth_with_cas). Note that loading Biblio.pm also starts a chain going to Auth.pm. This report changes two use C4::Auth statements into requires. This will prevent or postpone execution of this code. Note also that this will resolve a few failing tests like (Matcher.t and Prices.t) where the schema mock actually was too late and the database was accessed instead of defined fixtures. Along the way we fix a few minor issues in t where database access should be eliminated. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 20116] New: Cache language list
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '22

18 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20116 Bug ID: 20116 Summary: Cache language list 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(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 20115 C4::Languages::getTranslatedLanguages calls _get_language_dirs that list directories to know the available themes. It sounds like we could avoid that and cache it instead. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20115 [Bug 20115] Languages appear in a different order in the footer -- You are receiving this mail because: You are watching all bug changes.

1 78

[Bug 22760] New: cataloging search yields no results if queryparser is on
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '22

17 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22760 Bug ID: 22760 Summary: cataloging search yields no results if queryparser is on Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mikael.olangcay-brisebois(a)inLibro.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- If QueryParser is on and defaultsortorder is set to relevance,dsc, when you do a cataloging search, first page yields results but other pages don't return any results half the time. It also seems to break the sort by popularity, but that is not adressed by this patch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 22407] New: OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object
by bugzilla-daemon＠bugs.koha-community.org 14 Oct '22

14 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407 Bug ID: 22407 Summary: OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object Change sponsored?: --- Product: Koha Version: master 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Example, instead of this: return Koha::Patrons->find( $self->guarantorid() ); We should do this: return Koha::Patron->_new_from_dbic($self->_result->guarantor); This allows us to use prefetch and perform a single query as opposed to multiple queries -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 19064] New: OAI-PMH Records appearing in OAI that can' t be found in OPAC
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '22

12 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19064 Bug ID: 19064 Summary: OAI-PMH Records appearing in OAI that can't be found in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: marrone.patricio(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hello, While harvesting Koha records from the OAI-PMH interface, I found a series of records that can't be accessed using the OPAC interface. That is, the harvester finds a record with an identifier, say http://example.com/cgi-bin/koha/oai.pl?verb=GetRecord&metadataPrefix=oai_dc… that shows the complete record. Trying to link to the OPAC using the biblionumber in the last part of the identifier, say http://example.com/cgi-bin/koha/opac-detail.pl?biblionumber=572 I get a 404 error. I have yet to confirm this, but this might be related to the records being hidden in the OPAC view being leaked into OAI. In that case, I would expect the record to have a deleted status in OAI so that in can be removed from the harvesting results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 19556] New: Added Content ISBN Does Not Match MARC 020
by bugzilla-daemon＠bugs.koha-community.org 04 Oct '22

04 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19556 Bug ID: 19556 Summary: Added Content ISBN Does Not Match MARC 020 Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org This came to my attention with Novelist Select, but it does not appear to only relate to that. Here's what I'm seeing: Issue 1: A MARC record shows the 020 $a as "9780345813602 (hardcover) :" (minus quotes). The Novelist Select section of detail shows as blank. Novelist support reports seeing that they're getting a 9-digit ISBN 034581360. When I inspect the Novelist Select section, Koha appears to be passing 034581360X. <div data-novelist-novelistselect="034581360X"> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15772 mentions that Novelist can't interpret 10-digit ISBNs ending in X and this seems to be consistent with that. Issue 2 (less problematic from a patron perspective): A MARC record shows the 020 $a as "9781408810552" (minus quotes). The Novelist Select section shows the expected results. Novelist support reports getting ISBN 1408810557 This is a valid ISBN for the title, but not the one on the record. When I inspect the Novelist Select section of the details page, Koha appears to be passing 1408810557. <div data-novelist-novelistselect="1408810557"> In both cases above, ISBNs used for Novelist Select are the same as used for gbs-thumbnail-preview, however the cover image is returned in both cases. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 19309] New: Add ReservesMaxPickUpDelay to the Circulation Matrix
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '22

03 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19309 Bug ID: 19309 Summary: Add ReservesMaxPickUpDelay to the Circulation Matrix Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some libraries would love to have the option to specify the ReservesMaxPickUpDelay by itemtype, rather than specify the ReservesMaxPickUpDelay for all items via the system preference. There are times when specific item types like popular or new items, DVD's or even Museum passes may not want to sit on a shelf for 7 days waiting for the patron to pick it up. Versus a non popular item that can wait for 7 days for the patron to pick the item up. Moving ReservesMaxPickUpDelay to the circ matrix would allow the library to choose the patron category and item type providing more flexibility for items waiting to be picked up by the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 19318] New: Add ability to use custom file upload paths
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '22

02 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19318 Bug ID: 19318 Summary: Add ability to use custom file upload paths 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries don't like the hard coded way uploaded files are all put in the same directory with the hash prefixing the file. We should allow uploaded files to retain their original name, and optionally specify a path to upload to I'm imagining we could accomplish this with something along these lines: 1) Add option on file upload page to not add file checksum to the uploaded filename, modify Koha::Upload 2) Modify Koha::Upload to support this option 3) Create new Authorised Value UPLOAD_PATH to define a set of upload paths 4) Add new 'upload path' option to file upload form as a pulldown of defined upload paths 5) Add new column 'file_path' to uploaded_files table 6) Modify Koha::Upload to support the automatic creation and use of custom file upload paths -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 23301] New: Borrower messaging preferences lost when duplicating patron and changing category
by bugzilla-daemon＠bugs.koha-community.org 23 Sep '22

23 Sep '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23301 Bug ID: 23301 Summary: Borrower messaging preferences lost when duplicating patron and changing category Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com To test: - Create a patron and set their messaging preferences to something other than the defaults - Duplicate the patron - Note that their messaging preferences have been maintained - Before saving the new patron, change their category - Note that their messaging preferences reset to the default for their new category -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6