New
subfields 0 1 2 in 310 and 321
Changes
310 change to repeatable
883 renamed
883 a d q renamed
To test:
1) Remove bibliographic frameworks
2) Check mandatory bibliographic fw load without problem
misc/load_yaml.pl --load --file=installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml
3) Check new/renamed fields/subfields
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit f259298fd4)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 1da7817243)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Marking an item as a return claim checks MarkLostItemsAsReturned to see if claim_returned is a value in MarkLostItemsAsReturned.
However, this option was never added to MarkLostItemsAsReturned so an a return claim can never be automatically removed from the patron record, even if they wanted such behavior.
Test Plan:
1) Apply this patch
2) Restart all the things
3) Note the new return claims option on MarkLostItemsAsReturned in the system preferences
Signed-off-by: Marti Fyerst <mfuerst@hmcpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit e53d559f42)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 1fa7920f2a)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Categories B, J, K and YA have a upper age limit of 17 years.
We are setting the dateofbirth to today - 15 years to prevent juvenils
to be 70!
Note that DATE_SUB is a MySQLism, but there is no way to be portable
here.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit b647aff01d)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 23dd20a9ce)
To prevent them to be expired.
Note that the last patron is kept expired.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit e3205b4c41)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit c2f9610e3f)
This fixes a broken link in the sample news items for fr-FR and fr-CA.
Test plan:
1) Apply the patch.
2) Install the French language files - see
https://wiki.koha-community.org/wiki/Installation_of_additional_languages_for_OPAC_and_INTRANET_staff_client
3) When Koha is in French, from the home page of the staff interface go to Tools/Outils > News/Annonces, and make sure the two news items are there.
-If not, try importing the two files into your database or reset and install Koha in French (fr-FR or fr-CA).
4) There should be a news item with the heading Et maintenant ?, click the 5th link "proposez des correctifs et des améliorations".
5) If should take you to
https://wiki.koha-community.org/wiki/Version_Control_Using_Git
and there is no 404 error, the patch has worked!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit c6009f3220)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 4ba318f8a8)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
TEST PLAN
Follow https://wiki.koha-community.org/wiki/Installation_of_additional_languages_for_OPAC_and_INTRANET_staff_client in order to install french.
When koha is in french, from home go to tools/outils, then
news/Annonces, make sure the two files are there.
Preview them there or view them from the homepage and check that the 3
is gone.
If the files are not there, try importing the two files into your
database.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 42aac43290)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 35e723fc53)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
I have changed GRN to UAH in both
installer/data/mysql/ru-RU/optional/sample_currency.sql and in
installer/data/mysql/uk-UA/optional/sample_currency.sql
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 732e69f4b2)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 63babb7401)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Didn't know how to change the uk-UA default currency.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 6bb8065af6)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit e001395c1a)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 37b5a14f4c)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit f42baffc94)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Mana system preference type 'YesNo' is wrong since it has 3 values.
Change to 'Choice'
Test plan :
1) Run atomic update
2) Check in database 'Mana' system preference type is 'Choice'
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 557d2137d6)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 3b464f56d3)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit e6426a540b)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 1356a55d21)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
UsageStatsCountry system preference type 'YesNo' is wrong since it has
several values.
Change to 'Choice'.
Looks like this error whas only in updatedabase 3.17.00.030.
Test plan :
1) Run atomic update
2) Check in database 'UsageStatsCountry' system preference type is
'Choice'
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit bbab661563)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 32b89e216d)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
This patch prepares Koha to officially no longer support Elasticsearch 5.X
It adds a new system preference 'ElasticsearchCrossFields' to allow users to choose whether or not
to enable this feature
It updates the about page to add a deprecation warning if a site is running ES5
To test:
1 - Be running Koha with Elasticsearch 5.X
2 - Attempt to search
Error: Unable to perform your search. Please try again.
3 - Apply patch
4 - Update database
5 - Searching works
6 - Find syspref 'ElasticsearchCrossFields'
7 - Enable it
8 - Searching is now broken
9 - Check the about page
10 - you can now see the Elasticsearch version
11 - The systeminformation tab has a deprectaion warning
12 - Set SearchEngine preference to 'Zebra'
13 - View the about page - no warnings
14 - Test again with ES6 - searching should "work" with either pref setting
15 - There should be no warning on about pages
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
UPDATE: changed queries to not touch * values
To test:
1 - Checkout 19.11.x and reset_all
2 - Add a new patron category, itemtype, and branch to your system
3 - Create issuing rules using thise 3 values, and others
4 - Delete the new category, itemtype and branch
5 - Checkout master
6 - Restart_all
7 - updatedatabase
8 - you get errors
9 - repeat 1-5
10 - apply patch
11 - restart_all
12 - updatedatabase
13 - no errors!
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 31e38bc371)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The mapping in the itemcallnumber system preference is only valid
for MARC21 libraries using DDC classification, but not for libraries
using UNIMARC or other classification.
This patch suggests to remove the default mapping and start new installations
with an empty value.
To test:
- On an emtpy database
- Apply patch
- Run the web installer, selecting either MARC21 or UNIMARC
- Verify that the itemcallnumber system preference is empty
- Verify the description now also include examples for UNIMARC
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit d80421ce85)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch harmonizes the column datatypes of import_biblios
with biblio and biblioitems to prevent database errors which cause
staged MARC uploads to sometimes fail to update 100% correctly.
To test:
1. Go to http://localhost:8081/cgi-bin/koha/tools/stage-marc-import.pl
2. Upload a file with MARC records with titles longer than 128
characters long
3. Click "Stage for import"
4. Monitor /var/log/koha/kohadev/intranet-error.log for
database errors
5. Note that there are no database errors
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit e39b9684d5)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
00:02:16.310 koha_1 | DBD::mysql::st execute failed: Can't create table `koha_kohadev`.`aqbudgets` (errno: 150 "Foreign key constraint is incorrectly formed") at /usr/share/perl5/DBIx/RunSQL.pm line 278, <$args{...}> line 1.
00:02:16.310 koha_1 | Something went wrong loading file /kohadevbox/koha/installer/data/mysql/kohastructure.sql ([SQL ERROR]: CREATE TABLE `aqbudgets` ( -- information related to Funds
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
(cherry picked from commit 3df7a02d81)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
- When we run into invalid data, we use Augustin's suggested solution
and copy the data into a separate table, setting the budget_period_id to
NULL.
- We amend the output using the new $message.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 3c8bef50a2)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When there are inconsistent budget_period_id in aqbudgets this patch
creates the table _bug_18050_aqbudgets with the original data, then sets
the column to null and warns the user that there is inconsistent data.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 1193dddd8b)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This adds a FK constraint on aqbudgets.budget_period_id so that
a fund cannot be added with an invalid aqbudget.budget_period_id.
We should not have funds that belong to no budget. In case we have, the
update will be skipped and a note displayed.
Part1:
- Before applying the patch
- Make sure you have a budget with some funds linked to it
- You will have to change one of the funds to link to an invalid
budget with SQL:
UPDATE aqbudgets SET budget_period_id = 999 WHERE budget_id = max(budget_id);
- Apply patch
- Run updatedatabase - verify that you see the hint about 1 existing fund with invalid budget.
- Repair your fund with SQL
UPDATE aqbudgets SET budget_period_id = ... WHERE budget_id = max(budget_id);
(... needs to be your existing budget_period_id)
- Run updatedatabase again - verify it runs successfully now.
- If you try to change the budget_period_id to a non-existing now with SQL, you will
get a database error. The new FK doesn't permit it.
Part 2:
- Start fresh with the web installer, verify there are no errors on
creating the database tables
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 0ce62b29bf)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This is really an installation issue, though at the
time of installation it did not result in any error.
During cataloguing in the items menu the "Type of item or material"
is not constrained by the itemtypes authorised_values (as it is for 942c records).
I have added the itemtypes to the installer sql in unimarc_framework.sql
as well as adding the description of this field for OPAC, which had been left empty.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 3bd23a3287)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Patch changes some of the values in the sql statement that inserts 307a
unimarc row into the marc_subfield_structure which created an SQL error
on installation.
The fields changed are:
- isurl now 0 instead of NULL,
- hidden now -5 instead of NULL,
- seealso empty string instead of NULL,
- link empty string instead of NULL.
These field values are now similar to the ones inserted for 306a or 308a.
The value that caused the SQL error was using NULL for hidden (due to
the NOT NULL constraint in the table definition).
I have tested the install with this change and found no issues.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 7c74c6636f)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - perform query "select variable,explanation from systempreferences where explanation like '% his %';"
2 - find 6 sysprefs with gendered pronouns used in explanations
3 - apply patch, reset_all
4 - repeat query
5 - no more gendered pronouns!
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit a96f5deef0)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
All subfields for a MARC21 field should always be in the same tab.
There were some mistakes found by the "MARC bibliographic framework
test" this fixes.
Before you apply the patch:
- Check the "MARC bibliographic framework test" page
- Ideally you should see the "wrong tab" mistakes
- Reset your db (reset_all) or drop your db and run the web installer
- Verify the page no longer points out any issues
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 1cd2233173)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
(cherry picked from commit d59ec16fd07aa95bc870ad06b7b568c38fb4bcc0)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 5cfbe318d8)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
After looking at Marcel's comments, the problem is in our matching
to hold_fill_targets - rather than adjusting to find filled/waiting holds we
could ensure that hold_fill_targets only refers to the specific hold it
is intended to
This patch is clearer, if slightly less performant than last (we now return all
the reserves and have to find the 'highest')
Test Plan:
1 - Create and use a patron that can place multiple record level holds per record
2 - Create a record with X items, each at a different library
3 - Place X 'Next available' holds on the record for the patron using the 'Holds to place' box
4 - perl misc/cronjobs/holds/build_holdsqueue.pl
5 - Check in LibraryA's copy as LibraryA and confirm the hold
6 - Revisit request.pl for the record, notice the next hold in line is now item-specific
7 - Checkout the item to the patron, notice the remaining hold is marked waiting
8 - Attempt to place another hold for your patron, notice that it requires an item-specific hold
8 - Apply this patch
9 - Repeat steps 1-5
10 - Revisit request.pl for the record, notice the next hold in line has *not* become item-specific
11 - Checkout the item to the patron, ensure the first hold is filled and the second remains record level
12 - Repeat whole test plan without building holds queue to confirm holds are still treated correctly
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 0bfe336c7b)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If the database update for bug 21443 is run, and the library changes any
of the hourly or daily rental fees following the calendar, a second run
of the database update will overwrite those changes.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit e708566e72)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Add a "year" search field type. Fields with this type will only
retain values that looks like years, so invalid values such as
whitespace or word characters will not be indexed.
This for instance improves the behaviour when sorting by
"date-of-publication". If all values are indexed, records with
junk data instead of valid years will appear first among the search
results, drowning out more relevant hits. If assigning this field
the "year" type these records will instead always appear last,
regarless of sort order.
To test:
1) Have at least two biblios, one with a valid year in 008 (pos 7-10)
and another with an invalid one ("uuuu" for example)
2) Perform a wildcard search (*) and sort results by publication date.
3) The record with invalid year of pulication in 008 should appear first
4) Apply patch and run database updates
5) Reindex ElasticSearch
6) Perform the same search as in 2)
7) The record with the invalid year should now appear last
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: Add database update script
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: Update tests
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: Add suppport for uncertain fields and ranges
To test:
1 - Have some records with uncertain dates in the 008
19uu, 195u, etc.
2 - Index them in Elasticsearch
3 - Do a search that will return them
4 - Sort results by publication/copyright date
5 - Note odd results
6 - Apply patch
7 - Reindex
8 - Sorting should be improved
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: Refactor using tokenize_callbacks
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: Simplify with new and imporved value_callbacks
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: (follow-up) Fix spelling
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: (follow-up) Add support for spaces as unknown characters
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Bug 24807: (QA follow-up) Remove uneccessary tests
These tests fail now, the code expects a real response from ES in Indexer.pm
but these tests mock 'bulk' and so don't have the necessary fields.
We are testing the same code above and can just add the _id == biblionumber test
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1. On 20.05.x run updatedatbase and see an error
2. Apply patch
3. Re-run updatedatabase without an error
https://bugs.koha-community.org/show_bug.cgi?id=25958
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This translates the new notices and CSV profie for late orders,
makes some minor changes to the patron category descriptions
and numbering patterin labelling.
To test:
- Make sure German language is installed, see:
https://wiki.koha-community.org/wiki/Installation_of_additional_languages_for_OPAC_and_INTRANET_staff_client
- Run the web installer and choose de-DE
- Select all sample files
- Make sure they all install without any errors
Bonus:
- If you can speak German, you can check the translations as well :)
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit ef3b7eedc0)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Field 943$a has link value "130". This does not work; 130 is not a search
index. It should be Title-uniform.
Note: Only used on a search link in the intranet MARC detail page.
In some cases "130" should be replaced by "Title-uniform", but sometimes
130 without quotes had to be replaced. Performed by two sed statements
on git grep results.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit a937895fda)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The updated files have been auto-generated based on the
po files and downloaded from
https://translate.koha-community.org/files/
To test:
- Make sure German language is installed, see:
https://wiki.koha-community.org/wiki/Installation_of_additional_languages_for_OPAC_and_INTRANET_staff_client
- Run the web installer and choose de-DE
- Select all sample files
- Make sure they all install without any errors
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit c0adeab58f)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When lost items are not marked as returned, they are still subject to
the long overdue cron, so an item that has already been marked Lost may
automatically roll to Long Overdue. In some cases, a library may not
want that lost value to change. This becomes especially important with
the introduction of Claims Returned, which uses a variety of lost.
Test Plan:
1) Set up a long overdue item that would be moved to lost by longoverdue.pl
2) Run the cronjob with the new --skip-lost-value option
3) Note the item is not altered
4) Include that value in the new system preference DefaultLongOverdueSkipLostStatuses
5) Run the cronjob *without* the new option
6) Note the item is not altered
7) Run the cronjob again with the new command line option, but set it to
a different value so the item will be affected
8) Note the item is altered as it would have been before this patch was
applied
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Rebecca Coert <rcoert@arlingtonva.us>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 48edb29471)
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>