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

[Bug 31188] New: UPC or ASIN from amazon for dvd, music cds image
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31188 Bug ID: 31188 Summary: UPC or ASIN from amazon for dvd, music cds image Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: julie.emond(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, We would like, in the same way as the isbn for books, that the UPC code or the ASIN for amazon enter automatically for the display of images for dvds and music cds. In short for other documents that do not have an isbn. On other request we see that some have briefly talked about it but no solution except to enter the images by hand has been submitted. A gateway between amazon and koha for the UPC code in the same way as we have a gateway for the simagette with an ISBN. Thank you for your help -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 18315] New: authentication and authorization refactoring
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18315 Bug ID: 18315 Summary: authentication and authorization refactoring Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: oha(a)oha.it QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Currently, C4::Auth is responsible to do session management, authentication and authorization. There is no clear separations between them, and the authentication is not modular, making it increasingly harder to maintain and/or introduce no authentication integrations. I was experimenting on this for a while, and I managed to put together few commits in a branch. It started as a proposal, but turned out to be working in _most_ of my tests. here more details: I completely removed any need for CGI and CGI::Session while maintaining a fork-exec aproach to the scripts. (This made it easier to implement Koha::Middleware::Session, Koha::Session::DB and ::KohaCache) Koha::Middleware::Session inject a session object in the Plack request, and invoke Koha::Auth if any authentication tokens are available. Koha::Auth has a list of modules which will be invoked in turn and could be enabled/disabled plack.psgi is changed as well, it has enabled the new Middleware and the applications used are no longer Plack::App::CGIBin but Koha::Middleware::App. here few of the things i want to do to simplify the interaction with the current "legacy" code: I didn't change the scripts or any other module at all, instead I tried to hijack C4::Auth methods to rely on Koha::Session and Koha::Auth. This make it simple to switch back to the previous plack.psgi OR using apache and the normal cgi-bin. authentication should happen upfront, before the script is even started. script will have to verify authorization. authentication MUST be modular, possibly having different systems cooperate. (Some serious discussions must be around this point, especially about accounting and authority) what needs to be done: permissions should be reintroduced. right now permissions are read for the user and set in the template, but no checks are perform on requests. (should be fairly simple to do) reintroduce the code related to shib, cas and any other. more testing, especially for the installer (there is lots of code regarding the web installer which isn't there anymore) -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 36546] New: API yaml validation is slow.
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36546 Bug ID: 36546 Summary: API yaml validation is slow. 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: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org >From an strace it can take up to 6 sec on our servers. Ex: First stat: 07:48:46.941069 (+ 0.000129) brk(0x5641224ad000) = 0x5641224ad000 <0.000018> 07:48:46.941340 (+ 0.000015) stat("/home/koha/src/api/v1/swagger/swagger.yaml", {st_mode=S_IFREG|0644, st_size=30696, ...}) = 0 <0.000010> ... last one 07:48:53.453980 (+ 0.000030) lstat("/home/koha/src/api/v1/swagger/swagger.yaml", {st_mode=S_IFREG|0644, st_size=30696, ...}) = 0 <0.000015> -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 79

[Bug 36958] New: Internal server error when importing MARC file with bad encoding into an order
by bugzilla-daemon＠bugs.koha-community.org 06 May '25

06 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36958 Bug ID: 36958 Summary: Internal server error when importing MARC file with bad encoding into an order Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 167168 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=167168&action=e… Test record in MARC 8 with an encoding error (uses extended character set for Simplified Chinese characters) To reproduce: 1. Go to Cataloguing > Stage Records for Import 2. Upload the attached example file, which is encoded in MARC 8 3. Select the correct encoding and stage the file for import 4. Find or create an open basket in the Acquisitions module 5. Click Add to basket 6. Select From a staged file 7. Select the file that was just staged --> Page crashes with Internal Server Error (or a stack trace if you're testing in KTD) On the other hand, if you return to Cataloguing > Manage Staged Records and import the staged file from there, the import completes and the records are added to the catalog. The badly encoded biblio records can still be viewed (and the biblio detail page displays a warning about the bad encoding). Not sure if it makes sense to allow addorderiso2709.pl to simply import the bad record anyway like manage-marc-import.pl does, or if that would break something else in the ordering process. At the very least it should display an error message instead of crashing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28760] New: Granular restrictions
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28760 Bug ID: 28760 Summary: Granular restrictions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com It would be great if restrictions has more options. It would be great if we could restrict specific item checkouts or holds on a patron, if needed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 35049] New: Add ability to choose which status is included in MaxOpenSuggestions
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35049 Bug ID: 35049 Summary: Add ability to choose which status is included in MaxOpenSuggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org This is following a discussion between me and Aude on https://gitlab.com/koha-community/koha-manual/-/merge_requests/739 A client asked me if their custom status was included in the count for MaxOpenSuggestions. After testing, I found that only "Pending" suggestions were counted. This was fine with my client as it is what they wanted. But Aude raised the question that maybe some libraries might want their custom statuses to be included in the count. My client did ask me in the inital request that if the suggestions with custom statuses were included in MaxOpenSuggestions, if it was possible to "add an exception" to make it not count... I think it depends on the workflow of the library. If the status is s step after the suggestion has been analysed and decided upon, it probably should not count in MaxOpenSuggestions. But if it's a status for open suggestions waiting for analysis by another staff member (for example), it probably should count. I was thinking a system preference might be added, similar to the ILLHiddenRequestStatuses syspref, to let the library choose which statuses count in MaxOpenSuggestions. By default, only 'Pending' counts. To test: 1. Change MaxOpenSuggestions to 2 2. Go to Adminsitration > Authorized values > SUGGEST_STATUS and add a custom status 3. Log in to the OPAC as a patron 4. Make 2 suggestions --> A message should indicate that you cannot make any more suggestions as you have reached the maximum permitted 5. In the staff interface, go to Acquisitions > Suggestions 6. Change the status of one of the suggestions to the custom status 7. Go back to the OPAC --> You should now be able to make a suggestion -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18298] New: Enforce password complexity
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18298 Bug ID: 18298 Summary: Enforce password complexity Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries would want to add the option to Koha to enforce a strong password policy. That policy would mean that passwords should include both upper and lower case characters one or more numbers. -- You are receiving this mail because: You are watching all bug changes.

1 91

[Bug 33985] New: Add the ability to integrate electronic signatures
by bugzilla-daemon＠bugs.koha-community.org 05 May '25

05 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33985 Bug ID: 33985 Summary: Add the ability to integrate electronic signatures Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com A library would like to be able to integrate electronic signatures into Koha. This could be a way that the patron could sign digitally and this signature would be captured in Koha. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 35832] New: Add option to include an email signature on all notices
by bugzilla-daemon＠bugs.koha-community.org 04 May '25

04 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35832 Bug ID: 35832 Summary: Add option to include an email signature on all notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It would be useful to have the option to always include a particular signature on all notices from the system. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 38090] New: The UX for customer notice styling per notice template is confusing
by bugzilla-daemon＠bugs.koha-community.org 02 May '25

02 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38090 Bug ID: 38090 Summary: The UX for customer notice styling per notice template is confusing Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org A couple of people have highlighted now that the adding of a 'Format' section amongst the message transport types in the notice template editor is confusing. The feature itself is also a little misleading as people presumed from the title that it affected print-type notices only, when in fact it affects all notice types when printed. The distinction is subtle, but makes a large difference in expectations. I'm not sure how to proceed here, but I want it recorded as a bug to see if anyone can come up with a cleaner approach for end users. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14