Bug 38010 broke the vendors pages when Koha is running as a Mojolicious application Steps to reproduce: 1. Run `bin/intranet daemon -l http://*:3000/` 2. Point your browser to http://localhost:3000 (replace localhost by the hostname/IP of koha's container, if needed) 3. Go to Acquisitions and search for a vendor. You will get an error 404.
Created attachment 182768 [details] [review] Bug 39980: Fix vendors pages when using Koha as a Mojo app Bug 38010 broke the vendors pages when Koha is running as a Mojolicious application This adds new routes to Koha::App::Intranet to mimic the Apache rewrite rules added in bug 38010. To be able to do that, the CGIBinKoha plugin's code had to be moved to a controller. The logic remains the same. Test plan: 1. Run `bin/intranet daemon -l http://*:3000/` 2. Point your browser to http://localhost:3000 (replace localhost by the hostname/IP of koha's container, if needed) 3. Go to Acquisitions and search for a vendor. You should see the list of vendors. 4. Click on "New vendor" button. Notice the URL changed to .../acquisition/vendors/add. 5. Reload the page. You should still see the form to create a new vendor 6. Verify that you can create a vendor and that you are then redirected to the list of vendors
Created attachment 182769 [details] [review] Bug 39980: Add tests for .../acquisition/vendors* in Mojo context
The tests are not executed inside a DB transaction because when they are, I get the following error: DBIx::Class::Storage::DBI::mysql::_exec_svp_release(): DBI Exception: DBD::mysql::db do failed: SAVEPOINT savepoint_1 does not exist at /home/koha/koha/Koha/Object.pm line 174 Anyone knows how to fix this ?
I had a go at testing, but I can't get it to work for me using KTD. Starting up: bin/intranet daemon -l http://*:3000/ [2025-05-23 20:51:42.98851] [4056] [info] Listening at "http://*:3000/" Web application available at http://127.0.0.1:3000/ Accessing the URL: This site can’t be reached 127.0.0.1 refused to connect. Try: Checking the connection Checking the proxy and the firewall ERR_CONNECTION_REFUSED
(In reply to David Nind from comment #4) > I had a go at testing, but I can't get it to work for me using KTD. You have to point your browser to the KTD container's IP, not 127.0.0.1
Created attachment 182874 [details] [review] Bug 39980: Fix vendors pages when using Koha as a Mojo app Bug 38010 broke the vendors pages when Koha is running as a Mojolicious application This adds new routes to Koha::App::Intranet to mimic the Apache rewrite rules added in bug 38010. To be able to do that, the CGIBinKoha plugin's code had to be moved to a controller. The logic remains the same. Test plan: 1. Run `bin/intranet daemon -l http://*:3000/` 2. Point your browser to http://localhost:3000 (replace localhost by the hostname/IP of koha's container, if needed) 3. Go to Acquisitions and search for a vendor. You should see the list of vendors. 4. Click on "New vendor" button. Notice the URL changed to .../acquisition/vendors/add. 5. Reload the page. You should still see the form to create a new vendor 6. Verify that you can create a vendor and that you are then redirected to the list of vendors Signed-off-by: David Nind <david@davidnind.com>
Created attachment 182875 [details] [review] Bug 39980: Add tests for .../acquisition/vendors* in Mojo context Signed-off-by: David Nind <david@davidnind.com>
Testing notes (using KTD): 1. Step 2 - to find the IP address of the koha docker container: - access a new terminal window on your computer - find the name of the koha container: docker ps (it should be kohadev-koha-1) - find the IP address (for me, it was at the very end of the output - IPAddress): sudo docker container inspect kohadev-koha-1 2. Check that the tests pass: prove t/db_dependent/mojo/acquisition/vendors.t
[FAIL] Koha/App/Controller/CGI.pm SKIP pod_coverage No POD exists SKIP spelling FAIL tidiness File is not tidy, please run `perl misc/devel/tidy.pl Koha/App/Controller/CGI.pm` [FAIL] Koha/App/Intranet.pm SKIP spelling FAIL tidiness File is not tidy, please run `perl misc/devel/tidy.pl Koha/App/Intranet.pm` [FAIL] Koha/App/Opac.pm SKIP spelling FAIL tidiness File is not tidy, please run `perl misc/devel/tidy.pl Koha/App/Opac.pm` [PASS] Koha/App/Plugin/CGIBinKoha.pm [FAIL] t/db_dependent/mojo/acquisition/vendors.t SKIP spelling FAIL tidiness File is not tidy, please run `perl misc/devel/tidy.pl t/db_dependent/mojo/acquisition/vendors.t`
Test Summary Report ------------------- /usr/share/koha/t/db_dependent/mojo/acquisition/vendors.t (Wstat: 256 (exited 1) Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=1, Tests=1, 10 wallclock secs ( 0.03 usr 0.01 sys + 9.59 cusr 0.40 csys = 10.03 CPU) Result: FAIL not ok 4 - Login OK # Failed test 'Login OK' # at t/db_dependent/mojo/acquisition/vendors.t line 35. [etc etc] Auth ERROR: Cannot get_session() at /usr/share/koha/C4/Auth.pm line 1060. => in sub checkauth
Created attachment 184292 [details] [review] Bug 39980: Fix vendors pages when using Koha as a Mojo app Bug 38010 broke the vendors pages when Koha is running as a Mojolicious application This adds new routes to Koha::App::Intranet to mimic the Apache rewrite rules added in bug 38010. To be able to do that, the CGIBinKoha plugin's code had to be moved to a controller. The logic remains the same. Test plan: 1. Run `bin/intranet daemon -l http://*:3000/` 2. Point your browser to http://localhost:3000 (replace localhost by the hostname/IP of koha's container, if needed) 3. Go to Acquisitions and search for a vendor. You should see the list of vendors. 4. Click on "New vendor" button. Notice the URL changed to .../acquisition/vendors/add. 5. Reload the page. You should still see the form to create a new vendor 6. Verify that you can create a vendor and that you are then redirected to the list of vendors Signed-off-by: David Nind <david@davidnind.com>
Created attachment 184293 [details] [review] Bug 39980: Add tests for .../acquisition/vendors* in Mojo context Signed-off-by: David Nind <david@davidnind.com>
Fixed the tidiness but tests pass for me. Can you take another look Marcel ? I believe get_session() without params is not supposed to fail unless there is a problem with the session storage itself
(In reply to Julian Maurice from comment #13) > Fixed the tidiness but tests pass for me. > Can you take another look Marcel ? > I believe get_session() without params is not supposed to fail unless there > is a problem with the session storage itself Still fails with me. Also tried: t::lib::Mocks::mock_preference( 'SessionStorage', 'tmp' );