Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adapts the definition file and also tweaks the attribute
names and descriptions to match our guidelines.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the fast_cataloging permission to those checked when a duplicate is found
Additionally, the barcode was missing from the duplicate check and is now added to be passed forward
To test:
1 - Create or choose a borrower and grant permissions:
catalogue
circulate
borrowers: list_borrowers
editcatalogue: fast_cataloguing
2 - Log in as that patron
3 - Search for another borrower and go to checkout screen
4 - Enter random string as barcode to checkout
5 - Item is not found, click to fast catalogue
6 - In the editor type into 245$a 'Perl best practices' - or another title that exists in your system
7 - Get a notice of duplicate with options:
Yes: View existing items
No, save as new record
8 - Clicking 'Yes' will take you to the record details page - you cannot add an item because record is not FA framework
9 - You can click 'back' to return to the messages
10 - Clicking 'No' will create a new record and take you to the details page - you can add an item (Edit->manage items)
but barcode has been dropped
11 - Apply patch
12 - Repeate 3-6
13 - You now get options:
Yes: View existing items (you cannot add items to an existing record)
No, save as new record
14 - 'Yes' will take you to details view
15 - Click back
16 - 'No' will take you to the edit items screen and populate the barcode
17 - Saving the item should return you to patron and issue item
18 - Repeat again with a staff patron with full permissions and confirm saying 'Yes' completes the fast catalogin workflow as expected
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The cronjob debar_patrons_with_fines.pl is meant to add a restriction based on a fines threshold.
The problem is that the script adds a MANUAL restriction, which makes no sense. MANUAL restrictions are meant to be manually created, never automatic as this script does.
In addition, they are repeatable, not unique. Every time this script runs, it will add an additional restriction.
There is already a restriction type meant for this type of use case: SUSPENSION
We should change this script to create SUSPENSION restrictions instead of MANUAL restrictions.
In summary, this script should use the unique restriction type SUSPENSION to prevent multiple additional restrictions from being created on each run.
Test Plan:
1) Set up a patron with fines
2) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message"
3) Note the restriction is created
4) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message" again
5) Note another restriction is created
6) Delete the restrictions
7) Apply this patch
8) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message"
9) Note the restriction is created
10) Run misc/cronjobs/debar_patrons_with_fines.pl -c -m "Test message" again
11) Note another restriction is *not* created!
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
So that screen readers announce errors, add a role attribute set to "alert" and a aria-live attribute set to "assertive".
Since the page reloads on each login attempt, the page will effectively be loaded with both attributes set (if there is an error) and so screens readers should be able to detect and announce the message.
Test plan:
1) On the Koha OPAC, navigate to Home > Log in to your account
2) Attempt to login, entering an incorrect password
3) Inspect the HTML, and notice that the relevant element now has a role attribute set to "alert" and an aria-live attribute set to "assertive".
Repeat steps 2-3, but instead of an incorrect password error, trigger:
A) a timeout error
B) a different IP address error
C) a too many login attempts error
D) an authorisation error (where we are authenticating with a third party)
E) a shibboleth authentication error
F) a CAS login error
G) an invalid username/password error for an anonymous patron
H) an anonymous patron error
I) a password expired error
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Put a few items on hold and make note of the barcodes.
2. Check out one of the items to a patron who doesn't have the hold
3. Check the cancel hold radio button
4. Also check the Remember for the session for this patron
5. Click 'Yes, check out'
6. Notice the item is checked out and the hold is cancelled
7. No checkout another on hold item to the same patron
8. No confirm screen ( good )
9. The item is checked out ( good )
10. The hold is not cancelled. ( bad )
11. APPLY PATCH and restart all
12. Try steps 1 - 9 again. This time the 2nd hold should be cancelled.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With bug 30280 and subsequent patches we attempt to respect the
thesaurus indication when linking with LinkerConsiderThesaurus on.
However, there are still cases when we link wrong.
This happens when thesaurus in bibliographic field 6XX is defined by
subfield $2. In such a case the authority record should have 008/11 = 'z'
and, according to https://www.loc.gov/marc/authority/ad008.html
(cf. comment for 008/11 = 'z': "A MARC code for the conventions used to
formulate the heading *may* be contained in subfield $f"), may or may have
thesaurus declared in 040 $f.
This is why we make a second search attempt in C4::Heading::_search,
but doing so we have to make sure that the resulting authority
record has not a different thesaurus declared in 040 $f. (Note
that 008/11 and 040 $f are indexed with the same search
field: subject-heading-thesaurus. So we search for the
second time in the same search field but with
'notdefined' == 008/11='z' instead of the original
thesaurus taken from subfield $2 of the bibliographic
field 6XX.) This means we have to explicitly check the
content of 040 $f of the resulting authority record.
Test plan:
==========
1. Turn on the LinkerConsiderThesaurus systempreference.
2. Create an authority record (e.g. TOPIC_TERM) with 008/11 = 'z' and
040 $f containing a thesaurus indication (e.g. 'kaba'), and a term
in field 150 $a (e.g. Early music).
3. Edit a bibliographic record: in field 650 put 2nd indicator '7',
the term 'Early music' in $a, and a different thesaurus code in $2
(e.g. 'dbn'). Click the 'Link authorities automatically' button.
Note that 650 'Early music' (dbn) has been linked with and authority
record 'Early music' (kaba). This is wrong.
4. Apply the patch ; restart_all ; reindex ES for authorities with:
koha-elasticsearch --rebuild -d -a kohadev
5. Repeat p. 3. Now the 650 'Early music' (dbn) has not been linked to
an authority record (650 - No matching authority found.)
Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
NB, some previous test had to be adjusted to make it posible to call
search_auth_compat in _search and properly interpret its results.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Hint now covers the default ports for FTP (21) and
SFTP (22), instead of "will default to 22".
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When creating or editing an EDI (EDIFACT vendor record) if the port is left empty it will be set to port 22. This is fine then the service is SFTP, but if FTP is selected the default to 21.
Test plan:
1) Enable EDIFACT
2) Create a new EDI Vendor account with the FTP transport selected. Pleave the ports unpopulated
3) Note the saved record has port 22 set
4) Apply this patch
5) Restart all the things!
6) Repeat stepts 1 and 2
7) The port should now be 21 for new ftp site and 22 for new stp sites!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We shouldn't attempt to load the JS block for dealing with the budgets
table if there is no budgets defined and thus no budgets table.
Test plan
1) Remove all budgets
2) Load acqui-home.pl and note an error in the browser console
3) Apply the patch
4) Reload acqui-home.pl and note the errors have gone
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Amended-by: Jonathan Druart
Tidy
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The last patron menu uses the value "hiddenborrowername." I've made that use preferred_name instead of firstname. When a patron's preferred_name is not manually set/edited, it automatically takes the value of firstname, so we don't need an IF in the template toolkit here.
To test:
1 - have a patron with a preferred_name and one without
2 - get both patrons in the Last Patron dropdown, confirm they both show firstname
3 - apply patch, restart services, clear cache, reload page
4 - get your patrons in Last Patron again, confirm now one shows preferred name and the other firstname
Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan (UNIMARC):
1 - Create a list with different publicationdates, chose to sort it by
copyright gate
2 - Go to the list in the OPAC -> it is not correctly sorted
3 - Pick sort order: copyright date -> not correctly sorted
4 - Apply patch
5 - Retry 2&3 and see it works
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Bug 34889 moved to additional contents.
Remove call in opac pages.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Bug 34869 moved additional contents.
Remove call in opac/opac-search.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1 - Create a new basket - 'Gonna transfer'
2 - Add an order to the basket
3 - Create another basket 'Has the transfer'
4 - Return to first basket and transfer order to second
5 - Return to second basket, click 'Add to basket' and inspect the modal
6 - Note basketno says 'Gonna transfer'
7 - apply the patch
8 - redo steps 1 through 6 with fresh baskets and the modal should have the correct values
Signed-off-by: Andrew Auld <andrew.auld@openfifth.co.uk>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a new test to the data inconsistencies script to report where
MARC records contain item fields.
These may not cause issues in Koha, however, in discovery harvests they have eben found to create errors
To test:
1 - Follow test plan on bug 39412 to generate records with item tags
2 - perl misc/maintenance/search_for_data_inconsistencies.pl
3 - Note new section and hint on how to fix
4 - perl misc/maintenance/touch_all_biblios.pl
5 - repeat 2
6 - Errors cleared
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When building queries for matchign Zebra uses OR to combine searches - Elasticsearch
has been effectively using 'AND' - this patch checks whether and_or has been passed
and follows the variable when present.
To test:
1 - Have an import file of auths with multiple 035
2 - Setup an authority matching rule
Search index: other-control-number
Score: 1000
Tag: 035
Subfields: a
3 - Make sure Koha is using Elasticsearch
4 - Stage file without matching, import file
5 - Stage file again, using your matching rule
6 - Note all records match
7 - Setup Cataloging->Marc modification template
8 - Add an action to delete first 035 field
9 - Run it against the records you just imported
You can use a report:
SELECT authid FROM auth_header WHERE authid > #### (find the lowest new record number in batch you imported)
10 - Change matching rule in batch to none, then back to your rule
11 - No matches!
12 - Apply patch, restart all
13 - Set matchign rule to none, then back to your rule
14 - Matches!
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Works as advertised!
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to members/moremember.pl?borrowernumber=X where X is borrowernumber of a patron with a surname
2. Look under contact information and notice surname is missing.
3. APPLY PATCH and look again.
4. Surname should be included.
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
1. Turn on bookings for an item or item type
2. Find an item and book it.
3. Check the same item out.
4. Go to Circulation > Bookings to collect and run the report
5. The table never loads
6. APPLY PATCH
7. Try again, the bookings to collect report should load!
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Kristi Krueger <kkrueger@cuyahogalibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This test plan edits database values rather than getting these transfers requested via StockRotation. I don't believe that impacts the validity of the testing.
To test:
1 - enable StockRotation syspref (otherwise the Transfers to Show page doesn't show up)
2 - go to /cgi-bin/koha/circ/branchtransfers.pl and transfer an item
3 - log into the database and "update branchtransfers set datesent=NULL where branchtransfer_id=[your transfer]"
4 - go to /cgi-bin/koha/circ/transfers_to_send.pl
5 - confirm there is a column named "On shelf" and your transfer shows the value "On shelf" in that column
6 - back in the database, "update items set onloan=curdate() where itemnumber=[your item]"
7 - reload Transers to Send, confirm it now shows "Due [today]" for your item in the On Loan column
8 - apply patch
9 - reload Transfers to Send, confirm column is now titled "Date due" and the value for your item is still the due date
10 - back in the database, "update items set onloan=NULL where itemnumber=[your item]"
11 - reload Transfers to Send, confirm your item now shows a value of "Not checked out"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Enable Holds history system preference and set the OPACShowHoldQueueDetails to "Show holds and their priority level".
2. Make an item level hold on a record.
3. Make a record level hold on a different record.
4. Login to the OPAC as that patron
5. On the detail page for the item level hold, it works
6. On the detail page for the record level hold, dataTable error
7. APPLY PATCH
8. Try each of the OPAC detail pages again, they should both work.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We also use a badge without a text-bg-# class on the modal claims
include.. this patch adds the same text-bg-info to that.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
With bootstrap 5, a 'badge' class should always be accompanied by a
text-bg-# class. This second class sets the badge color and an
appropriate forground text color to ensure appropriate contrast.
Steps to test:
1. Enable the ability to mark items as "Claimed Returned" by setting
the ClaimReturnedLostValue system preference.
2. Check out an item to a patron, and backdate the due date so that it
becomes overdue.
3. Navigate to: /cgi-bin/koha/circ/overdue.pl to view the overdue item.
4. Mark the item as "Claims Returned".
5. Observe the display: the claim return date text uses #fff (white),
which is not visible on white table rows and has poor contrast on
grey rows.
6. Apply the patch
7. Clear cache in browser and observe the display: the claim return date
badge is now blue with black text.
8. Sign off and have an amazing day! :D
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
As discussed at length on (mattermost)[https://chat.koha-community.org/koha-community/pl/wiopmtr7j3835df3yfi6q64ooy] we need to use the I18N library to properly handle this otherwise we will end up with TT tags inside the translatable strings.
We can not use <span> here as we are inside an <option> tag and nesting
<span> insdie <option> is against the html standard.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This improves the consistency with other areas of Koha:
1. A space before the barcode: "Only item 3999....".
2. Where there is no barcode: "Only item [No barcode]".
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1) Place an item-level hold for an item with a barcode
2) In the holds list on request.pl, see that the Details
column for your hold lists "Only item[barcode]" in the
dropdown without a space before the barcode
3) Apply patch, restart_all, reload page
4) Confirm your hold has a space before the barcode
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If DefaultHoldExpirationdate is on and DefaultHoldExpirationdatePeriod
is blank, the blank is treated as a zero and all holds are created
with an expiration date of today.
This patch changes expiration dates storing so that if
DefaultHoldExpirationdatePeriod is left blank, expiration date is not
set. Users are informed about this with a note in syspref.
To test:
1. Set DefaultHoldExpirationdate on but leave
DefaultHoldExpirationdatePeriod blank.
2. Add hold for patron.
=> Note that expiration date is set as today.
3. Apply this patch
=> Confirm following note is now added after sysprefs:
"NOTE: If DefaultHoldExpirationdatePeriod is left blank
default expiration date is not set."
4. Add new hold for patron.
=> Note that expiration date is not set.
Also prove t/db_dependent/Hold.t.
Sponsored-by: Koha-Suomi Oy
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch correct a template variable name so that the authority record
ID is correctly included in the search results table markup.
To test, apply the patch and go to Authorities.
- Perform a search which will return more than one result.
- On one of the results, click Actions -> Merge.
- An message should appear at the top, "Merging with authority..." and
the authority record ID should be shown in parentheses.
- Pick another record in the results list to merge, click Actions ->
Merge.
- You should be redirected to the "Merging records" page, with the
correct two records shown under "Merge reference."
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If a subfield is present in the authority record, but this subfield is
marked as 'Hide all', then if you edit and save such a record, the
data from hidden fields wil be lost forever. This behavior differs
from bibliographic records editor, when even if a subfield is hidden
(not active) in the editor it will be activated and present in the
editor if present in the record.
The problem affect above all records imported from external agencies.
Test plan:
==========
1. Have any authority record. Note one present subfield (e.g. 100 $d).
2. Modify the record framework for this type of record
(/cgi-bin/koha/admin/authtypes.pl), marking the subfield 'Hide all'.
3. Open the record in the editor and save.
4. Re-enable the subfield in the framework, marking it as 'Show all' now.
5. Reopen the record in the editor. Note that the previous content of
the subfield you played with is gone. Enter any new value and save.
6. Apply the patch ; restart all.
7. Repeat p. 2, i.e. hide the subfield again. Open the record in
the editor. You should see the content of the hidden field as you
would for a bibliographic record with a subfield hidden in the editor
but present in a record. (Note also that the content of this subfield
is visible in record view).
8. Open the editor with an empty record (New authority) of the type
in question. Control that the subfield is hidden (not accessible)
for a new record.
BTW Note that the "hidden" but present subfields are visible in OPAC,
but not in the staff interface *before* applying the patch. The patch
changes nothing for OPAC.
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes the indexer poll the DB in configurable batches. Pretty
much like Rabbit does.
The only change is that it will now pass a LIMIT <batch_size> to the
query.
To test:
0. Have KTD started with ES (skip if you have an instance running):
$ ktd --es7 up -d
1. Stop the indexer and rabbit:
$ ktd --shell
k$ sudo koha-es-indexer --stop kohadev
k$ sudo service rabbitmq-server stop
2. On a separate terminal, watch the queue:
k$ watch -n 0.5 'echo "SELECT COUNT(*) FROM background_jobs WHERE status=\"new\"" | koha-mysql kohadev'
=> SUCCESS: It should be empty
3. Add a bunch of things to index (this works with default KTD data):
k$ for i in $(seq 1 438; seq 1 438) ; do echo "INSERT INTO background_jobs (status,queue,data) VALUES ('new','elastic_index','{\"record_server\":\"biblioserver\",\"record_ids\":[$i]}')" | koha-mysql kohadev ; done
4. Start the ES indexer:
k$ sudo koha-es-indexer --start kohadev
5. Look at the queue size
=> FAIL: It shrinks too fast [1]
6. Apply this patch
7. Restart the indexer
k$ perl misc/workers/es_indexer_daemon.pl &
8. Repeat 3
9. Look at the queue size:
=> SUCCESS: It shrinks 'slowly'
10. Sign off :-D
[1] This is a problem in certain scenarios, not in all of them. This is
the best I come up with in order to test the behavior change. Anyone can
set a new size of their taste.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The save button for automatic item modification rules got moved outside
of the form during the refactor for bug 38714. This happened because
the form was spread between two separate IF blocks that checked the same
condition, which is no longer allowed as of 38714.
This patch consolidates the conditional blocks and moves the submit
button back inside its form.
To test:
1. Go to Cataloguing > Item modifications by age
2. Click Add Rules, and then Add Rule to create a new rule
3. Fill in some reasonable values, for example:
Age in days: 365
Age field: items.itemlost_on
Substitutions: items.withdrawn = 1
4. Click save
--> Nothing happens!
5. Apply patch, refresh, the page, and fill values in again if needed
6. Click save again
--> The rule is saved!
7. Confirm the Edit rules, Add rule, and Cancel buttons still work
i. Click Edit rules
--> The rule you just created should now be editable
ii. Click Add rule
--> A new form for a second rule should be added to the page
iii. Click Cancel
--> The change is cancelled and the page returns to "List of rules"
view
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>
If using ES, the script will collect the newly created records and biblionumbers in atwo arrays (@search_engine_record, @search_engine_record_ids) and pass that to the indexer when $commitnum records are read. The arrays are cleaned afterwards.
BUT: The records and biblionumbers were always stored, even if we're not using Elasticsearch. And as the cleaning of those arrays only happens if we are in fact using ES, all the data is added but never cleaned.
This patch fixes this by only storing record and biblionumber if we have an $indexer (i.e. if we're using Elasticsearch).
I have no idea though how/if the records are indexed when using Zebra.
After applying this patch and importing a large enough file without using Elasticsearch, the RAM usage also stays more or less constant.
@Jan, please verify!
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
So, I reviewed the code, which has a bunch of issues:
* there's a call to `next RECORD`, but no `RECORD` loop label.
* $record_number is incremented twice
* and the calls to txn_begin is moved from the outside the loop into each record, starting one transaction per record. Not sure how mysql handles this, but postgres would not like it.
This patch fixes those issues:
After I fixed the first two issues, I ran the patched script on a file containing 75 authorities (from GND), and not one was added to the DB, presuambly because nested transactions don't work in mysql?
So I also moved the BEGIN transaction outside of the main loop and started a new one after each commit, and added a final commit after to loop.
Signed-off-by: Jan Kissig <bibliothek@th-wildau.de>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Include checking for invalid marc data in main loop to avoid
loading all marc data into memory at once.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We alter how the options are added to the patrons_search datatables
search bar, but we didn't update the selenium test to match.
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch does:
* Mock `CanItemBeReserved` and `CanBookBeReserved` to better control the
test scenario and make it agnostic from existing data.
* Adds tests for the item-level group holds use case
* Adds tests for the warnings printed when placing the hold should not
be possible
To test:
1. Apply this patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/api/v1/clubs_holds.t
=> SUCCESS: Tests pass!
3. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We change the page title in the templates, but didn't update the
corrseponding selenium test
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
BEFORE APPLYING PATCHES:
1) Enabled ILLModule
2) Install a metadata enrichment plugin .e.g:
https://github.com/PTFS-Europe/koha-plugin-api-pubmed/releases/tag/1.1.1
3) Visit ILL requests:
http://localhost:8081/cgi-bin/koha/ill/ill-requests.pl
4) Click 'New ILL requests batch' and pick 'Standard'
5) Enter a name 'test', a cardnumber '42' and any library
6) Click "Continue", enter '123' on the identifiers textarea on the right.
7) Click "Process identifiers"
8) Click "Add items to batch"
9) Click "Finish and view batch"
10) Click 'Batch requests' at the top right of the page.
11) Select the batch you just created and click 'edit'
12) Notice you're unable to 'Continue' or 'Finish and view batch' until you add some pubmedid and click 'Process identifiers'
APPLY ALL PATCHES
13) Repeat test plan
14) Notice the layout and cosmetic changes.
15) Notice you can now edit a batch without having to add new requests. Edit the batch name or library or status and click 'Finish and view batch'. Notice it saves the batch.
Sponsored-by: UKHSA - UK Health Security Agency
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
1) Hide 'continue' button when its no longer needed
2) Dont display 'finish' button until 'continue' is hidden
Sponsored-by: UKHSA - UK Health Security Agency
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The layout is now vertical, fieldsets should be shown vertically, not horizontally.
Border inside the modal no longer exists.
Footer has been readjusted to match other modal footers in Koha, both buttons on aligned to the right, where first button is accept and 2nd button is cancel.
'Process identifiers' button style has been updated.
Sponsored-by: UKHSA - UK Health Security Agency
Signed-off-by: Jeremy Evans <Jeremy.Evans@ukhsa.gov.uk>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>