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

[Bug 18586] New: Create module to mint RDF subject URIs
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '23

02 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18586 Bug ID: 18586 Summary: Create module to mint RDF subject URIs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In the relational database, we use biblionumber as the ID for bibliographic records, but a triplestore we need to use a RDF URI. So I'm going to put together a module with a little method for minting URIs. While we could just agree on a convention, it probably makes sense to use the convention in the module and then use the module elsewhere to keep things consistent. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 18713] New: Add support for named graphs and rfds:seeAlso to Koha:: RDF
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '23

02 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18713 Bug ID: 18713 Summary: Add support for named graphs and rfds:seeAlso to Koha::RDF Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When I download RDFXML via OAI-PMH, I delete existing named graphs and create new named graphs. This functionality isn't specific to OAI-PMH, so I'm putting it in Koha::RDF. There is also a method for adding rdfs:seeAlso to a $subject and an $object. In my case, I'm linking a Koha record to an imported record. It's a generic relationship though, which will be useful in many other scenarios, so it's going in Koha::RDF too. -- You are receiving this mail because: You are watching all bug changes.

1 54

[Bug 26248] New: Simplify keep_text Javascript function
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '23

02 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26248 Bug ID: 26248 Summary: Simplify keep_text Javascript function Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 The keep_text function in koha-tmpl/intranet-tmpl/prog/js/staff-global.js is functional but not very readable. We can simplify it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 28477] New: INTRANET and OPAC loggers should print to STDERR instead of to file
by bugzilla-daemon＠bugs.koha-community.org 02 Jun '23

02 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28477 Bug ID: 28477 Summary: INTRANET and OPAC loggers should print to STDERR instead of to file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 25284 notes that Plack will fail to start up if the /var/log/koha/<site>/opac-error.log file isn't writeable by the specific Koha Linux user. It has a workaround for chowning all the log files, but that's really not the best way to go. We shouldn't be messing around with the log files that belong to the Apache web server. Instead, we should be printing to STDERR using the Log4Perl logger. For CGI Koha using Apache, that text will wind up in the correct web server log file automatically. For Plack Koha, it would wind up the correct web server log file as well... or thanks to Bug 16357 they'll wind up special log files created and owned by Koha. It's as easy as changing the Log4Perl configuration as follows: FROM: log4perl.appender.INTRANET=Log::Log4perl::Appender::File log4perl.appender.INTRANET.filename=__LOG_DIR__/intranet-error.log log4perl.appender.OPAC=Log::Log4perl::Appender::File log4perl.appender.OPAC.filename=__LOG_DIR__/opac-error.log TO: log4perl.appender.INTRANET=Log::Log4perl::Appender::Screen log4perl.appender.INTRANET.stderr = 1 log4perl.appender.OPAC=Log::Log4perl::Appender::Screen log4perl.appender.OPAC.stderr = 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 22959] New: Using the help feature when in the Patron Category Admin page, should bring user to that section in the manual
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '23

01 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22959 Bug ID: 22959 Summary: Using the help feature when in the Patron Category Admin page, should bring user to that section in the manual Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Target Milestone: --- With the introduction of the new help button opening up the manual in Koha 18.11, clicking on Help when in the patron category set up in the administration module does not bring the user to that portion of the manual, instead it goes to the main page of the manual. It should go here : https://koha-community.org/manual/18.11/en/html/administration.html#patron-… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 32011] New: 2FA - Problem with qr_code generation
by bugzilla-daemon＠bugs.koha-community.org 01 Jun '23

01 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32011 Bug ID: 32011 Summary: 2FA - Problem with qr_code generation Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: major 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 Depends on: 29873 Looks like an major bug is caught by this selenium test: STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...} /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try (eval 541):1 in Selenium::Remote::Driver::__ANON__ (eval 543):2 in Selenium::Remote::Driver::__ANON__ /usr/share/perl5/Selenium/Remote/Driver.pm:1058 in Selenium::Remote::Driver::_execute_command /kohadevbox/koha/t/lib/Selenium.pm:203 in Selenium::Remote::Driver::execute_script t/db_dependent/selenium/authentication_2fa.t:264 in t::lib::Selenium::wait_for_ajax /usr/share/perl/5.32/Test/Builder.pm:334 in main::__ANON__ /usr/share/perl/5.32/Test/Builder.pm:334 in (eval) /usr/share/perl/5.32/Test/More.pm:809 in Test::Builder::subtest t/db_dependent/selenium/authentication_2fa.t:291 in Test::More::subtest # Looks like you planned 7 tests but ran 2.t/db_dependent/selenium/authentication_2fa.t .. 4/5 # Failed test 'Enforce 2FA setup on first login' # at t/db_dependent/selenium/authentication_2fa.t line 291.Error while executing command: unexpected alert open: Dismissed user prompt dialog: [object Object] at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. at /usr/share/perl5/Selenium/Remote/Driver.pm line 356. There is a 500 in the logs: "POST /api/v1/app.pl/api/v1/auth/two-factor/registration HTTP/1.1" 500 That is caused by [ERROR] POST /api/v1/auth/two-factor/registration: unhandled exception (Mojo::Exception)<<Overflow error. version 8 total bits: 1268 max bits: 1232>> It's coming from GD::Barcode, in my understanding we should increase ModuleSize. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29873 [Bug 29873] 2FA: Generate QR code without exposing secret via HTTP GET -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 20568] New: Add API key management interface for patrons
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20568 Bug ID: 20568 Summary: Add API key management interface for patrons 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Bug 20402 implements an Oauth2 server for the client credentials grant. It should be awesome if the patron management interface in Koha provided a way for staff members (and maybe for patron users later) to create and revoke API keys. The work is actually done already, by Julian in the first commit for bug 13920. So we need to recover that patch, adapt it to our coding guidelines and make it work on top of bug 20402! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75

[Bug 21548] New: ILLLIBS patron category / partner_code seems extraneous
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21548 Bug ID: 21548 Summary: ILLLIBS patron category / partner_code seems extraneous Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com The original installation notes created by Alex for ILL (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7317#c20) describe a requirement to create a new patron category with a code ILLLIBS, organisational patrons are then attached to this category and their email address is used for the "Place request with partners" function. However, Koha ships with a patron category called "Inter-Library Loans" (code: IL) which would appear to remove the requirement for an ILLLIBS category to be created. This bug proposes moving away from using ILLLIBS and using the pre-existing IL category instead. Grepping the code for ILLLIBS reveals that it's assumed to exist and will be used as a default code if one is not specified in the <partner_code> element in koha-conf.xml, so modifications will be required. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 27462] New: Number of suggestions includes archived suggestions
by bugzilla-daemon＠bugs.koha-community.org 31 May '23

31 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27462 Bug ID: 27462 Summary: Number of suggestions includes archived suggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 25033, 22784 On the main page the number of suggestions includes archived suggestions. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22784 [Bug 22784] Add the ability to archive purchase suggestions https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25033 [Bug 25033] Counts of suggestions are confusing -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 32372] New: Calculate hold waiting expiration based on days closed
by bugzilla-daemon＠bugs.koha-community.org 30 May '23

30 May '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32372 Bug ID: 32372 Summary: Calculate hold waiting expiration based on days closed 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently the ExcludeHolidaysFromMaxPickUpDelay is an on or off function. This is problematic with libraries that are closed several days in a week. It would be helpful if there were a threshold that could be set for this setting. The question would be, what kind of a threshold? For example, if ReservesMaxPickUpDelay is set to 7, and a pickup library is closed for 4 days in a week, if ExcludeHolidaysFromMaxPickUpDelay does not use the calendar, the expiration on the waiting hold will likely fall on a closed day, and also reduce the number of opportunities to be picked up. However, if ExcludeHolidaysFromMaxPickUpDelay is set to use the calendar, that same library will end up holding the item for more than two weeks to fulfill the 7 days. If ExcludeHolidaysFromMaxPickUpDelay uses the calendar, it would be helpful if there were an option to extend the ReservesMaxPickUpDelay to the closest open day past the closed dates. Perhaps something like MaxReservePickupExtentension, in which if it is blank or set to 0, it does nothing, like Koha does currently, but if it is set to a number of days, it would extend the expiration past the close date to the next open day that falls within the number of days defined. For example, ReservesMaxPickUpDelay is set to 7, and our proposed MaxReservePickupExtentension setting is set to 7 as well, and the pickup library is closed Sunday, Monday, Wednesday, and Friday. The pickup library receives the item on Tuesday, and instead of expiring on the following Monday when they are closed, Koha would look to the next open day (within 7 days past ReservesMaxPickUpDelay), which would be the following Tuesday. If there is no open days within the extra days defined in MaxReservePickupExtentension, it would keep the original expiration date, or more accurately, expire on the last open day before the closed expiration date. I hope that makes sense. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1