The wiki now uses `REST*` for the rule names instead of `SWAGGER*` some
tests have their descriptions correct, but most don't.
This is a follow-up to an editorial decision made on the Wiki (probably
at a dev meeting too, I don't remember).
QA tests will probably not pass, but I refrain from tidying it because
there's a major tidy on its way to main.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes the POST endpoints missing the Location header return
it.
Some endpoints I skipped:
* /patrons/account/credits (doesn't have a GET route to point to)
* /patrons/account/debits (doesn't have a GET route to point to)
To test:
1. Apply the regression tests
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/authorities.t \
t/db_dependent/api/v1/biblios.t \
t/db_dependent/api/v1/clubs_holds.t \
t/db_dependent/api/v1/holds.t \
t/db_dependent/api/v1/ill_batchstatuses.t \
t/db_dependent/api/v1/import_batch_profiles.t \
t/db_dependent/api/v1/transfer_limits.t
=> FAIL: Tests fail! The endpoints don't return the header!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There is some JS on the staff interface search history page which uses a
jQuery selector that doesn't seem to work after the DataTables upgrade.
This patch fixes it.
To test, apply the patch and enable EnableSearchHistory if necessary.
- In the staff interface, perform a few catalog searches if necessary.
- Choose "Search history" from the user menu in the upper right.
- In the table of searches, check the checkbox next to one or more
search history entries.
- The delete button at the top of the table should become enabled.
- Clicking the delete button should work correctly to delete your
selected searches.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We never use another value than the default one.
We can simply remove this property.
Test plan:
Rebuild the dist files using `yarn js:build` and confirm that the
buttons in the toolbar of the ERM and Preservation modules still appears
and are styled like before.
Signed-off-by: William Lavoie <william.lavoie@inLibro.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The trashcan icon to cancel a hold from the list of holds on a bib record has
a leftover href attribute from before the bug 34478 CSRF protection changes.
It has an 'op=cancel' which does nothing since there's only a cud-cancel op,
so it just falls through to the view case and redisplays the page if you open
it in a new tab, and doesn't get used at all if you click the trashcan, when
JavaScript builds up a form that you can POST.
Test plan:
1. Place a hold on any item.
2. On the list of holds, right-click the Cancel hold trashcan icon, and
select Open in new tab
3. In the new tab, note that the URL in the browser address bar shows all
sorts of things about op=cancel and borrowernumber and biblionumber and
reserveid, but nothing changed, your hold wasn't deleted
4. Close that pointless tab, and apply patch
5. Reload the page with the list of holds, and again right-click the
Cancel hold trashcan and select Open in new tab
6. In the new tab, note that the URL just has the biblionumber and a #, no
other extraneous things
7. In the original tab, left-click the trashcan, confirm cancellation in the
popup, and make sure that cancelling still does work.
Sponsored-by: Chetco Community Public Library
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Column "Actions" was not translatable in itemsearch.tt. This
patch makes column translatable. This also fixes typo in this
columns id.
Test plan:
1. Change language as something else than english.
2. Navigate to "Item search" page and search for items.
=> Note that column "Actions" still reads "Actions"
3. Apply this patch.
4. Make new item search.
=> Column should now have correct translation.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is not the correct way to hide a column, we should use the DT's column
visibility plugin.
Test plan:
Have some checkouts for a patron, go to the checkout history page
Without this patch notice the "shift" => the table does not take the
whole available width.
Apply this patch, restart_all, remove localStorage entries
=> The table is now displayed properly
You can also play with on-site checkouts.
Before:
https://snipboard.io/uTWYit.jpghttps://snipboard.io/qxZE35.jpg
After:
https://snipboard.io/2L0F3Q.jpg
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
I found the same code in preferences.tt, actually we don't need to trim
if the list is properly generated (ie. without extra spaces)
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Site: .../cgi-bin/koha/admin/usage_statistics.pl
If you try to select a country, you get an error:
==
The value of your system preference 'UsageStatsCountry' is not valid (Germany). Please select a valid one.
==
It doesn't matter which country you chose, no country is valid.
Test plan:
==========
1. Select a country for UsageStatsCountry system preference.
2. Go to http://<your addr>:8081/cgi-bin/koha/admin/usage_statistics.pl
3. Confirm the issue.
4. Apply the patch ; restart_all.
5. Repeat p. 2.
6. Confirm that the issue has been solved.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This trivial patch replicates the mappings in Koha::Biblioitem.
To test:
1. Pick a sample record ID
2. Fetch is using the API with your favourite tool:
GET /api/v1/biblios/<the ID>
Accept: application/json
3. Save the output for later
4. Delete the record
5. Fetch the deleted biblio using the API:
GET /api/v1/deleted/biblios/<the ID>
Accept: application/json
6. Compare the results
=> FAIL: Attributes like `volumedate` are not mapped!
7. Apply this patch
8. Repeat 5
=> SUCCESS: Attributes are mapped!
9. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Leo Stoyanov <leo.stoyanov@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch removes the <div> surrounding batch patron modification
results with the style "overflow:auto". Also removed is the DataTable
option "scrollX". This eliminates the horizontal scrolling for the table
itself, and causes the whole page to scroll horizontally instead. This
is consistent with other pages in Koha.
This fix lets us avoid bugs which are associated with the overflow
scrolling and our DataTables implementation. (see Bug 37730).
To test, apply the patch and go to Tools -> Batch patron modification
- Submit a batch of patrons for modification.
- On the screen showing the patrons which will be modified, the page
will probably have a horizontal scrollbar already. If not, resize your
browser to confirm that the whole page scrolls, not just the table.
- Confirm that the table header "sticks" to the top of the screen when
you scroll down, and that the header continues to be aligned correctly
when you scroll horizontally.
Sponsored-by: Athens County Public Libraries
Signed-off-by: William Lavoie <william.lavoie@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
.badge-pill is from a previous version of Bootstrap. .rounded-pill is
the current version, but I think it looks better without.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Make some checkout to a patron so they have a circulation history,
with some items checked in and some still on loan.
2. Look at the patron's "Circulation history" table. There are four
possible background colors for each row: #ffffff, #f3f4f4, #F9FAE0,
and #FFFFCC.
3. Apply the patch, update the CSS (yarn build), and restart everything
(restart_all).
4. Repeat steps 1-2, if needed. An orange/gold badge will appear under
the "Return date" column of the table for items that have been
checked out, and there will no longer be alternating, pale yellow rows.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised. I agree that it looks better now than before, and
that it is easier to tell the checked out items from the returned items.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We don't have proper exceptions in the `C4::Biblio::AddBiblio` method,
but we at least know `$biblio_id` will be `undef` in the even of an
error processing the call.
This patch makes the controller handle this situation so (at least) it
is obvious that something bad happened.
To test:
1. Apply the regression tests patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/biblios.t
=> FAIL: Tests fail! The endpoint returns 200 even on error!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass! The endpoint returns a 400 with a reasonable
message!
5. Sign off :-D
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes the code call `FindDuplicate` only if
`x-confirm-not-duplicate` is not passed. This makes sense, as having it
passed makes it override any duplicate found.
This patch doesn't change any end user behavior, just makes the code
more efficient.
To test:
1. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/biblios.t
=> SUCCESS: Tests pass
2. Apply this patch
3. Repeat 1
=> SUCCESS: Tests pass, no behavior change
4. Sign off :-D
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Duplicate barcodes are generated when placing an Order in Acquisitions when AcqCreateItem = "placing an order" and Autobarcode is turned on.
The problem is that you can accidentally attach 3 items to an order, but only 1 will be saved to the database. When you go to receive your order, you can only receive 1 item as the other two were never made, since the barcode wasn't unique.
In 3.8.0, a software error comes up which prevent any item creation, I believe, but master (3.9.x) doesn't throw any warnings or errors.
Yes.. This tries and solve a bug from 3.8.0 /o/
Test plan:
1 - set syspref "autoBarcode" to generated in the form <branchcode> yymm001
2 - set the barcode field to "barcode.pl" in marc structure
3 - create a new basket
4 - add one item to this basket
5 - click on the barcode field -> it should have a barcode
6 - click on add item and click on the new barcode fiels, it should have
the same value
APPLY PATCH:
7 - click on the barcode field -> it should have a barcode
8 - click on add item and click on the new barcode fields, it should have
an higher barcode.
Note : The barcode is incremented each time the barcode with an empty
value is clicked on. Therefore, if the
librarian removes the value from barcode and click again, they could get
another barcode. I do not know if it is an issue.
Note: This patch is not splitted in two parts anymore
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan, works as advertised.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1: Add 4 items, 2 with homebranch = Library A and 2 with homebranch = Library B
2: Logged into Library A, check out 1 Library A item and 1 Library B item, both with due dates in the past enough for the longoverdue cron
3: Set yourself to Library B, check out 1 Library A item and 1 Library B item, both with due dates in the past enough for the longoverdue cron
4: Run longoverdue cron with --verbose, without --confirm, and without --Library. see that it would act on all 4 items
5: Set CircControl to "the library the item is from"
6: Set HomeOrHoldingBranch to "the item's home library"
7: Run longoverdue cron with --verbose and --library="A" (where A is the code for your Library A), wihout --confirm
8: See the cron wants to act on the items with homebranch = A
9: Set HomeOrHoldingBranch to "the item's holding library"
10: Run longoverdue cron with --verbose and --library="A" (where A is the code for your Library A), wihout --confirm
11: See the cron is still trying to act on the two items with homebranch = A
12: Apply patch, restart all
13: Run longoverdue cron with --verbose and --library="A" (where A is the code for your Library A), wihout --confirm
14: See the cron is now trying to act on the two items with holdingbranch = A
15: Set HomeOrHoldingBranch to "the item's home library"
16: Run longoverdue cron with --verbose and --library="A" (where A is the code for your Library A), wihout --confirm
17: See the cron wants to act on the items with homebranch = A
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
MARC records with over 99999 bytes are invalid by spec, and when you use
UTF-8 encoded characters in your MARC records, there is the potential
to generate fatal errors in MARC::File::USMARC when it runs
"marc_to_utf8" from "MARC::File::Encode" during its "decode" operation.
That is, if you MARC::File::USMARC->encode a MARC record
with over 99999 bytes (including a number of UTF-8 bytes), there
is the potential when you run MARC::File:USMARC->decode on that same
data that you'll generate a fatal exception.
The main patch in bug 38913 wraps the function doing the decode,
so that a bad record doesn't crash processing.
Without the patch, this unit test will fail. With the patch, this
unit test will pass.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
After Bug 38416 Elasticsearch indexing explodes with oversized
records, especially with UTF encoded data.
In Koha::SearchEngine::Elasticsearch::marc_records_to_documents a
following snippet has been introduced:
my $usmarc_record = $record->as_usmarc();
my $decoded_usmarc_record = MARC::Record->new_from_usmarc($usmarc_record);
But if $record is oversized (> 99999 bytes), it is OK for MARC::Record
object, but not for $record->as_usmarc. The produced ISO 2709 string
is not correct and hence cannot be properly converted back to
MARC::Record object by new_from_usmarc.
The result in this case can be like:
UTF-8 "\x85" does not map to Unicode at /usr/share/perl5/MARC/File/Encode.pm line 35.
Since it is done without any eval / try, the whole reindex procedure
(for instance rebuild_elasticsearch.pl) is being randomly interrupted
with no explanation.
Test plan:
==========
Hard to reproduce. But the explanation together with discussion in Bug
38416 (from 2024-12-15) explains and justifies the need of this added
eval.
1. Have a standard KTD installation with Elasticsearch.
2. Use the provided test record - add it to Koha with
./misc/migration_tools/bulkmarcimport.pl -b -file test.xml -m=MARCXML
(have patience).
During load process you should see a message like:
UTF-8 "\xC4" does not map to Unicode at /usr/share/perl5/MARC/File/Encode.pm line 35.
3. The record should get biblionumber 439. Check in librarian interface with
http://<your_addreess>:8081/cgi-bin/koha/catalogue/detail.pl?biblionumber=439
that the record has been imported.
However, you should not be able to make a search for this record.
4. Try to reindex with:
./misc/search_tools/rebuild_elasticsearch.pl -b -bn 439
You should get a message like:
UTF-8 "\xC4" does not map to Unicode at /usr/share/perl5/MARC/File/Encode.pm line 35.
Again, no search results.
5. Apply the patch ; restart_all.
6. Repeat reindex with:
./misc/search_tools/rebuild_elasticsearch.pl -b -bn 439
There should be no warning now and you should be able to find the record.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan. Works as advertised.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes a wrong condition check in `usermenu.inc` for
determining if the tab should be active.
It currently checks for `ermview`, probably a copy and paste error.
This patch adds a new `curbside_pickups_view` parameter that is passed
instead.
Note: I tidied the code block I changed, inline to avoid extra commits.
To test:
1. Enable the `CurbsidePickup` system preference
2. Log into the OPAC
=> SUCCESS: There's a 'Curbside pickups' tab
3. Click on the tab
=> SUCCESS: The 'Curbside pickups' section gets displayed
=> FAIL: The tab remains inactive
4. Apply this patch
5. Restart plack:
$ ktd --shell
k$ koha-plack --restart kohadev
6. Repeat 3
=> SUCCESS: The 'Curbside pickups' section gets displayed
=> SUCCESS: The tab is rendered as active
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Remove the bs-data-dismiss attribute from the "cancel transfer" button
on the Wrong Transfer modal. The "cancel transfer" button's JS works by
adding a hidden input and then submitting the form - we don't want
Bootstrap to dismiss the modal before the embedded form has been
submitted.
Note: This bug seems to be browser-dependent. So far it has been
reproduced with Firefox, but not Chrome/Chromium or Microsoft Edge
To test:
1. Log into the staff client using Firefox
2. Set up system preferences:
TransfersBlockCirc - Don't block
AutomaticConfirmTransfer - Do
3. Find or create an item that belongs to a branch other than the
logged-in branch
4. Check in the item to trigger a Return to Home transfer
5. Click OK on the modal to confirm the transfer
6. Check in the item again to trigger a Wrong Transfer modal
7. Click the "Cancel transfer" button on the modal
8. Navigate to the bib for that item and check the item status
--> The transfer wasn't cancelled - the item is still in transit
9. Apply patch and refresh the page
10. Repeat steps 6-8
--> Item shows as available - the transfer was cancelled successfully
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
After the upgrade to Bootstrap 5, modals need either the block or
noblock class in order to be shown. The class was missing from the modal
that appears when an item is checked in after it is already waiting for
a hold.
To test:
1. Place a hold on an item for pickup at the logged-in branch
2. Check in the item and confirm the hold
3. Check in the item again
--> There is no notification that the item is already assigned to a
waiting hold, just a "Not checked out" message
4. Apply patch
5. Navigate away from the page (we can't simply refresh the page because
we don't want to resubmit the request just yet)
6. Check in the item again
--> A modal appears notifying of the waiting hold
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
19:05:50 koha_1 | "error": "Basic authentication disabled"
We don't need to pass the auth in this request, we are authenticated
already.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It might not exist!
This code is not trivial and should ideally be moved to somewhere it
could be reused easily. But good enough for now to fix the failing tests.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We redefine it and so the query/mysql plugin is not available
It fixes csrf.ts
14:36:17 koha_1 | The task 'query' was not handled in the setupNodeEvents method. The following tasks are registered: buildSampleObject, buildSampleObjects
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Run t/Makefile.t, observe failure
2) Apply patch
3) Run t/Makefile.t, observe success
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This makes the strings easier to translated for maintaining them as a
whole instead of splitting them
Bonus 1: it adds a missing dot for consistency.
Bonus 2: makes a string more idiomatic.
To test:
1. In the categories edit page, check the 3 'If set...' texts
2. Apply this patch and reload
=> SUCCESS: No visual change
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch modifies the curbside pickups page in the staff interface so
that each table is a DataTable with configurable columns.
The patch also replaces the patron name output with patron-title.inc for
consistency and to display names 'surname, firstname' for correct
column sorting.
To test, apply the patch and restart services.
- Enable the CurbsidePickup system preference if necessary.
- Properly testing requires testing data. You can run this command to
REPLACE your curbside pickup data with sample data:
bash <(curl -s https://gitlab.com/-/snippets/2572579/raw/main/test_curbside_pickups.sh)
- Go to Circulation -> Curbside pickups.
- Test DataTable functionality under each tab: sorting, paging,
filtering, column visibility, and export.
- Go to Administration -> Table settings -> Circulation -> Curbside
pickup
- Confirm that changes made to the configuration of each of the
4 curbside pickup tables is correctly applied on the curbside
pickups page.
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch moves the RoutingListNote system preference into HTML
customizations, making it possible to have language- and
library-specific content.
To test you should have some content in the RoutingListNote
system preference before applying the patch. Apply the patch and run
the database update process.
- In the staff client, go to Tools -> HTML customizations and verify
that the content from RoutingListNote is now stored there.
- The HTML customization entry form should offer RoutingListNote
as a choice under "Display location."
- Update and reinstall active translations (for instance fr-FR):
- perl misc/translator/translate update fr-FR
- perl misc/translator/translate install fr-FR
- Enable the translation if necessary under Administration -> System
preferences -> language.
- Edit the RoutingListNote HTML customization and add unique
content to the "fr-FR" tab.
- Go to Serials and create a subscription if necessary.
- From the subscription detail page, click "Create routing list" in the
left-hand sidebar.
- Add one or more recipients to the list and click "Save".
- On the "Preview routing list" page click "Save and preview routing
slip".
- In the pop-up window with the routing list preview you should see the
content you added to the RoutingListNote HTML customization.
- Switch to your updated translation and confirm that the content you
added for your translation shows up correctly.
- Go to Administration -> System preferences and search for
"RoutingListNote." It should return no results.
NOTE: This patch does not keep the default content which was stored by
the RoutingListNote system preference. Having a default value for that
kind of preference is not standard. Instead I have updated the
description of the RoutingSerials preference to add a mention of the
RoutingListNote HTML customization option.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH
2. Have some checkouts with various issue dates.
3. Go to item search and look for the 'Last checkout date:'
4. Try some different searches and confirm that they work as expected.
5. Change the DateFormat system preference and make sure the search still works with all the DateFormat optoins.
Signed-off-by: William Lavoie <william.lavoie@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. APPLY PATCH and restart_all
2. Go to an item record and click 'Manage bundle'
3. Make sure the item you are adding has a copy number.
4. Look at the bundle_table and notice the copy number displaying.
5. Make sure you can hide the column ( Gear icon: Columns ) and via Table settings.
Signed-off-by: Hebah Amin-Headley <hebah@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
1. Have or create an item with a serial subscription on it.
2. When receiving make sure you add some publisheddatetext (
Publication date text )
3. Have a look at the record in the OPAC.
4. In the subscrptions tab there is no 'Publication date text' column.
5. APPLY PATCH and restart_all.
6. Still no 'Publication date text' column is visible.
7. Go to Administration > Table settings
8. Expose the column
9. Reload the OPAC page, you should see the new column.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This one is less obvious, how is it possible to request an authority
search using catalogue/search.pl?
Is it dead code or is it actually used somewhere?
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This is clearly dead code as it's never set in the controller file.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Added decimal input_mode and pattern for "Rental discount (%)" so it functions same way as "Fine amount" or "Overdue fines cap (amount)" rules, allowing user to save decimals only.
1. Go to Circulation and fine rules page and save some gibberish into "Rental discount (%)", see that it allows you to do that.
2. Apply the patch, and try same thing again, this time it should only allow you to save decimal numbers.
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Tomas Cohen Arazi
Owen Leonard
Jonathan Druart
Phil Ringnalda
Emmi Takkinen
Janusz Kaczmarek
Leo Stoyanov
Baptiste Wojtkowski
Andrew Fuerste Henry
David Cook
Emily Lamancusa
Matt Blenkinsop
Paul Derscheid
Katrin Fischer
Lucas Gass
Petro Vashchuk
