Add UNIQUE KEY entries to table definition
The UNIQUE KEY are required as a hold group 'might have' a target hold, not 'has many' target holds.
This update and the other things this patch updates in atomicupdate + kohastructure should fix the error thrown by command:
perl /kohadevbox/misc4dev/run_tests.pl --instance=kohadev --db-password=password --run-db-compare-only --compare-with=HEAD
This command no longer produces any errors.
Also in this patch:
Renamed table from 'hold_group_target_holds' to 'hold_groups_target_holds' and move it alphabetically to be after 'hold_groups' in kohastructure.sql
This is cleaner, as it matches the 'hold_groups' related table, and allows for alphabetical sorting on kohastructure.sql that makes sense i.e. hold_groups is created first, then hold_group_target_holds is created second with an FK to the former.
All of this passes:
prove ./t/db_dependent/Koha/Hold.t
prove ./t/db_dependent/Reserves/HoldGroup.t
prove ./t/db_dependent/Circulation*
prove ./t/db_dependent/Hold*
prove ./t/db_dependent/Reserves*
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>
Hold group target hold:
The hold that is set as the hold group's target. If a hold group has a
hold target, subsequent check-ins that would 'trap' items to the
remaining holds in the group are instead skipped.
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If some installs didn't notice the column was missing (not renamed) we
can still do it now.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We can reach an inconsistent state if the upgrade DB failed and
new_record_id has been created but renamed.
I don't think we should try to recover from this state, but have a
specific error message in this case. We will guide people asking for
help.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Follow the original test plan and compare the resulting tables to:
MariaDB [koha_kohadev]> desc additional_field_values;
+-----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| field_id | int(11) | NO | MUL | NULL | |
| record_id | int(11) | NO | | NULL | |
| value | varchar(255) | NO | | | |
+-----------+--------------+------+-----+---------+----------------+
4 rows in set (0.003 sec)
MariaDB [koha_kohadev]> desc aqbookseller_aliases;
+-----------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+----------------+
| alias_id | int(11) | NO | PRI | NULL | auto_increment |
| vendor_id | int(11) | NO | MUL | NULL | |
| alias | varchar(255) | NO | | NULL | |
+-----------+--------------+------+-----+---------+----------------+
3 rows in set (0.004 sec)
MariaDB [koha_kohadev]> desc aqbookseller_interfaces;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| interface_id | int(11) | NO | PRI | NULL | auto_increment |
| vendor_id | int(11) | NO | MUL | NULL | |
| type | varchar(80) | YES | | NULL | |
| name | varchar(255) | NO | | NULL | |
| uri | mediumtext | YES | | NULL | |
| login | varchar(255) | YES | | NULL | |
| password | mediumtext | YES | | NULL | |
| account_email | mediumtext | YES | | NULL | |
| notes | longtext | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
9 rows in set (0.003 sec)
The Type field should be the only deviation from the previous version,
Null and Extra should be identical.
2. Run perl ../misc4dev/run_tests.pl --run-db-compare-only --compare-with v24.05.00
3. Sign off
Co-authored-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
- Change `RENAME COLUMN <OLD> TO <NEW>` to `CHANGE COLUMN <OLD> <NEW>
<DATATYPE (required for this syntax)>`.
To test (assuming ktd):
1. Checkout upstream/24.11.x
2. Start ktd with `KOHA_IMAGE=24.11-bullseye(-arm64) DB_IMAGE=mariadb:10.3 ktd up
-d`
3. Checkout upstream/main
4. Run updatedatabase in the Koha container
5. Observe the error regarding the unsupported syntax.
6. Tear everything down again: ktd down
7. Repeat 1-2.
8. Once started up, checkout upstream/main
9. Apply the patch on top of it
10. Run updatedatabase in the Koha container
11. Observe a successful upgrade
12. Sign off
Side Note: I tested this against upstream/25.05.x, but this patch is
based on main.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Merging patrons only required edit_borrowers permission
but would result in a patron deletion.
This patch requires a new merge_borrowers subpermission
To test:
1. Give a patron the following permissions
catalogue, edit_borrowers, list_borrowers
2. Log into the staff interface as the patron
3. Do a patron search and select 2 patrons
4. Click merge patron - success - a patron got deleted
5. Apply patch, updatedatabase and restart_all
6. Repeat steps 3 and 4 - you can't
7. Add the new permission for merge_borrowers
8. Repeat steps 3 and 4 - now you can
9. prove t/Koha/Auth/Patrons.t
Sponsored-by: CLAMS
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Anneli <anneli.osterman@koha-suomi.fi>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The default sort order for Koha's patron search includes many columns, some of which are not indexed:
[% CASE 'name-address' %] {
"data":"me.surname:me.preferred_name:me.firstname:me.middle_name:me.othernames:me.street_number:me.address:me.address2:me.city:me.state:me.postal_code:me.country",
Depending on the number of patrons in the database, and the specific configuration of the server, this can end up generating a query that creates a temp table in the hundreds of gigabytes of data or more. Not only does this risk crashing a database server with insufficient disk space, it's also incredibly slow.
We've found a compound index prevents the issue and also makes the search much faster. InndoDB indexes have a fixed maximum length which is too small ( 3072 bytes ) to encompass the full data for all the fields we need to sort by.
The following works well as a comprise to keep the index length within the maximum:
CREATE INDEX idx_borrowers_sort_order ON borrowers (
surname(100), -- 400
preferred_name(80), -- 320
firstname(80), -- 320
middle_name(50), -- 200
othernames(50), -- 200
streetnumber(20), -- 80
address(100), -- 400
address2(75), -- 300
city(75), -- 300
state(40), -- 160
zipcode(20), -- 80
country(40) -- 160
);
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
3) Perform a patron search
4) No change in behvior should be noted!
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Run install or update
Check new preference under Administration
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We needed better idempotency around checking for fields before
attempting to use them during migration and then dropping them.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In the unit test system we reset the database version to 21.11 after
having upgraded a long way past that. The 231200022 update appears not
to be fully idempotent, so we fail running through the upgrade.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In the unit test system we reset the database version to 21.11 after
having upgraded a long way past that. The 221200041 update appears not
to be fully idempotent, so we fail running through the upgrade.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds database migration to move EDI transport configurations
from vendor_edi_accounts to the new file_transports system introduced
in Bug 39190.
Changes:
- Add file_transport_id column to vendor_edi_accounts with foreign key
- Add 'local' transport type to file_transports enum
- Remove old transport fields from vendor_edi_accounts in kohastructure
- Migration script converts existing EDI configurations to file transports
- Handles FILE -> local transport type conversion
Sponsored-by: ByWater Solutions
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
- without patch login to Koha
- edit a biblio and put a wrong ISBN in 020a (010a for unimarc).
- leave the input field (looses focus), no warning
- apply patch and do "reset_all" to make a full re-install.
- edit the biblio again and put an invalid ISBN in 020a (010a for unimarc).
- when you leave the input field you should have a warning saying "invalid ISBN".
- the input field should turn yellow
- you can still save the biblio with a wrong isbn, it is just a warning.
- if you apply the patch on an existing install, you must manually link the value builder to your existing frameworks to get it working.
Signed-off-by: Johannes Reuter <reuter@die-bonn.de>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Run updatedatabase.pl
Check ListOwnershipUponPatronDeletion on Patron preferences tab.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
As suggested by David, this one adds an index on the new column
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
David considered using boolean, but this would catch 'no' and 0 as
truthy. I instead look for common values here more explicitly.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
As pointed out by David.. it's the 942 not the 952 we have this data in.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>