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

[Bug 24539] New: Build generic authentication module interface
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24539 Bug ID: 24539 Summary: Build generic authentication module interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Locally, I run a number of custom authentication integrations for Koha, and I've been thinking it would be great if there were a generic authentication module interface. So I've refactored my local OpenID Connect implementation, so that the changes to Auth.pm and opac-auth.tt are very generic, and other authentication modules could easily leverage them without touching Auth.pm or opac-auth.tt. (The latter remains translateable as generic messages are in opac-auth.tt and they are bound to keys passed from the authentication module.) Right now, you invoke a custom endpoint (I have ideas about making those more generic and extensible too) and it passes an object to C4::Auth::checkauth(). The module for that object and some other data are persisted in the logged in user's session. To log off, you just hit the log off button, Koha gets relevant info from the user's session, and runs the authentication module's logout hook. My goal is to make it so that people can rapidly develop authentication modules, and make it easy to swap in and out different modules. (For instance, my local OpenID Connect code works and works reasonable well, but it's not perfect. However, I shouldn't need to touch Auth.pm and opac-auth.tt to improve that code. The improvements should be isolated within the specific authentication module itself.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 25713] New: get_qualified_table_name should be a class method rather than an object method
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25713 Bug ID: 25713 Summary: get_qualified_table_name should be a class method rather than an object method Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org It would be very useful if "get_qualified_table_name" were a class method rather than an object method. That way you should easily get a qualified table name from anywhere in a plugin without having to instantiate a plugin object. The current method could be updated to support either class or object method invocations. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21153] New: Add system preference to hide login box on opac-main.pl
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21153 Bug ID: 21153 Summary: Add system preference to hide login box on opac-main.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There should be a system preference to hide the login box on opac-main.pl, and that system preference should also make it so that the opacmainuserblock can be 12 if opacuserlogin == 1 but the new system preference == 0. I have a lot of people who hide it with CSS, but it means that a lot of front page real estate is wasted with whitespace. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 25794] New: Add PKI/x509/client SSL authentication to REST API
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25794 Bug ID: 25794 Summary: Add PKI/x509/client SSL authentication to REST API Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au It could be useful to add PKI/x509/client SSL authentication to the REST API to ease machine-to-machine interactions. A vendor could set up all their Koha instances to trust certificates signed by the a vendor's certificate authority public key. Then all new API consumers could just get certificates issued by the vendor's CA. That said, I suppose authorization would still be a problem. With Bug 6296, they were still mapping the certificate to a Koha user. And then there's the issue of how to handle revoked certificates. Maybe it is best just to rely on OAuth2 and Basic Auth. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 19168] New: Non-Debian koha-httpd.conf prevents oai.pl from working
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19168 Bug ID: 19168 Summary: Non-Debian koha-httpd.conf prevents oai.pl from working Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The following block in koha-httpd.conf prevents oai.pl from working in a web browser: # Secure internal stuff <DirectoryMatch "__OPAC_WWW_DIR__/.*/(modules|xslt|includes)"> Order deny,allow Deny from all </DirectoryMatch> You get a 403 for /opac-tmpl/xslt/OAI.xslt which prevents the HTML from displaying. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16352] New: Fix spacing for 245$h and 245$c in XSLTs
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16352 Bug ID: 16352 Summary: Fix spacing for 245$h and 245$c in XSLTs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 13381 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381) apparently changed the spacing for the $h and $c subfields, which causes template text to appear concatenated. It's as easy as adding some <xsl:text> </xsl:text> elements after the spans. It looks like it's for both the intranet and the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18585] New: Connect to RDF triplestore
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18585 Bug ID: 18585 Summary: Connect to RDF triplestore 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 order to store RDF data, we need to be able to connect to a triplestore. This enhancement simply allows us to connect to a separate triplestore. -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 24781] New: Parse and build query strings more reliably
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24781 Bug ID: 24781 Summary: Parse and build query strings more reliably Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Throughout the code, you'll see a lot of string mangling to manipulate query strings. Examples from opac-search.pl: $query_cgi = "tag=" . uri_escape_utf8( $tag ) . "&" . $query_cgi; $pasarParams .= '&query=' . uri_escape_utf8($query); $pasarParams .= '&count=' . uri_escape_utf8($results_per_page); $pasarParams .= '&simple_query=' . uri_escape_utf8($simple_query); $limit_cgi_not_availablity =~ s/&limit=available//g if defined $limit_cgi_not_availablity; It would be good to have a more reliable unit-tested way of creating and editing query strings. I have a module called Koha::Util::URL which should be able to help. I'm hoping to put together a patch tomorrow. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17355] New: Allow deletion of authorised value categories
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17355 Bug ID: 17355 Summary: Allow deletion of authorised value categories Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This will be a follow-up to bug 17216 that adds a separate table for authorised value categories. Now that we store them, we need a way to delete accidentally added categories easily. Jonathan wrote about this: - There is no way to delete a category (TODO). But to do so it would be good to have a authorised_value_categories.is_internal field to mark some categories as "cannot be deleted". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 66

[Bug 30796] New: Standardize CRUD HTML forms to use 1 controller
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30796 Bug ID: 30796 Summary: Standardize CRUD HTML forms to use 1 controller 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I would love it if we only had 1 controller for handling the input from CRUD HTML forms. At the moment, we have hundreds of different Perl scripts for CRUD operations where the logic is embedded in the Perl controller scripts and not the underlying Perl model modules. Having so many controller scripts means it's difficult to make system-wide changes. Whether changes are made manually or automatically it, it also increases the chance of errors, since you're having to make so many changes (to Perl code or HTML templates). When you have the 1 standard controller, you can use the same base template, the same base error handling, etc. You take advantage of the DRY principle to make old code easier to maintain and you make it easier to add new code. You can put your base code in a base Perl module, subclass it, and then only make the modifications you need to make for special cases. -- I work on other PHP and Perl projects that use this model and it's so much nicer. Of course, a similar alternative is something along the lines of Bug 30225. I'd be happy for there to be a standard Vue3 based form that used the APIs to handle CRUD. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2