This patch updates the cn_browser plugin output so that table rows are
highlighted using row classes and in colors which have sufficient
contrast.
To test, apply the patch and set your 952$o tag to use the cn_browser
plugin:
- Administration -> MARC bibliographic frameworks -> BKS -> MARC
Structure -> Tag 952 -> Edit subfields.
- Under the "Full call number" tab (o), set the "Plugin" dropdown to
"cn_browser.pl" and save your changes.
- Go to Cataloging and locate a bibliographic record using the
cataloging search.
- Add or edit items. NOTE: In the testing data there is only one item
with a callnumber and it is "FIC/kas"
- In the "o - Full call number" field, type "FIC" and then click the
plugin editor image.
- You should see the record with the "FIC/kas" call number and a
green row right above it (indicating where an item with
the call number "FIC" would be in the results).
- Revise your search using the form at the top, entering "FIC/kas".
- The record row should now be highlighted in pale yellow.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Gretchen <maxeinergl@gcc.edu>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The news RSS link on the OPAC appears to be invalid when the news
content contains HTML. Users cannot subscribe to the feed using
standard RSS readers or email clients.
To reproduce:
1- Go to Tools -> HTML customizations -> News
2- Click New Entry with the following settings:
2-1- Display location: OPAC
2-2- Publication date: today
2-3- Title: "News test"
2-4- Content: click on <> and paste some HTML code, for example:
<span style="color: #ba372a; font-size: 12pt;">Le Prêt
entre bibliothèques est mis en pause.
Désolés de
l'inconvénients.<br />Merci de votre
compréhension.</span>
3- Save the entry.
4- Go to the OPAC and copy the "RSS feed for system-wide library news"
link.
5- Execute: curl -v
http://opac/cgi-bin/koha/opac-news-rss.pl?branchcode= and copy the
XML output to https://validator.w3.org/feed/ to check the feed.
==> The feed is not valid.
6- Try to create a subscription to this link in an email client (e.g.,
Thunderbird).
==> It does not work, giving the error "Feed URL is not valid".
7- Apply the patch.
8- Repeat steps 5 and 6.
==> The feed is now a valid RSS.
9- Repeat step 7.
==> You can now subscribe to the RSS feed using standard readers
and email clients.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Update the pending offline circulation actions page to link each item
barcode directly to the item details, rather than the biblio record, and
open the links in a new tab.
Add a column to show the last seen date of the items being processed,
with a warning if the item's last seen date is more recent than the
offline circulation action date.
To test:
1. Upload a Koha Offline Circulation (koc) file
(the file attached to this bug can be used if you are using a
sandbox or KTD with the standard sample data)
i. Go to Circulation > Upload offline circulation file
ii. Upload the file
iii. Click "Add to offline circulation queue"
2. Go to Circulation > Pending offline circulation actions
3. Click on the item barcodes in the table
--> Note that each barcode links to the biblio record, and navigates
away from the page within the same tab.
4. Apply patch and restart_all
5. Return to (or refresh) the pending offline circulation actions page
and click on the item barcodes again
--> The barcodes now open the item details page in a new tab
--> There is a new column for the item last seen date
6. Without processing the offline circulation actions, check in one of
the items listed in the table
7. Return to the Pending offline circulation actions page
--> Confirm that the last seen date of the item you just checked in is
highlighted in red with a warning icon, since its last seen date is
newer than the offline transaction date
8. Hover over the warning icon
--> Confirm that a tooltip appears with an explanation of why the date
is in red
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Queries that use OR instead of IN are less efficient and can lead to
situations where the query takes a very long time to complete due to
row level scanning. We found one instance where they query had been
running for over 10 days!
This patch makes ids() return a subquery instead of a list of results,
and switches the callers to using IN. The database now resolves the set
itself and the queries stay a constant size no matter how large the
catalog is. This is super efficient because the subquery doesn't even
execute as a separate query since biblionumber is the primary key!
Test Plan:
1) Apply the unit tests patch
2) prove t/db_dependent/Koha/Database/DataInconsistency.t
3) Note the ids() subtest fails
4) Apply this patch
5) prove t/db_dependent/Koha/Database/DataInconsistency.t
6) Note all tests pass!
7) Run misc/maintenance/search_for_data_inconsistencies.pl
8) Note the output is the same as before the patch
9) Bonus: Re-run it with DBIC_TRACE=1 and note the queries now use
IN (SELECT ...) instead of one OR clause per bib!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
t/db_dependent/Holds.t, t/db_dependent/ILSDI_Services.t, and
t/db_dependent/api/v1/holds.t all fail if a site has a global
'Holds Allowed (Daily)' circulation rule configured, because
C4::Reserves::CanItemBeReserved checks holds_per_day before
holds_per_record/reservesallowed, so an ambient daily-cap rule
returns tooManyReservesToday and masks the status these tests
actually exercise (tooManyReserves, noReservesAllowed, OK, or the
API's hold_limit override). The affected subtests never set
holds_per_day themselves, so they unintentionally depend on the
database having no such rule configured.
Test plan:
1. On a fresh db, set a global 'Holds Allowed (Daily)' circulation
rule (Administration > Circulation and fine rules) to 1.
2. prove t/db_dependent/Holds.t t/db_dependent/ILSDI_Services.t
t/db_dependent/api/v1/holds.t
=> fails before this patch, passes after.
3. Remove the circulation rule and re-run the same tests.
=> still passes (no regression for the default/unconfigured case).
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If stateSave is turned on and one of the option has a value with _id set
to an Integer, toLowerCase is not available and a JS error is raised:
Uncaught (in promise) TypeError: this._id.toLowerCase is not a function
Test plan:
1.) Admin - table settings: cgi-bin/koha/admin/columns_settings.pl#eholdings|packages
Activate checkbox "Save search state on page change"
2.) Go to ERM : cgi-bin/koha/erm/eholdings/local/packages
And create two packages:
- One package with My Vendor assigned.
- One package without a vendor.
3.) Filter the package results list by My Vendor. --> List is filtered to one package
4.) Leave the page, for example by navigating to Agreements.
Return to the Packages list and you will see the issue (See also attached Screenshot)
=> Without the patch
The package results list becomes unresponsive / hangs after returning to the page.
=> With the patch
The package results list should load and display the filtered results correctly.
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>
To test:
1. Have some overdues
2. Go to circ/overdue.pl
3. Notice the the 'Patron' column the name is prefixed with the biblio title
4. This is meant to be the borrowertitle
5. APPLY PATCH, restart_all
6. Now you should see only the borrower/parton name and info.
7. Edit the patron and add a " Salutation"
8. In the overdue report this should now display
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The log viewer results table uses "Return" for "Check-in" actions.
See the terminology list:
https://wiki.koha-community.org/wiki/Terminology#C
Test plan:
1. Check out an item to a patron, then check it back in again.
2. Go to the log view (Tools > Additional tools > Log viewer).
3. Click "Submit".
4. Note that the action column for the results shows "Return".
5. Apply the patch.
6. Refresh the log viewer page.
6. Note that the action column now correctly shows "Check-in".
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the koha-create command to generate the random encryption key
using pwgen with the number of characters set to 32.
Test plan:
1. In ktd, create a new instance:
- sudo koha-create --create-db test1
- Check the /etc/koha/sites/test1/koha-conf.xml file and verify that the encryption_key
is having the placeholder text '__ENCRYPTION_KEY__'
2. Apply the patch and copy the new koha-create command
- git bz apply 42861
- sudo cp /kohadevbox/koha/debian/scripts/koha-create /usr/sbin/koha-create
3. In ktd, create a new instance:
- sudo koha-create --create-db test2
- Check the /etc/koha/sites/test2/koha-conf.xml file and verify that the encryption_key
is generated and has 32 characters random string.
4. Sign-off
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When you edit an already received serial from Serial collection page
using Edit serials and edit items buttons, and try to save a barcode
that already exists on another item, saving leads to Error 500.
There is no barcode validation for editing serials, this patch adds it.
To test:
1. Go to serials module.
2. Search for a serial that is not expired to edit and click on the title.
3. Go to Serial collection from the menu.
4. Use the checkboxes to mark an already received (eg. usually older,
arrived, not expected) serial and click Edit serials.
5. Click on Edit item.
6. Replace the barcode with a unique barcode that is already in use
and hit save.
=> Error 500 is raised.
7. Apply this patch and restart services.
8. Attempt to save serial with already used barcode again.
=> A standard Koha error message is displayed stating that barcode
must be unique.
Sponsored-by: Koha-Suomi Oy
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>
This patch checks for waiting or in_transit items allocated to recalls, and excludes them from the Holds to Pull report.
To test:
1. Enable UseRecalls and set the recalls-related circulation rules
2. Check out an item to Patron A
3. Place an item-level hold on the item for Patron B
4. Log into the OPAC as Patron C and search for the item. Place an item-level recall on the item.
5. Go back to the staff interface and check in the item. This should prompt a pop-up to confirm the recall as waiting. Confirm the recall as waiting.
6. Go to Circulation -> Holds to pull.
7. Notice that even though the item is allocated for a recall, the hold is showing. It should not be showing in this page.
8. Apply the patch, restart services and refresh the page
9. The item allocated to a recall should no longer be showing in the Holds to pull report
10. Go to the record detail page and go to the Recalls tab
11. Revert the recall from its waiting status
12. Go back to the Holds to pull page. The record will now show for the hold.
13. Go to the Circulation -> Check in page
14. Go to the menu in the top-right of the page and click Set library
15. Change your library to a different one
16. Check in the item to confirm the recall as waiting and trigger a transfer
17. Go back to the Holds to pull page
19. The item should no longer show on the Holds to pull report
20. Confirm tests pass t/db_dependent/Koha/Holds.t
Sponsored-by: Catalyst IT
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When one tries to transfer an item that could fill a pending hold
to a library that is not the holds pickup library, Koha gives only
a option to transfer item to pickup library. This patch adds
new option to ignore hold and transfer item to the library user
selected in transfer tool.
To test:
1. Log into Library A.
2. Find or create a biblio with 1 holdable item at Library A.
3. Place a hold for the biblio with pickup at Library B.
4. Navigate to Circulation > Transfers.
5. Attempt to transfer item to Library C.
=> Note that Koha only allows to transfer item to Library B,
cancel hold and attempt transfer or return to the transfer tool.
6. Apply this patch.
7. Attempt to transfer item again.
=> Note that there is now an option to ignore the hold and transfer
item to Library C.
=> When option to transfer item to the Library C is selected, confirm
that Koha tells that transfer was made to Library C and a new transfer
was made to database.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When one tries to transfer an item that could fill a pending hold
to a library that is not the holds pickup library, Koha gives only
a option to transfer item to pickup library. When this option
is chosen, Koha tells that item is being transfered to selected
library not to pickup library but fails to create the transfer.
This patch fixes this by setting op variable as "cud-transfer"
and tobranchcd as holds pickup library so that transfer is actually
made and target library is displaued correctly.
To test:
1. Log into Library A.
2. Find or create a biblio with 1 holdable item at Library A.
3. Place a hold for pickup at Library B.
4. Navigate to Circulation > Transfers.
5. Attempt to send your item to Library C.
6. Koha gives you three options. Pick the first one:
"Transfer to Library B."
7. Koha tells you it has transferred the item to Library C.
8. Go to detail.pl for your title, confirm the holdings table
says "there is an item level hold" on your item.
9. Click to the Holds tab for your title, confirm the hold claims
to be in transit.
10. Query the branchtransfers table
SELECT * FROM branchtransfers WHERE itemnumber = [your item]
=> Note that no new transfer was made.
11. Query reserves SELECT * FROM reserves WHERE biblionumber = [your biblio]
=> Confirm your hold has found=T, itemnumber=[your item], and item_level_hold=0
12. Revert trasfer from biblios holds page.
13. Apply this patch.
14. Attempt the transfer again.
=> Koha should now tell that transfer was made to Libary B.
15. Check branchtransfers table again.
=> New transfer should have been made to Library B.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Bug 21820 made the Zebra queue update conditional on the new
ElasticsearchEnableZebraQueue system preference, which defaults to off.
The 'basic_quote_processing' subtest in t/db_dependent/Koha/EDI.t counts
the log lines process_quote emits, and two of those are the
"specialUpdate biblioserver" traces that ModZebra logs only when the
Zebra queue path runs. When the SearchEngine preference is set to
Elasticsearch, that path no longer runs by default, so the subtest now
records 6 log lines instead of 8 and fails:
# Failed test '8 log lines recorded for passed quote file'
# got: '6'
# expected: '8'
# Failed test 'Trace recorded biblioserver index'
Test Plan:
1) Set the SearchEngine system preference to 'Elasticsearch'
2) prove t/db_dependent/Koha/EDI.t
3) Note the basic_quote_processing subtest fails with "got: '6', expected: '8'"
4) Apply this patch
5) prove t/db_dependent/Koha/EDI.t
6) Note the tests pass!
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>
Test plan:
1) Install another language
2) Navigate to a vendor record
3) The group names should translate correctly and display in the split screen view
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Koha::File::Transport::FTP::_list_files parsed the LIST / "ls -l" output
with a non-greedy date capture that only consumed the first of the three
date tokens (the month), leaving the day and time glued to the front of
the filename. Every filename returned for an FTP transport was therefore
prefixed with the listing date, e.g.
-rw-r--r-- 1 user group 1234 Jan 01 12:00 QUOTES_413514.CEQ
=> filename "01 12:00 QUOTES_413514.CEQ"
Callers (Koha::Edifact::Transport, marc_ordering_process.pl) then asked
the server for a file that does not exist, so no files were downloaded,
renamed or deleted over FTP. SFTP and Local transports were unaffected.
This regressed when the EDI transport was moved onto the file_transports
system (bug 38489). The previous Koha::Edifact::Transport::ftp_download
listed files with Net::FTP->ls (NLST, bare names); the refactor switched
to Net::FTP->dir (LIST) so it could return the richer hashref shape used
by the SFTP and Local transports, but the parse was faulty.
The date field in "ls -l" output is a fixed run of three whitespace
separated tokens (Mon DD HH:MM or Mon DD YYYY). Consume it explicitly so
the filename is captured cleanly, preserving spaces and still skipping
directories. The LIST-based approach and the filename/longname/size/perms
return shape are kept so the structure stays consistent across transport
classes (relied on by consumers, including out-of-tree ones).
Test plan:
1) prove t/db_dependent/Koha/File/Transport/FTP.t
2) git checkout Koha/File/Transport/FTP.pm and re-run: the list_files()
subtest fails on the filename/size/perms assertions
3) prove t/db_dependent/Koha/Edifact/Transport.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
holds.js declared `coded_values` as a bare top-level global, evaluated
immediately at script-parse time, reading `all_libraries` which is only
ever defined by the including template (request.tt, or
patron-detail-tabs.inc for circulation.tt/moremember.tt). This works
today only because those templates happen to emit their `all_libraries`
script block before Asset.js("js/holds.js") in the rendered HTML - a
fragile, easy-to-break ordering dependency between separate template
files, not something holds.js itself can guarantee.
Move the assignment into the existing $(document).ready() handler,
setting it explicitly on `window` so it remains visible as a global to
datatables.js's build_query(), which reads `coded_values` unqualified.
This defers evaluation until all synchronous inline scripts (including
whichever template defined all_libraries) have already run, regardless
of future include/ordering changes.
To test:
1. Place holds on a title for two different pickup libraries
2. Confirm the holds table on reserve/request.tt, the patron's Holds
tab (circulation.pl and moremember.pl) all load with no console
errors
3. Confirm filtering the holds table by pickup library name/branchcode
still works on all three pages
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
filters_options was introduced with the coded_values library filtering
patch but never referenced anywhere in the file.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The "Add patron names to data in column def in holds table" patch
dropped the null-patron handling in the patron column's render
function, so a hold row whose patron embed comes back null (e.g. a
user without permission to view the patron on that hold, per Bug
23269's test plan) now renders a blank cell instead of a useful
message.
Restore the fallback, sourced from `all_libraries` (populated by this
same table's include) rather than the separate `libraries` global,
and check `row.patron` directly instead of the now-composite `data`
column key.
To test:
1. Have holds on a bib from patrons the logged in user cannot see
(e.g. IndependentBranches, or a reduced permission set)
2. View the record's Holds tab
3. Confirm rows with no visible patron show "A patron from library
<library>" instead of a blank Patron cell
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
holds_table.inc is INCLUDEd in a loop from reserve/request.tt whenever
HoldsSplitQueue splits the holds queue by branch/itemtype, or when
holds for more than one biblio are shown at once (multi_hold). Each
inclusion appended its own <script> block declaring `all_libraries`,
and since top-level `let`/`const` in separate inline <script> tags
share the page's global lexical scope, the second and subsequent
occurrences threw "Identifier 'all_libraries' has already been
declared", breaking those script blocks and the pickup-library
filtering that depends on `all_libraries` being set.
Worse, that script block is only emitted when a biblio's holds are
actually rendered (biblioloo.total_holds > 0), but holds.js is loaded
unconditionally by reserve/request.tt and reads `all_libraries` at
top-level parse time. Placing the very first hold on a title (0
existing holds) therefore threw:
ReferenceError: all_libraries is not defined
breaking every hold-management handler defined below that line in
holds.js.
Fix both by declaring `all_libraries` exactly once, unconditionally,
in request.tt's existing page-global script block (alongside the
other unconditional globals such as HidePatronName and
HoldsSplitQueue), before Asset.js("js/holds.js") loads, instead of
duplicating it inside the per-title/per-split holds_table.inc
include.
To test:
1. Search for a title with no existing holds and start placing one
2. Without this patch: browser console shows "ReferenceError:
all_libraries is not defined" as soon as the page loads
3. With this patch: no console errors
4. Set HoldsSplitQueue to "pickup library", place holds on a title
for two different pickup libraries, confirm both split tables
render with working patron-name and pickup-library filtering and
no console errors
5. Confirm the patron's own Holds tab (moremember.pl/circulation.pl)
still loads without console errors
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Have a patron with multiple holds
2. Go to the patron record's hold tab
3. Confirm the table loads and no errors are logged to the console
Sponsored-by: CLAMS
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds the patron firstname and surname to the searchable
data in the patron column definition for the holds table and
removes unnecessary code from the render function.
This enables searching holds by patron names.
To test:
1. Have holds on a bib for different patrons and pickup locations
2. Try filtering by a patron name
3. See 'No matching records found'
4. Apply patch and repeat step 2
5. Filtering by patron name works!
6. Confirm filtering by cardnumber still works too
7. Set system preference HidePatronName to 'Don't show'
8. Confirm searching by patron names doesn't work ;)
Sponsored-by: CLAMS
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds coded_values for libraries to the holds table
and sets the data type in the pickup library column definition.
This enables searching holds by pickup location.
1. Have holds on a bib for different patrons and pickup locations
2. Try filtering by a pickup library name or branchcode
3. See 'No matching records found'
4. Apply patch and repeat step 2
5. Filtering works!
6. Note: if two libraries share the same beginning text
both results are returned :)
For example: 'Fair' returns holds for pickup at Fairview and Fairfield
Sponsored-by: CLAMS
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
- cypress run --spec t/cypress/integration/KohaTable/PatronSearch_spec.ts
- cypress run --spec t/cypress/integration/KohaTable/KohaTable_spec.ts
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
On the hold request and the patron search pages, the search is not
deferred when a state exists.
Coming from
commit 2a34413601
Bug 41604: Save user decision per column when visibility changes
- if (default_save_state_search) {
+ if (default_save_state || default_save_state_search) {
$("#" + settings.nTable.id).data("loaded_from_state", true);
- } else {
+ }
+ if (!default_save_state_search) {
delete state.search;
state.columns.forEach(c => delete c.search);
I think this was a leftover from another try to fix bug 41604. I don't
see how it could help in the context of saving the user decision.
In the different patches from bug 41604 we don't test loaded_from_state.
Test plan:
Go to /cgi-bin/koha/members/members-home.pl
=> The table is not displayed
Search for patrons
=> The table is displayed
Reload the page
=> Without this patch the table is displayed
=> With this patch the table is not displayed
If you have "Save search state on page change" enabled for this table,
the table should be displayed if a previous search was made.
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>
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>
The account editor preselects "No" for "Holds get captured" when
creating a new SIP account, but the SIP checkin default is to capture
holds. This patch makes the editor default the option to "Yes" so a
new account behaves the same as one that never set the option.
Test Plan:
1) Apply this patch
2) yarn js:build
3) Restart all the things!
4) Create a new account in the SIP2 administration module
5) Note "Holds get captured" defaults to "Yes"!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The migration from SIPconfig.xml to the database ( bug 37893 ) leaves
holds_get_captured NULL for any account that didn't define it in the
config file. At SIP checkin an unset holds_get_captured defaults to
on, but the REST API returns NULL boolean columns as false, so the
SIP account editor shows "No" selected. Saving the account without
touching the option then stores 0 and holds are no longer captured
at SIP checkin.
This patch changes the column default to 1 and sets existing NULL
values to 1 so the stored value matches the actual checkin behavior.
Test Plan:
1) If you have no SIP accounts, create one
2) Simulate an account migrated from a SIPconfig.xml that doesn't define holds_get_captured:
UPDATE sip_accounts SET holds_get_captured = NULL;
3) Edit the account, note "Holds get captured" shows "No" even though
holds *are* captured at SIP checkin while the value is unset
4) Apply this patch
5) Run updatedatabase.pl
6) SELECT login_id, holds_get_captured FROM sip_accounts;
7) Note holds_get_captured is now 1!
8) Edit the account again, note "Yes" is now selected for "Holds get captured"!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates several more administration templates with new markup
and CSS for layout forms using CSS grids.
To test, apply the patch rebuild the staff interface CSS.
Check the following pages, confirming that the "New" and
"Edit" versions of the form look correct in each case:
- Administration -> Item search fields
- Administration -> OAI sets
* Updated OAI set mappings form to add maxlength attributes to field
and subfield inputs.
- Administration -> OAI repositories
- Administration -> SMS cellular providers
- Administration -> SMTP servers
Sponsored-by: Athens County Public Libraries
Signed-off-by: Felicie <felicie.thiery@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Typo in edit SQL when authorised values category is wrong : 'op=edit_formid='
Test plan:
1) Create a new authorised values category WRONG
2) Create a new SQL report with : SELECT * FROM biblio WHERE title LIKE <<val|WRONG>>
3) Save the report
4) Delete authorised values category WRONG
5) Run the SQL report
6) You see message 'The authorized value category (WRONG) you selected does not exist.'
7) Click on 'Edit SQL'
=> You comme back to editing the correct SQL report
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1. Set SuspendHoldsIntranet to "Don't allow"
2. Place a hold for a patron
3. Open the patron holds table
4. Confirm the Suspend button is visible in the Suspend column
5. Apply the patch
6. Reload the patron holds table
7. Confirm the Suspend button is no longer visible
8. Set SuspendHoldsIntranet to "Allow"
9. Reload the patron holds table
10. Confirm the Suspend button is visible again
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Set ReservesControlBranch is set to 'item's home library'
2. Set the deafult 'Holds and bookings policies by item type' for the itype BK to allow holds from patrons from any library, but pickup at CPL only
3. Have a bib owned by another library ( I used MPL ), and bib owned by CPL. Both are the item type BK, and each has one item on the bib.
4. Place a hold for a patron on bib A for pickup at MPL
5. Move the hold to bib B
6. Note that the hold moves successfully, and is still set for pickup at MPL
7. Login and try to trigger the hold, nothing happens
8. APPLY PATCH, restart_all
9. Try spets 3 - 6 again. This time on step 6 you should see a message that the hold cannot be moved.
Signed-off-by: Eric Phetteplace <phette23@gmail.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Edit or create a framework that does not require the 008.
2. Make or edit a record in that framework without a 008.
3. Turn on EnableAdvancedCatalogingEditor, and make sure you are using the advanced editor.
4. Go to the record from step 2 and click "Edit as new (duplicate)"
5. The record won't load in the advanced editor.
6. APPLY PATCH
7. Try again, this time the record should load when using "Edit as new (duplicate)".
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Since the introduction of Maskito by bug 33703 we do no longer need to
valid dates when the flatpickr widget is closed.
This patch removes the following JS function from staff and OPAC:
* is_valid_date
* validate_date
* get_dateformat_str
Test plan:
0. Do not apply this patch and confirm that the date string received by
those functions has already been correctly formatted
1. Apply the patch and git grep to make sure no occurrence exists in the
code
2. Confirm that you are still able to select dates with flatpickr
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
apply_sticky is invoked from a watch() in Toolbar.vue every time the
toolbar element (re)mounts. The scroll listener it registers was never
removed, so long-lived SPA modules (ERM, ILL, Acquisitions,
Preservation, SIP2) that mount/unmount this Toolbar as the user
navigates between records leaked another window-level scroll listener
on every remount.
An IntersectionObserver + sentinel node was tried instead, since it's
the standard technique and doesn't poll on every scroll frame, but
verified against KTD/Cypress it fails
t/cypress/integration/Toolbar_spec.ts consistently: the observer's
callback fires once on attach and never fires again after
cy.scrollTo("bottom"), even though the sentinel is confirmed (via
instrumentation) to have scrolled fully out of the viewport. The
scroll-listener approach passes the same spec reliably across repeated
runs. So the scroll listener stays; apply_sticky now returns a
disconnect() callback and Toolbar.vue calls it before re-applying and
on unmount, closing the leak without touching detection behaviour.
Test plan:
1. Rebuild assets (yarn build) and confirm:
yarn cypress run --spec t/cypress/integration/Toolbar_spec.ts
passes consistently across several runs.
2. Manually confirm sticky toolbars in ERM, Acquisitions (vendors),
ILL, Preservation and SIP2 still float correctly on scroll, and that
navigating between several records doesn't accumulate extra "scroll"
listeners on window (DevTools -> getEventListeners(window)).
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Highlighted by the Cypress upgrade (bug 42772): the sticky element is always
visible and IntersectionObserver rely on the visibility of the element.
Cypress test Toolbar_spec.ts use scrollTo("bottom") to test the
behaviour of the sticky toolbar. We test that the "floating" class is
correctly added to the element. To do that we rely on
IntersectionObserver that will check the visibility of the element. But
the sticky element is always visible.
I actually do not recreate the problem when using the UI but the current
code may be broken in some browsers (or new/future versions).
To fix this problem we insert a new "sentinel" element into the DOM and
rely on its visibility to toggle the "floating" class.
Test plan:
Confirm that the sticky toolbar behaviour is the same after this patch
is applied, ie. that the "floating" class is added when we scroll down.
On top of bug 42772 confirm that the following command passes (run it
several times):
yarn cypress run --spec t/cypress/integration/Toolbar_spec.ts
QA: Note that the apply_sticky function takes only one node in
parameter, that's why it has been renamed nodes => node
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Owen Leonard
Hammat Wele
Emily Lamancusa
Kyle M Hall
Martin Renvoize
Jonathan Druart
Lucas Gass
Samuel Sowanick
Saiful Amin
Emmi Takkinen
Aleisha Amohia
Andrew Fuerste Henry
Matt Blenkinsop
Brendan Lawlor
Paul Derscheid
Fridolin Somers
Slava Shishkin