Addressing QA lines of feedback has changed the forms. Cypress tests need to be updated accordingly.
cypress run --spec t/cypress/integration/SIP2/Accounts.ts --config video=false,screenshotOnRunFailure=false
cypress run --spec t/cypress/integration/SIP2/Institutions.ts --config video=false,screenshotOnRunFailure=false
cypress run --spec t/cypress/integration/SIP2/SystemPreferenceOverrides.ts --config video=false,screenshotOnRunFailure=false
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This follow-up removes the security vulnerability of storing plaintext
passwords in the sip_accounts table. The SIP2 system now relies entirely
on Koha's secure password authentication.
Changes:
- Remove plaintext password comparison from login_core() and telnet_transport()
- Remove login_password column from sip_accounts table
- Update database schema files and atomic update
- Remove password field from API definitions and Vue form
- Update all tests to remove login_password references
Authentication now works in two stages:
1. Access control: Check if userid exists in sip_accounts (allowlist)
2. Authentication: Validate password against hash in borrowers table
This maintains SIP access control while eliminating plaintext password
storage. Staff users authenticate with their Koha password (securely hashed).
Test plan:
1. Run updated tests to verify they pass
2. Verify SIP2 authentication works with staff user credentials
3. Confirm no plaintext passwords are stored
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
cypress run --spec t/cypress/integration/SIP2/Institutions.ts
cypress run --spec t/cypress/integration/SIP2/Accounts.ts
cypress run --spec t/cypress/integration/SIP2/SystemPreferenceOverrides.ts
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t
Test plan for the whole module:
[MODULE UI TESTING]
1) Checkout the branch and reset_all
2) Run 'updatedatabase'. The contents from
/etc/koha/sites/kohadev/SIPConfig.xml have been migrated to the
database and should be accessible in the UI.
3) Visit the administration page:
http://localhost:8081/cgi-bin/koha/admin/admin-home.pl
4) Notice the new 'Self-service circulation (SIP2)' item under 'Patrons
and circulation'. Click it.
5) Notice you are now on the new SIP2 module. Create some institutions,
accounts, listeners, etc. Play around with the forms.
6) Confirm all the data has been migrated correctly, and is editable in
the UI as expected.
[SIP TESTING]
1) On ktd, run the following SIP emulator command:
$ perl misc/sip_cli_emulator.pl -su koha -sp koha -l kohalibrary --host localhost --patron 42 -m patron_information
2) Note that the response message contains 'Greetings from Koha'.
3) Using the module UI, visit SIP accounts:
http://localhost:8081/cgi-bin/koha/sip2/accounts
4) Find the SIP account that has 'koha' as login. Click edit.
5) Scroll down to 'SIP response mappings' and click 'Add new screen msg regex'.
6) On 'Find', enter 'Greetings from Koha'. On 'Replace', enter 'Hello from 37893 test plan'. Save.
7) Repeat the sip command from 1). Note that 'Greetings from Koha has been replaced with 'Hello from 37893 test plan', without having to restart the SIP server.
[OPTIONAL]
1) You can repeat the previous steps in [MODULE UI TESTING] but edit the contents of
/etc/koha/sites/kohadev/SIPConfig.xml beforehand with a more complex and
thorough configuration (something resembling a real SIPConfig.xml)
2) After updating the contents of SIPConfig.xml, restart SIP:
koha-sip --restart
3) Test the module again, verify the contents have been migrated as
expected.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This test file utilizes the same SIPconfig.xml as the atomicupdate.
To test different SIPConfig.xml configurations using k-t-d, edit the
contents of /etc/koha/sites/kohadev/SIPConfig.xml and run the test file
again. All tests should always pass.
[IMPORTANT]: The atomicupdate file used in this test (bug_37893.pl)
needs to be updated to the respective DBrev file when it's pushed.
prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t
Test plan for the whole module:
1) Checkout the branch and reset_all
2) Visit the administration page:
/cgi-bin/koha/admin/admin-home.pl
3) Notice the new 'Self-service circulation (SIP2)' item under 'Patrons
and circulation'. Click it.
4) Notice you are now on the new SIP2 module. Create some institutions,
accounts, listeners, etc. Play around with the forms.
5) Notice everytime you add/edit a new SIP2 'resource', a prompt asking
to restart the SIP2 server is shown. If you confirm it, it will
restart the SIP server in order for the new data to take effect.
6) Run 'updatedatabase'. Notice the contents from
/etc/koha/sites/kohadev/SIPConfig.xml have been migrated to the
database are should be accessible in the UI.
7) Confirm all the data has been migrated correctly, and is editable in
the UI as expected.
8) You can repeat this test plan but edit the contents of
/etc/koha/sites/kohadev/SIPConfig.xml with a more complex and
thorough configuration (something resembling a real SIPConfig.xml)
9) After updating the contents of SIPConfig.xml, restart SIP:
koha-sip --restart
10) Test the module again, verify the contents have been migrated as
expected.
11) Run the migration test again to ensure that SIP2 is being served the
exact same configuration before and after the migration:
prove t/db_dependent/Koha/SIP2/SIP2ModuleMigration.t
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
They are failing randomly for too long.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds aria-disabled and tabindex = -1 to a breadcrumb, if it
is the current page. This aids in accesssibility, and is generally good
practice.
== TO TEST: ==
a) Visit any page on the OPAC, and inspect the breadcrumb pertinent to
the current page
*) Notice the lack of aria-disabled and tabindex on the inspected
element
== APPLY PATCH ==
b) repeat step a
*) Notice how there is now an aria-disabled and tabindex = -1
*) Notice you cannot tab on to the final breadcrumb anymore
c) Ensure other breadcrumbs are unaffected and still work as links
== SIGN OFF ==
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Adds comprehensive selenium tests for the new functionality where
superlibrarians can manage 2FA settings for other patrons.
To test:
1. Run the existing authentication_2fa.t selenium tests
2. Notice missing coverage for cross-user 2FA management
3. Apply the patch
4. Run the tests again
5. Verify new subtests pass:
- Superlibrarian can view/disable other users' 2FA
- Enable button is hidden with explanatory message
- Non-superlibrarian gets 403 error for other users
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In order to prevent permission errors to user without the 'parameters'
permission we are introducing a separate endpoint for the ERM module to
retrieve additional fields for this specific module.
* Adds a new endpoint /erm/extended_attribute_types
* Adjusts Cypress and REST API tests
* Adds REST API swagger specs
I wanted to keep the code as simple as possible and decided to create a
wrapper for the additional fields API client. The magic is in
koha-tmpl/intranet-tmpl/prog/js/fetch/additional-fields-api-client.js
Ideally we should provide a test for this but I failed to write them.
If required by QA I would suggest to deal with them on a separate bug to
not delay this bugfix. The code has been kept designed to be used in
other contexts but the api client is not used outside of Vue and
outside of the ERM module.
Test plan:
Confirm that user without the 'parameters' permission can use the ERM
module with additional fields.
Sponsored-by: Karlsruhe Institute of Technology (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
cypress run --spec t/cypress/integration/ERM/Dialog_spec.ts
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
prove t/db_dependent/api/v1/patrons_hold_groups.t
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Updates patron format cypress tests to allow for ShowPatronFirstnameIfDifferentThanPreferredname
Test Plan:
-Install Patch
-On command line, in koha root directory, run `cypress run --spec t/cypress/integration/Patron/Format.ts`
-Check to make all tests pass
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We can use the new record_table field to save ourselves a join in here
too.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Failed with:
Failed test 'Context userenv set correctly with no flags'
at t/Koha/Script.t line 31.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
session_id is now part of userenv
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The AuthClient template plugin was causing 500 errors during database
upgrades when the identity_providers schema was out of sync. The plugin
tried to query the new 'auto_register_opac' column before the database
schema was updated, creating a chicken-egg problem.
This patch wraps the database query in Try::Tiny to handle schema
mismatches gracefully during upgrades, allowing the upgrade process
to continue without crashing the authentication interface.
Test plan:
1. On main, apply all bug 37711 patches BUT THIS ONE
2. Simulate an upgrade by:
* Edit Koha.pm so it points to the next version
* Move the atomicupdate file to the right number in db_revs
3. Restart everything:
$ ktd --shell
k$ restart_all
4. Access http://kohadev-intra.localhost
=> FAIL: You get a 500! With a stack trace!
5. Apply this patch
6. Repeat 3 and 4
=> SUCCESS: No 500 error, redirects to installer
7. Proceed with the upgrade:
=> SUCCESS: It works as it should
8. Run tests:
k$ prove -v t/db_dependent/Template/Plugin/AuthClient.t
=> SUCCESS: All tests pass
9. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Before this patches, only OPAC auto-registration at login using
OAuth2/OIDC IdPs was allowed.
This patch makes the staff interface to be able to auto-register new
users.
On doing it, I had to track down the possible values for the `interface`
parameter in the case of the staff interface.
Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked
with it. The whole area needs more param validation and exceptions to
avoid mistakes for not knowing the valid values.
I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers.
They get tested on the added tests.
To test:
1. Apply this patch
2. Run:
$ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t
=> SUCCESS: Tests pass!
3. Have a valid OAuth...
4. Enable Staff auto-register
5. Login with an external IdP on the staff interface
=> SUCCESS: It gets registered!
Note: it will probably lack permissions to access the staff interface,
but you can check on the DB it got registered.
6. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch makes the API representation of the identity providers
domains match the new metadata.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We should not log/leak session_id!
Failed test 'Context set from userenv + interface'
at t/db_dependent/Koha/BackgroundJob.t line 132.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
Looks like you failed 1 test of 10.
Failed test 'enqueue() tests'
at t/db_dependent/Koha/BackgroundJob.t line 135.
Failed test 'Userenv set from job context on process'
at t/db_dependent/Koha/BackgroundJob.t line 240.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
Looks like you failed 1 test of 5.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Failed with:
at t/Koha/Script_cron.t line 28.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
session_id is now part of userenv
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We need to mock userenv
ERROR: Plugin dateaccessioned.pl: Can't use an undefined value as a HASH reference at /kohadevbox/koha/cataloguing/value_builder/dateaccessioned.pl line 30.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In bug 40587 we renamed a variable from $b to $basketno. After rebasing,
the auto-orders blocking code had a bug where it referenced an undefined
variable $b instead of $basketno when checking for PO number conflicts.
This caused warnings: "Use of uninitialized value $Koha::EDI::b in exists"
This patch:
- Renames $b to $basketno throughout the conflict checking code
- Updates test plan from 7 to 8 to match actual subtest count
Test plan:
1. Run prove t/db_dependent/Koha/EDI.t
2. Verify all tests pass without warnings
3. Confirm auto-orders blocking works correctly for duplicate PO numbers
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
With the move to Koha::File::Transports we need to update the tests
introduced in this patchset to match the others by generating a 'local'
transport and using that.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When po_is_basketname is enabled for a vendor, duplicate purchase order
numbers should prevent both automatic ordering (auto_orders) and manual
UI-triggered ordering to avoid conflicts with existing baskets.
This patch implements blocking functionality that:
1. Auto-orders blocking:
- Tracks baskets with PO number conflicts during quote processing
- Skips auto-ordering for baskets with duplicate PO numbers
- Logs clear warnings about blocked baskets
2. UI basket ordering blocking:
- Adds duplicate checking in create_edi_order function
- Returns detailed error information when conflicts detected
- Prevents EDI order creation for conflicting baskets
3. User-friendly error handling:
- Updates basket.pl to handle duplicate PO number errors
- Stays on basket page to display error messages
- Provides clear messaging about conflicts and resolution steps
4. Template messaging:
- Adds clear error message explaining duplicate PO conflicts
- Shows which existing basket uses the same PO number
- Guides users on next steps to resolve the issue
This ensures data integrity and prevents order processing conflicts
while providing clear feedback to users about duplicate PO number
issues.
Test plan:
1. Set up a vendor with EDI account and enable "po_is_basketname"
2. Create a basket with a specific name (e.g., "PO12345")
3. Process an EDIFACT quote that contains the same PO number:
- If auto_orders is enabled: verify the new basket is created but NOT automatically ordered
- Check the logs show "Auto-order blocked" message
4. For UI testing, create another basket manually with the same name
5. Try to generate EDI order via "Generate EDI order" button
6. Verify: Error message appears stating duplicate PO number conflict
7. Verify: Basket remains open (not closed)
8. Verify: Error message shows which existing basket uses the PO number
9. Test with po_is_basketname disabled: verify normal operation continues
10. Test with unique PO numbers: verify orders process normally
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When vendors are configured to use purchase order numbers for basket naming,
the purchase order number should be included in outgoing ORDER messages as
the document message number in the BGM segment for proper EDI workflow continuity.
According to EDIFACT specifications, the purchase order number from incoming
quote messages (RFF+ON segments) should be used as the document message number
in the BGM segment of outgoing ORDER messages, rather than as a separate RFF+ON
segment.
This follow-up ensures that:
1. Purchase order numbers from incoming QUOTE messages are preserved
2. The same purchase order numbers are sent back in ORDER messages via BGM segment
3. Vendors receive the reference numbers they expect for order processing in the
correct format.
Implementation:
- Added get_purchase_order_number() method to extract PO number from basket name
when vendor is configured with 'po_is_basketname'
- Modified beginning_of_message() to accept purchase order number parameter
- Uses purchase order number in BGM segment when available, falls back to basketno
- Added comprehensive tests for purchase order number handling in ORDER messages
Test Plan:
1. Apply patches
2. Configure a vendor EDI account with "Basket name source" = "Purchase order number"
3. Process a QUOTE message containing RFF+ON segment
4. Verify basket is created with purchase order number as name
5. Generate ORDER message from the basket
6. Verify ORDER message contains purchase order number in BGM segment
7. Run tests: prove t/db_dependent/Koha/Edifact/Order.t
This completes the round-trip EDI workflow for purchase order number handling
according to EDIFACT standards: Quote RFF+ON → Basket Name → Order BGM
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When processing EDI quotes with purchase order numbers, validate that the
purchase order number is unique for the vendor to prevent operational
confusion. The validation:
- Checks for existing baskets with the same purchase order number and vendor
- Includes both open and closed baskets in the uniqueness check
- Logs an error with the raw RFF+ON segment and details to the edifact_errors table
- Continues processing (non-blocking) to prevent data loss
- Provides system log warnings for monitoring
The error logging includes:
- Section: Raw RFF+ON segment (e.g., "RFF+ON:orders 23/1")
- Details: Clear description of the duplicate purchase order number issue
This ensures administrators can identify and resolve duplicate purchase order
numbers while maintaining system functionality and audit trails.
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds tests for:
1. RFF+ON (Purchase Order Number) segment parsing in EDIFACT messages
2. Vendor configuration for basket naming preferences
3. Basket naming logic in QUOTE processing
Test coverage includes:
- Message-level RFF+ON segment extraction
- Validation that RFF+ON processing stops at LIN segments
- Multiple RFF segment handling
- Database field storage and constraints
- Basket naming configuration logic
- Fallback behavior when purchase order number unavailable
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
prove t/db_dependent/api/v1/holds.t
Signed-off-by: Phillip Berg <phillip.berg@mainlib.org>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This further rebases on top of 40058 which removed RevertWaitingStatus.
It also fixes a warning where 'eq was being utilized on initialized' coming from sub remove_as_hold_group_target
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If a hold that is a hold group target, i.e. it's 'waiting' or 'in transit', is reverted it needs to remove itself as its own hold group target
Tests added here as well:
prove t/db_dependent/Koha/Hold.t
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The skipping of non target holds was skipping all holds that are part of a hold group which has a target, including the target hold itself. This was wrong. Target holds need to be included as they are considered to be a regular 'found' hold.
Tests that prove the bug and its fix added to:
prove ./t/db_dependent/Koha/Hold.t
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan, k-t-d, patches applied:
1) Apply patches, enable DisplayAddHoldGroups system preference
2) Do a search for 'test':
<staff_url>/cgi-bin/koha/catalogue/search.pl?q=test
3) Click the 'Select all' link at the top of the search results, click the 'Place hold' button.
4) Enter the 'koha' user
5) Pick a pickup location for each of the holds and click 'Place holds'.
6) Visit the 'koha' patron:
<staff_url>/cgi-bin/koha/members/moremember.pl?borrowernumber=51
7) Notice there are 3 holds all part of hold group '1'
8) Check-in one of the items in this hold group: 39999000005578. Confirm hold.
9) Repeat 6). Notice 'Continuous delivery' is now the hold group 'target'.
10) Place a new hold for one of the other 2 'non-target' holds for a different patron. Visit:
<staff_url>/cgi-bin/koha/reserve/request.pl?biblionumber=29
11) Enter 'henry' on the patron input. Pick 'Henry Acevedo (23529000035676)'. Click 'Place hold'. Notice Henry's hold is priority 2. Let's check-in the item for this record: 39999000001310
12) Notice the eligible hold is Henry's, not the koha user's hold. This is because the hold that relates to koha's user is part of a hold group that already has a target so it was skipped. You may confirm the hold.
13) Now let's cancel 'target' hold, visit:
<staff_url>/cgi-bin/koha/members/moremember.pl?borrowernumber=51
14) Click the 'Holds' tab and the red trash icon next to 'Continuous delivery'. Confirm cancellation.
15) Check the holds again, now there's only 2 holds in the existing group.
16) Let's repeat the exercise as before and place a hold for 'Henry' for 'Clean code', visit:
<staff_url>/cgi-bin/koha/reserve/request.pl?biblionumber=114
17) Enter 'henry' and place a hold as before.
18) The 'Clean code' record now has 2 holds: first for 'koha' user and the second for 'Henry'.
19) Now check-in the item for that record. Notice it's the 'koha' user's hold that comes up. This is because it's first in priority and the hold is part of a hold group that does not yet have a target. Confirm hold.
20) Go back to 'Henry' and cancel his holds. Visit:
<staff_url>/cgi-bin/koha/members/moremember.pl?borrowernumber=19
21) Select 'both', click 'Cancel selected'. Confirm cancellation.
22) Visit 'holds to pull':
<staff_url>/cgi-bin/koha/circ/pendingreserves.pl
23) Notice no holds show, even though 'koha' user has a hold that does not yet have an item assigned to it. This hold was skipped because it's part of a hold group that already has a target. To confirm this, disable DisplayAddHoldGroups and refresh 'Holds to pull'. Confirm it shows.
24) The same happens for the 'holds queue' i.e. 'non-target' holds are skipped. To test, with the sys pref still disabled, run the build_holds_queue.pl script:
$ perl misc/cronjobs/holds/build_holds_queue.pl
25) Notice the 'non-target' hold shows, and that is expected if DisplayAddHoldGroups is disabled. Enable DisplayAddHoldGroups and repeat 24. Confirm the hold is gone.
The behavior above works as described for holds that become 'In transit' or 'Waiting'.
Run the updated test files:
prove ./t/db_dependent/Koha/Hold.t
prove ./t/db_dependent/Reserves/HoldGroup.t
Relevant tests worth running to ensure no regressions are added to existing covered functionality:
prove ./t/db_dependent/Circulation*
prove ./t/db_dependent/Hold*
prove ./t/db_dependent/Reserves*
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Enforce no hold group when creating hold object
When a hold is created by build_object, it's auto-assigned a hold_group_id (as expected).
When a hold is ->fill, it's hold_group_id is cleared by cleanup_hold_group (as expected).
The problem is then this causes the object before ->fill to be out of sync with the up to date object returned by the API (i.e. the latter has an empty hold_group_id, as expected, but the former has the auto-assigned hold_group_id).
Using ->discard_changes or ->get_from_storage doesnt work because the became a after ->fill.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. prove t/db_dependent/Koha/Item.t
2. Observe failing test
Subtest: test empty string warning
1..1
not ok 1 - No warnings were produced
Failed test 'No warnings were produced'
at t/db_dependent/Koha/Item.t line 3656.
found warning: Argument "" isn't numeric in addition (+) at /usr/local/lib/x86_64-linux-gnu/perl/5.34.0/DateTime/Duration.pm line 70.
didn't expect to find a warning
Looks like you failed 1 test of 1.
not ok 9 - test empty string warning
Failed test 'test empty string warning'
at t/db_dependent/Koha/Item.t line 3657.
Looks like you failed 1 test of 9.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Lucas Gass
Pedro Amorim
Martin Renvoize
Pedro Amorim
John Doe
Jonathan Druart
Jake Deery
Tomás Cohen Arazi
Matt Blenkinsop
Janusz Kaczmarek
CJ Lynce
Martin Renvoize
David Cook
Lari Taskula