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

[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 7174] Authentication rewriting
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7174 Magnus Enger <magnus(a)libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oha(a)oha.it --- Comment #26 from Magnus Enger <magnus(a)libriotech.no> --- *** Bug 18315 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39850] New: Missing documentation for the plugin system setup
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39850 Bug ID: 39850 Summary: Missing documentation for the plugin system setup Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.wagner(a)desy.de QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, philip.orr(a)lmscloud.de The Koha manual outlines the procedures to setup the plugin system via https://koha-community.org/manual/latest/en/html/plugins.html#set-up This mentions that one should set `<plugins_enable>1</plugins_enable>` in `koha-conf.xml`. However, due to Bug 25672 it seems necessary to also set ``` <plugins_restricted>0</plugins_restricted> ``` if one wants to enable plugin uploads via the browser(?). This setting is not yet documented (It seems that "needs documentation"-flag on Bug 25672 tries to raise the flag here?) Especially, as said setting is given in `koha-conf.xml` way further down it gets easily overlooked and especially to the uninitiated one has a pretty hard time to fiddle it out. (Thanks @cait ;) Equally, ``` <plugins_restart>1</plugins_restart> ``` misses documentation. ``` -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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 14210] Manage staged MARC records deletes replaced item when undoing import into catalog
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14210 --- Comment #16 from Mathieu Saby <mathsabypro(a)gmail.com> --- Major issue signaled 10 years ago :/ Is nobody ready to sponsor a fix ? Could we at least add a warning in the short term ? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14210] Manage staged MARC records deletes replaced item when undoing import into catalog
by bugzilla-daemon＠bugs.koha-community.org 07 May '25

07 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14210 --- Comment #15 from CB <balestrieri(a)monterey.org> --- +1 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14210] Manage staged MARC records deletes replaced item when undoing import into catalog
by bugzilla-daemon＠bugs.koha-community.org 06 May '25

06 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14210 Todd Goatley <tgoatley(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tgoatley(a)gmail.com --- Comment #14 from Todd Goatley <tgoatley(a)gmail.com> --- +1 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 39846] New: Holds Queue Local Holds Priority checks items after an item has been allocated
by bugzilla-daemon＠bugs.koha-community.org 06 May '25

06 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39846 Bug ID: 39846 Summary: Holds Queue Local Holds Priority checks items after an item has been allocated Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com foreach my $request (@$hold_requests) { ... foreach my $item (@$available_items) { ... if ($local_hold_match) if ( exists $items_by_itemnumber{ $item->{itemnumber} } and not exists $allocated_items{ $item->{itemnumber} } and not $request->{allocated} ) { This code checks each item for local holds priority and then goes to the next item if request is already allocated, but we should check earlier in the loop and go to the next request if the first one is already filled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 39844] New: Add problem class to circulation.tt
by bugzilla-daemon＠bugs.koha-community.org 06 May '25

06 May '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39844 Bug ID: 39844 Summary: Add problem class to circulation.tt Change sponsored?: --- Product: Koha Version: Main 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If you look at circ/returns.tt you'll see a bunch of classes like `class="problem ret_refund` or 'problem ret_checkedin', making it easy to target each of those specific problems. circ/circulation.tt returns many of the same messages but does not include the classes. It would be a lot easier to customize if it contained the same classes for each problem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[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