Adding new id "relationship" led to unexpected behaviour
in relationship handling. If one edits patron with
non-patron guarantor and added patron guarantor, non-patron
guarantors relatioship field was set as empty value which is
first option on select field. This patch removes code which
sets relationship select field to use first value of option
automatically when patron guarantor is added.
Also thi patch add missing id to mandatory relatioship field.
To test:
1. Add or edit patron.
2. Add non-patron guarantor for patron and select some value
as their relationship.
3. Then add a patron guarantor.
=> Note that non-patron guarantors relationship is empty.
4. Apply this patch.
5. Repeat steps 1 to 3.
=> Relationship shouldn't change.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit efaa21c80d)
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
In members.js line 112 variable guarantor_relationship is selected
with id "relationship". However id "relationship" is used in
auth-finder-search.inc, not in memberentrygen.tt.
One way to see what kind of effect incorrect selector has (and how I
originally stumbled into this), is to add into "IntranetUserJS" a line
which changes non-patron guarantors relationship default selected value
as other than empty. Script has to change "relationship" instead of
"new_guarantor_relationship" because selector input for patron
guarantors relationship actually uses default selected value from
non-patron guarantors relationship.
This patch changes two things. Firstly it adds id "relationship" to
memberentrygen.tt so that member.js can fetch correct value
to variable guarantor_relatioship. Secondly it changes id "relationship"
in auth-finder-search.tt as "special_relationship" to avoid confusion.
To test memberentrygen.tt:
1. Make sure you have some value(s) in syspref "borrowerRelationship"
e.g. "guarantor".
2. Add following line to "IntranetUseJS": $('.relationship
option:eq(1)').attr('selected', 'selected');
3. Add guarantee patron and note that non-patron guarantors relationship
is now "guarantor".
4. Add patron guarantor and note that relationship value is empty.
5. Apply this patch and refresh page.
6. Repeat step 4.
=> Note that now relationship value is "guarantor".
To test auth-finder-search.inc:
1. Add authority e.g. Chronological Term
2. Modify field 551$a, click "Tag editor" icon from right
3. Searc pop-up is opened.
=> Make sure that field "Special relationship" is highlighted when
you hover mouse over label.
=> Make sure that after performing a search, search value in
"Special relationship" field persists.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
(cherry picked from commit a605c070c7)
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
This patch updates the teams.yaml to include the voted in 25.05
release team.
Test plan
1/ Check against https://wiki.koha-community.org/wiki/Release_Teams
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There is a mismatch in KEY names.
We should use the ones auto-generated by the server, not pass specific
ones.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
- Explicitly set `NOT NULL` constraints for `creation_date` and `modification_date` in `kohastructure.sql` to clarify the implicit behavior of `DEFAULT CURRENT_TIMESTAMP`.
- Adjusted the `modification_date` column definition in the atomic update file to place `NOT NULL` before `ON UPDATE` for consistency.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
- DBIx::Class appears to determine column nullability based on database metadata.
When columns are added via `ALTER TABLE` without explicitly specifying `NOT NULL`,
the metadata may indicate `IS_NULLABLE = "YES"`, causing DBIx::Class to generate
`is_nullable => 1` in the schema files. This behavior might not account for the
implicit `NOT NULL` enforcement of `DEFAULT CURRENT_TIMESTAMP`.
- Adding `NOT NULL` explicitly in the `ALTER TABLE` statements ensures the database
metadata reflects the intended constraints, potentially resolving this issue.
- Additionally, comments in the atomic update and `kohastructure.sql` are aligned
for consistency and clarity.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
17:39:54 koha_1 | # Failed test 'updated_on correctly saved on newly created user'
17:39:54 koha_1 | # at t/db_dependent/Auth_with_shibboleth.t line 319.
17:39:54 koha_1 | # Structures begin differing at:
17:39:54 koha_1 | # $got->[0] = '2024-11-19 16:39:30'
17:39:54 koha_1 | # $expected->[0] = '2024-11-19 16:39:29'
17:39:54 koha_1 | # Looks like you failed 1 test of 54.
We must use t::lib::Dates::compare to compare datetimes in tests.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test were failing because I neglected to store the value in the cache, I was only
adding the cache key
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds tests to verify the cahcing of authority type in LinkBibHeadingsToAuthority
and adjusts other tests to clear the cache when changing marc flavour
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a missing conditional for ADDITIONAL_MATERIALS to the batch checkout table
Test plan:
1. Set a staff member with circ permissions, including FORCE_CHECKOUT
2. Turn on: CircConfirmItemParts, BatchCheckouts, BatchCheckoutsValidCategories (all)
3. Log in as staff member in step 1
4. Attempt to checkout an item with a 952$3 from the batch checkout tab
5. The item with a 952$3 displays, but the copy/text of the materials specified note does not.
6. Do not confirm checkout
7. Apply patch
8. Try again, the materials note should show this time
9. Confirm checkout
10. Success! Item is checked out
Signed-off-by: Catrina Berka <catrina@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This should do the tric: The test output shows that the second
mapping was not found (field 264); also the expected suspect btw.
So adding that here.
Test plan:
Run t/db_dependent/Biblio.t
See also comment28 on bug 19097.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Simulated the above by removing 264c from Koha to MARC mapping.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a library is expecting to have open invoices and does not, they may
want to check the closed invoices. The option to include closed invoices
should be visible in that case - otherwise, it's several extra clicks to
back out into the Acquisitions module and search the invoices.
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Filter out closed invoices by default when receiving.
Test plan:
1.) go to acquisition module and search for a vendor
2.) click on button 'receive shipment'
3.) enter an invoice number and click 'next'
4.) click on button 'finish receiving'
5.) activate the checkbox 'close'
6.) click on button 'save'
7.) Check that your Invoice has been modified. The status is now "Closed on ..." and the checkbox is now 'Reopen'
8.) Click on the link to the vendor to go the vendors page
9.) click on button 'receive shipment'
=> The closed invoice is no longer displayed
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT} Added a html filter for qa tools..
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adjusts the link to cancel jobs to be submitted as a POST with cud-cancel operation
To test:
1 - Stop your long tasks bacground jobs worker
sudo koha-worker --stop --queue long_tasks kohadev
2 - Stage a file for import
3 - Administration -> Manage jobs
4 - See your new job
5 - Click 'cancel'
6 - It didn't work
7 - Apply patch
8 - Browse to jobs again
9 - Click 'Cancel'
10 - Job is successfully cancelled
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Default to KohaAdminEmailAddress if ReplytoDefault is not set
Test plan:
1. Enter a valid email address into ReplytoDefault and
KohaAdminEmailAddress sysprefs
2. Apply patch and restart services
3. Generate a file on your Koha server. Place it in /tmp/test.mrc
4. Manually connect to the SFTP remote host and accept the hostkey
5. Enter Koha shell
6. Run the sftp_file.pl command-line script
./sftp_file.pl --host <your remote hostname> --user <your user> --pass <your password> --upload_dir <your upload directory> --file /tmp/test.mrc --email <your email>
7. Confirm the SFTP was successful
8. Confirm that the email that you received has a from address matching the
ReplytoDefault syspref
9. Empty out the ReplytoDefault syspref and repeat steps 5 and 6
10. Confirm that the new email you received has a from address matching
the KohaAdminEmailAddress syspref
Sponsored-by: Catalyst IT
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
On "Bug 36640: Remove fnAddFilters" I assume that it was only used for
debounce. But actually it was used on this table to add filtering.
This patch adjusts how we deal with the filters on this table, reusing
the standard "add_filters" and "filters_options" parameters of
KohaTable.
It also passes the DT object allowing to use DT's api. Here it is
useful to retrieve the data in the column.
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Might have been broken by the bootstrap 5 upgrade, but not sure.
Not sure why the click does not trigger the modal.
1. Place an order in acquisitions
1.1. Go to Acquisitions
1.2. Click 'Search' next to 'Search vendors'
1.3. Click 'Add to basket' next to 'My basket'
1.4. Search for an existing record (e.g. search for Shakespeare)
1.5. Click 'Add order' next to a result or in the detailed record
1.6. In the item form, choose an item type
1.7. Click 'Add item'
1.8. Choose a fund
1.9. Enter a price in 'Vendor price'
1.10. Click 'Save'
1.11. Click 'Close basket'
1.12. Click 'Yes, close'
2. Receive the order
2.1. Click 'Receive shipments'
2.2. Enter a value in 'Vendor invoice'
2.3. Click 'Next'
2.4. Click 'Receive' next to your order
=> The modal is shown
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
A lot happened, hard to summarize everything.
Basically at this point, we have (among other things):
* fixed bug 38118 (but reintroduced it with bug 36640)
* fixed bug 38436 (the original report was that the is_hidden setting
was no longer taken into effect on the holdings tables)
Here we are trying to deal with making user's previous changes
persistent across the pagination and col vis changes.
Test plan:
Confirm that hiding checkouts in settings hide the columns
Confirm that showing checkouts then change page (*pagination*, so you need
more than 20 items) and confirm that the columns are still the same
Add a callnumber for an item from page 2 and confirm that the column is
hidden on page 1 and shown on page 2
Hide callnumber from the settings and confirm that the column is hidden
on pages 1 and 2
Show callnumber from the holdings page and confirm that the column is
displayed on page 2, go page 1: hidden, go back page 2: displayed.
And certainly way more other things to test, just confirm that the
behaviours with this patch are consistent with what a end user would
expect.
Note for QA/self: this is not very nice as column-visibility.dt event
can change in datatables.js and not impact this one.
Also the following nice sounds good and should be added to datatables.js
+ if (recalc === false) return;
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is too complicated (at least for 24.11.00) to have everything works
in all situations.
This table has this specific "hide when empty" behaviour which
complicated how we deal with/restore the state
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
On the holdings table of the bibliographic record detail page, we have a special
behaviour: we hide columns if there is no data to display. Indeed we have a lot
of column and we want to limit the number of columns displayed.
This behaviour conflicts with "Save state": when the columns are hidden the
state is modified. If you leave the page and come back, the column will stay
hidden, even if the global settings does not have it as hidden and even if the
user didn't explicitly hide it.
We want to implement something correctly to prevent a conflict with those 2
behaviours, but 24.11.00 is coming and we need a quick fix: here we are going to
remove save state for these 2 tables.
Test plan:
Apply this patch, restart_all
Go to the tables settings admin, jump to holdings_table
Notice that "Save configuration state on page change" is turned off by default
Go to catalogue/detail.plbiblionumber=13 (item does not have call number)
=> "Call number" column is not displayed
Edit the item, set a call number
Go to catalogue/detail.plbiblionumber=13 (item has call number)
=> "Call number" column is displayed
Go to the tables settings admin, jump to holdings_table
Turn on "Save configuration state on page change"
Go to catalogue/detail.plbiblionumber=1 (item does not have call number)
=> "Call number" column is not displayed
Edit the item, set a call number
Go to catalogue/detail.plbiblionumber=13 (item does not have call number)
=> "Call number" column is still not displayed
This can be considered a bug, that why we are disabling the feature for this
table.
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: PhilipOrr <philip.orr@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch sync columns_settings.inc for the OPAC-side
It however removes 'api' from datatables.js as it is never used.
'api' was renamed 'kohaTable' on bug 29408 but OPAC was forgotten.
Better to not have to deal with this unused code for now, we will
reintroduce it if needed later.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Make it use bKohaColumnsUseNames as we are building the columns
depending on sysprefs.
Note that the hard-coded list of columns to export is wrong
exportColumns: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12],
Must use .noExport instead.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If the table does not have table settings we should not deal with the
column visibility and not display the 'Columns' button.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Paul Derscheid
Emmi Takkinen
Katrin Fischer
Martin Renvoize
Jonathan Druart
Nick Clemens
Marcel de Rooy
Emily Lamancusa
Alex Buckley
David Cook