[Bug 42664] New: Changes to SIP2 accounts may not applied immediately
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Bug ID: 42664 Summary: Changes to SIP2 accounts may not applied immediately Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs@lists.koha-community.org Reporter: kyle@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Also, Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #1 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199374 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199374&action=edit Bug 42664: Reload SIP2 configuration in every worker process SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Test Plan: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works 2) Add a new SIP2 account in the staff interface 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #2 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199375 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199375&action=edit Bug 42664: Update SIP2 config timestamp after storing the change Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. Bump the timestamp after the row has been written so it is not advanced ahead of the data it represents. Test Plan: 1) prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t 2) prove t/db_dependent/api/v1/sip2_accounts.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #3 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199376 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199376&action=edit Bug 42664: Unit tests Test Plan: 1) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199374|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199375|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199376|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #4 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199377 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199377&action=edit Bug 42664: Reload SIP2 configuration in every worker process SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Test Plan: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works 2) Add a new SIP2 account in the staff interface 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #5 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199378 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199378&action=edit Bug 42664: Update SIP2 config timestamp after storing the change Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. Bump the timestamp after the row has been written so it is not advanced ahead of the data it represents. Test Plan: 1) prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t 2) prove t/db_dependent/api/v1/sip2_accounts.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #6 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199379 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199379&action=edit Bug 42664: Unit tests Test Plan: 1) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199377|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199378|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199379|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #7 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199393 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199393&action=edit Bug 42664: Reload SIP2 configuration in every worker process SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Test Plan: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works 2) Add a new SIP2 account in the staff interface 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #8 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199394 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199394&action=edit Bug 42664: Update SIP2 config timestamp after storing the change Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. Bump the timestamp after the row has been written so it is not advanced ahead of the data it represents. Test Plan: 1) prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t 2) prove t/db_dependent/api/v1/sip2_accounts.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #9 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 199395 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199395&action=edit Bug 42664: Unit tests Test Plan: 1) prove t/db_dependent/SIP/SIPServer.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 jdemuth@roseville.ca.us <jdemuth@roseville.ca.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jdemuth@roseville.ca.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrew@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199393|0 |1 is obsolete| | Attachment #199394|0 |1 is obsolete| | Attachment #199395|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #10 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 201003 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201003&action=edit Bug 42664: Reload SIP2 configuration in every worker process SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Test Plan: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works 2) Add a new SIP2 account in the staff interface 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #11 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 201004 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201004&action=edit Bug 42664: Update SIP2 config timestamp after storing the change Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. Bump the timestamp after the row has been written so it is not advanced ahead of the data it represents. Test Plan: 1) prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t 2) prove t/db_dependent/api/v1/sip2_accounts.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #12 from Brendan Lawlor <blawlor@clamsnet.org> --- Created attachment 201005 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201005&action=edit Bug 42664: Unit tests Test Plan: 1) prove t/db_dependent/SIP/SIPServer.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org --- Comment #13 from Brendan Lawlor <blawlor@clamsnet.org> --- Test notes: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works To edit min_servers and max_servers: vim /etc/koha/SIPconfig.xml To confirm existing SIP2 account works use the default: /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + For good measure you can confirm patron 23529000035676 has a hold for Gairm. 2) Add a new SIP2 account in the staff interface In Administration > Self-service circulation (SIP2) First setup an Institution with a branchcode. I used CPL. Then set up a patron with user id, password and permissions. I used userid: bob, password: 1234, and superlibrarian permissions. Note: without adding permissions the login will always fail. 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl Example command: /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su bob -sp 1234 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account Remember to add permissions or the login will still fail on this step :) This time I used userid: rita, password: 1234, and superlibrarian permissions 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su rita -sp 1234 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + For good measure you can confirm patron 23529000035676 has a hold for Gairm. 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t This works as described. First time I have used the new SIP account ui. Very cool! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |pedro.amorim@openfifth.co.u |y.org |k CC| |martin.renvoize@openfifth.c | |o.uk -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #201003|0 |1 is obsolete| | Attachment #201004|0 |1 is obsolete| | Attachment #201005|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #14 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 201176 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201176&action=edit Bug 42664: Reload SIP2 configuration in every worker process SIP2 accounts/institutions are stored in the database and the SIP server is supposed to reload its configuration when they change. In practice, after adding or editing a SIP2 account, most SIP worker processes keep serving the old configuration (e.g. new accounts get "SIP access not authorized") until the SIP server is restarted ( I tested multiple times over 30 minutes ). There seem to be two issues: * L1 cache flushed too late. process_request() calls _config_up_to_date() before Koha::Caches->flush_L1_caches(). The SIP parent reads sip2_resource_last_modified into its own L1 cache at startup and never flushes it. Every worker inherits that stale L1, so a worker's first connection compares against the startup-era value instead of the current shared value. * sip2_config_read_timestamp is stored in the shared (memcached) cache, but the configuration it tracks is per-process. When one worker reloads the config from the database, it bumps the shared timestamp, so every other worker then evaluates as "up to date" and never reloads its own stale in-memory config. Test Plan: 1) Configure the SIP server with several worker processes (e.g. set min_servers and max_servers to 5) and confirm an existing SIP2 account works 2) Add a new SIP2 account in the staff interface 3) Without restarting the SIP server, test the new account with misc/sip_cli_emulator.pl 4) Note the login fails 5) Apply this patch 6) Restart all the things! 7) Add another new SIP2 account 8) Without restarting the SIP server test this new account with sip_cli_emulator.pl 9) Note that the new account works! 10) prove t/db_dependent/SIP/SIPServer.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #15 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 201177 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201177&action=edit Bug 42664: Update SIP2 config timestamp after storing the change Koha::SIP2::Object::store bumps the timestamp before SUPER::store, opening a race condition where a worker reloading during db update transaction caches a config that is missing the new row. Bump the timestamp after the row has been written so it is not advanced ahead of the data it represents. Test Plan: 1) prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t 2) prove t/db_dependent/api/v1/sip2_accounts.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #16 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Created attachment 201178 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201178&action=edit Bug 42664: Unit tests Test Plan: 1) prove t/db_dependent/SIP/SIPServer.t Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org> Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pedro.amorim@openfifth.co.u | |k --- Comment #17 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thank you for this important fix and additional testing notes! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |26.11.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 --- Comment #18 from Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> --- Thanks everyone! Pushed to main for 26.11! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42664 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com Version(s)|26.11.00 |26.11.00,26.05.02 released in| | Status|Pushed to main |Pushed to stable --- Comment #19 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- Pushed to 26.05.x for upcoming 26.05.02 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org