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

[Bug 20646] New: "ILL Request" menu options not displayed when user has superlibrarian permission
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20646 Bug ID: 20646 Summary: "ILL Request" menu options not displayed when user has superlibrarian permission Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com CC: andrew.isherwood(a)ptfs-europe.com, jonathan.druart(a)bugs.koha-community.org, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com Depends on: 7317, 20515 If the user has 'superlibrarian' permission, the menu is missing :( Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317 [Bug 7317] Add an Interlibrary Loan Module to Circulation and OPAC https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20515 [Bug 20515] "ILL Request" menu options displayed when user has no ILL permissions -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 18588] New: Integrate ILL generic_emails in notices system.
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18588 Bug ID: 18588 Summary: Integrate ILL generic_emails in notices system. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.sassmannshausen(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently ILLModule provides a hard-coded (English) email template to request ILLs from 'Partner' Libraries. This template should use the existing notices system to allow the template to be customized and translated. Alex -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 21017] New: Plugins: Allow for post-install configure flag
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21017 Bug ID: 21017 Summary: Plugins: Allow for post-install configure flag 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Some plugins, such as the CLA Check Permissions plugin, require configuring before they can be used. I propose a flag, probably in the plugin's $metadata hashref that indicates whether the plugin should redirect the user to the configure page immediately after installation. This would provide better UX, particularly with plugins that where it's not immediately obvious that configuration is required before use -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 17528] New: Holds to pull: check button Solved by
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '22

07 Nov '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17528 Bug ID: 17528 Summary: Holds to pull: check button Solved by Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: black23(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hello, we really like "Holds to Pull" in Koha. We miss function that bring possibility to set hold as solved. In our case it means that we need often to create transport order and give some signt to others that case is solved. So new column with checkbox "Solved by" name_of_staff and date, time would be nice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 18440] New: tmp_holdsqueue should have a timestamp
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '22

28 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18440 Bug ID: 18440 Summary: tmp_holdsqueue should have a timestamp 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If the holds queue builder doesn't run for some reason (cron job disabled, or job crashes), it's not possible to tell when the last entry was made in tmp_holdsqueue. It would be very nice to have a timestamp available for this. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 19540] New: opac-reserve does not correctly warn of too_much reserves
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '22

26 Oct '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19540 Bug ID: 19540 Summary: opac-reserve does not correctly warn of too_much reserves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When attempting to place more holds than allowed, opac-reserve.pl only checks against the SysPref 'maxreserves' and not the issuingrules 'holdsallowed'. If the issuing rule's limitation is lower than maxreserve, the opac-reserve page shows a message saying you cannot place any more holds but the explanatory message does not show. To reproduce: 0) Set MaxReserve to a high value (50 is default); 1) Set an issuing rule's "Holds allowed" to a low number (1 or 2); 2) Place as many holds as you can (for the corresponding (categorycode, itype, branchcode, etc). When you reach the maximum allowed by the issuing rule, you'll see a message telling you cannot place any more holds, but the explanatory message saying that you cannot place more than %d holds will not show. (It will show "No items available instead". Bug is present on 16.05 and master -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[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 19 Oct '22

19 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 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