Automatically redirect users who try to submit a PR at GitHub to instructions on how to submit patches and close the PR. Better experience for potential new developers (since they get immediate feedback, while still in the flow for submitting the patch).
The sparse checkout of readme is probably required, so that the gh command knows on what repo to work with.
Based on: https://github.com/mozilla-firefox/firefox/blob/main/.github/workflows/close-pr.yml
Signed-off-by: Imani Thomas <imani.thomas@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Add an required patron attribute
2. Go to the patron form ( memberentrygen.tt )
3. Look at the textarea for the required attribute
4. There is unwanted whitespace characters in the textarea
5. APPLY PATCH
6. Try again, the whitespace should be gone.
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Place a hold on many items
2. Change the "Pickup at:" dropdown" to something else
3. Notice the "Pickup location:" dropdowns do not change with it
4. APPLY PATCH
5. Try steps 1 & 2 again. This time the dropdpwns should adjust accordingly
Signed-off-by: Chip Halvorsen <chip.halvorsen@westlakelibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Moving one subfield to another was failing for repeatable fields where
the field to be moved doesn't exist in the first instance. When moving
subfields within the same field type (e.g. 020$z to 020$a), existing
subfield values in fields that didn't contain the source subfield were
being overwritten with values from other fields.
This patch fixes the issue by determining which fields actually contain
the source subfield and only updating those corresponding target fields,
preserving existing values in fields that don't have the source subfield.
The fix adds logic to _copy_move_subfield to:
1. Use field_exists() to identify which fields have the source subfield
2. Pass these field numbers to _update_subfield for targeted updates
3. Preserve all existing functionality while fixing the data loss bug
Test plan:
1. Create a MARC modification template to move 020$z to 020$a
2. Create a record with multiple 020 fields:
- Some with existing $a values
- Some with $z values to be moved
3. Apply the template
4. Verify existing $a values are preserved
5. Verify $z values are moved to $a only in appropriate fields
6. Verify $z subfields are removed after the move
Signed-off-by: Bernard Scaife <bernard.scaife@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This test verifies that when moving subfields between repeatable fields,
existing values in fields that don't contain the source subfield are
preserved.
The test creates multiple 020 fields:
- Some with existing $a values
- Some with $z values to be moved to $a
After applying the move template, it verifies:
- Existing $a values are preserved
- $z values are moved to $a only in fields that had $z
- $z subfields are properly removed after the move
Signed-off-by: Bernard Scaife <bernard.scaife@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The term 'falsy' is a standard JavaScript idiom referring to values
that evaluate to false in boolean contexts (false, 0, '', null,
undefined, NaN). This is widely used in modern JavaScript and is
part of the official ECMAScript specification terminology. I also
believe it is relevant for Perl.
Codespell currently flags 'falsy' as a misspelling, but this is
incorrect as it's legitimate technical terminology used throughout
our JavaScript codebase and documentation.
Changes:
- Add 'falsy' to codespell exceptions/dictionary
- Allows proper use of JavaScript terminology in code and comments
Test plan:
1. Apply patch
2. Run codespell on files containing 'falsy'
=> SUCCESS: No longer flagged as misspelling
3. Verify 'falsy' usage in JavaScript context works correctly
4. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Executing marc_ordering_process.pl will fail to run with the following errors:
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 21: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 23: marc_ordering_process.pl: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 25: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --confirm]: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: --verbose]: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 27: ./marc_ordering_process.pl: No such file or directory
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 29: or,: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 31: 0: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 33: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 35: This: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 36: If: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 38: =head1: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 40: =over: command not found
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: syntax error near unexpected token `newline'
/usr/share/koha/bin/cronjobs/marc_ordering_process.pl: line 42: `=item B<-v|--verbose>'
This is due to an inadvertent newline before the shebang of the script.
Test Plan:
1) Run ./misc/cronjobs/marc_ordering_process.pl
2) Note the error
3) Apply this patch
4) Run ./misc/cronjobs/marc_ordering_process.pl
5) No error!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
1. Create several random patron circ messages with different dates. I used the following sql for my ktd:
-- INSERT INTO messages (borrowernumber, branchcode, message_type, message, message_date)
SELECT
51 AS borrowernumber,
'CPL' AS branchcode,
ELT(FLOOR(1 + (RAND() * 3)), 'L','B','E') AS message_type, -- L=Staff note, B=OPAC, E=Email (adjust to your codes)
CONCAT('Random test message ', FLOOR(RAND()*1000)) AS message,
DATE_ADD(CURDATE(), INTERVAL -FLOOR(RAND() * 1825) DAY) AS message_date -- random day in last ~5 years (5*365)
FROM (
SELECT 1 UNION ALL SELECT 2 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5
UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 UNION ALL SELECT 9 UNION ALL SELECT 10
) AS x;
2. View the patron account and notice that messages are sorted by type, but not by date.
3. Apply the patch and restart_all
4. Refresh the patron account page and clear the browser cache if necessary.
5. View the patron account again and notice that the messages are still sorted by type, but they are also sorted in descending order (newest to oldest).
6. Sign off and have a great day!
Signed-off-by: Jen Tormey <jntormey@dmpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
1. Create a list
2. Sort this list by: title
3. Save
4. Edit the list, changing the the "Sort this list by:" to copyrightdate
5. Try to edit it again to any other type of sort. Save
6. Look again, it is reverted to copyrightdate
7. APPLY PATCH, restart_all
8. Now when you edit the list any value you use in "Sort this list by:" should be retained.
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Go to the Advanced search page
2. Click "More options"
--> Note that the first line in the "Search" section has a drop-down for
operation (and/or/not), but subsequent lines do not. It should be
the other way around. Also, the alignment is strange.
3. Apply patch and refresh page
--> All lines except for the first line now have an op drop-down, and
the alignment looks correct.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Select an existing record and manage items (or create a new record) so that you are on the additem.pl form.
2. Notice that the fields are uneven lengths.
3. Apply the patch. Do a yarn build and restart_all. Clear your browser cache if necessary.
4. Refresh the additem.pl page and notice that the fields are all the same length now.
5. Sign off and have a great day!
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan :
- before patch on ktd, go to http://localhost:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=155
- in the holdings table search for "general" like "General Stacks".
- see that no items appear
- apply patch
- repeat the search
- all items appear now.
Signed-off-by: Mathieu <mathsabypro@gmail.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
Login at OPAC.
Pass an unexisting reserve_id in a opac-modrequest.pl URL.
Verify that you get a 403 redirect.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Without the patch:
-Clicking delete from the Actions button -> delete pops up both a JS alert and a BS confirmation modal. The deletion works.
-Clicking the "Delete item" button that appears when you hover over any cell pops up both a JS alert and a BS confirmation modal. The deletion does NOT work.
-The "Cancel" button in the delete-item-modal does nothing.
2. APPLY THE PATCH:
-Clicking delete from the Actions button -> 1 modal for confirmation. The deletion works.
-Clicking the "Delete item" button that appears when you hover over any cell pops up only a modal confirmation. The deletion works.
-The "Cancel" button in the delete-item-modal properly closes the modal.
Signed-off-by: Jason <jvasche@roundrocktexas.gov>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Writing these I found that transferbook was generating two queue rebuilds - fixed that
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch does two things:
1:
It prevents rebulding the real time holds queue during a checkin if a reserve was found.
The reserve will either:
a - be set to waiting if at correct location and no confirmation - this is fine because we will rebuild the queue when
filling the hold
b - trigger a popup whihc will rebuild the queue when confirming the transfer, or be ignored
2:
It adds a form to ignoring a hold so that we can rebuild the holds queue if we decided not to use the current item
to fill the found hold
To test:
0 - Enable RealTimeHoldsQueue
1 - Place several holds for different libraries on a title
2 - Checkout a copy to a patron at current library (ignore current holds)
3 - Clean up DB so we can see outcomes from next steps:
delete from branchtransfers; delete from background_jobs; update reserves SET found=NULL where found='T';
4 - Check in item, confirm hold
5 - Check background jobs, note two rebuilds of the holds queue
6 - Check item out to previous patron, repeat 3
7 - Check in item, ignore the hold
8 - Check background jobs, note only one rebuild
9 - Apply patch, restart all
10 - Checkout item, repeat 3
11 - Checkin item, confirm hold
12 - Check background jobs, onlt one rebuild of holds queue
13 - Checkout item, repeat 3
14 - Checkin item, ignore hold
15 - Check background jobs, only one rebuild of holds queue
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Same as
commit 64a271992a
Bug 38201: Improve Agreements/Edit tests
It removes the following DT warning in the console
DataTables warning: table id=DataTables_Table_0 - Requested unknown parameter 'status' for row 0, column 4. For more information about this error, please see https://datatables.net/tn/4
related to bug 40809
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit b2a779e12f3ae23e10cba6177f248e12263306f8)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
It removes the following DT warning in the console
DataTables warning: table id=DataTables_Table_0 - Requested unknown parameter 'status' for row 0, column 4. For more information about this error, please see https://datatables.net/tn/4
related to bug 40809
(cherry picked from commit bc0ad04dddbe8e3462238a14b0e9e5caaa3cdfd7)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d5a9d6ebcc8ef5fd5189a3c91df5c0899d440aef)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Statements removed by bug 40051 but reintroduced by a commit earlier
(cherry picked from commit ab8914358f97bd4e78b20490e5741f87e40ebb15)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit 8f93049f404bb6d6b47ccc0d3c1a8a7a3ec03b1a)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit dab18d4a5f1546e79fafee1563276dc851f21e6e)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Happened again with discount
[Vue warn]: Invalid prop: type check failed for prop "modelValue". Expected String with value "1.75", got Number with value 1.75.
at <InputNumber key=1 id="discount" modelValue=1.75 ... >
(cherry picked from commit e44d7ceda0369a44964dd1cb715d53f8740a9556)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Michał Kula
Lucas Gass
Jonathan Druart
Martin Renvoize
Tomás Cohen Arazi
Kyle M Hall
Laura_Escamilla
Emily Lamancusa
Arthur Suzuki
Marcel de Rooy
Nick Clemens
Matt Blenkinsop