Sponsored-by: Catalyst IT, New Zealand
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We are storing edi vendor acccount passwords in clear text in the
database. Now that Koha has the Koha::Encryption module, we should
use that to encrypt passwords for all existing and new EDI accounts.
Test Plan:
1) Apply this patch
2) Create one or more EDI vendor accounts
3) Run a report to view the account passwords, note they are in clear
text
4) Run updatedatabase.pl
5) Re-run the report, account passwords should be encrypted now
6) Edit a vendor EDI account, note you can still view and update the
password for an account
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1 - Enable UseBranchTransferLimits by item type
2 - Set some limits for book
3 - Place a hold, verify that pikcup dropdown reflects the limits before and after patch
Signed-off-by: Bob Bennhoff <bbennhoff@clicweb.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds indices to the borrowers table to match the default
search fields for patrons.
To test:
1 - Apply patch
2 - Update database
3 - Ensure patron searching works as before
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Ann Flournoy <aflournoy@cityofkeller.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Right now the holds queue builder starts filling bib-level holds with
items whose patron's home library matches the item's home library.
It would be good and reasonable to have the option to prioritize
item's whose patron's home library matches the item's holding library
to minimize transfers.
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To keep current behavior, we can copy the removed fallback
into the syspref value in case someone might have cleared the pref.
Note: We are not restoring deleted prefs here; that is a data problem
outside the scope of this report. A regular installation should always
have this pref.
Test plan:
Run updatedatabase.pl
Bonus: Clear the pref Reference_NFL_Statuses and run again, verify that
the pref has changed.
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: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 30280 added the ability to use multiple thesauri for authorities in Koha.
This is a large change, and many libraries use authorities in a ess strict manner.
This patch simply adds a preference, disabled by default, to enable this new feature
To test:
1 - Find or create a record with a 650 heading, second indicator 0 (LOC)
2 - Ensure this links to an authority in your system
3 - Disable AutoCreateAuthorities, enable CatalogModuleRelink
4 - Edit the heading to second indicator 2
5 - Save, the heading does not link
6 - Apply patch, updatedatabase, restart all
7 - Edit and save record again
8 - Heading should now link to the LOC authority, despite different second indicator value for source
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Same sa issn and isbn, we want lccn to allow longer values.
Test plan:
Run the updatedatabase script to modify the DB structure
restart_all
Edit a bibliographic record and enter a long (more than 25 chars) lccn
Save
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Followed the test plan. Works as advertised.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves account debit and credit types, as well as the CASH
payment type, into YAML files under
installer/data/en/mandatory. This should make the debit and credit types
translatable (for new installations only).
To test:
1. Apply patch
2. Update po files
./misc/translator/translate update xx-XX
3. View the xx-XX-installer.po file
-->The default account debit and credit types (and cash payment type)
should be available to be translated
4. Translate the strings
5. Apply the translations
./misc/translator/translate install xx-XX
6. Load the new translated YAML files (with a fresh install, or by deleting
the values in the db and using ./misc/load_yaml.pl to load the files)
7. In the staff interface, go to Administration > Credit types
--> They should be translated
8. Go to Administration > Debit types
--> They should be translated
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
These guarantors cannot be added. They are of no use.
NOTE FOR QA/RM: I do not think that it is needed to add a new
db rev for this change since it happens seldom. But if you think
that it is, just copy it to atomicupdate/change bugno.
Test plan:
[1] Check your table definition and modify it:
alter table borrower_relationships modify column `guarantor_id` int(11) NULL;
[2] Add an empty guarantor:
insert into borrower_relationships (guarantee_id,relationship) values (SOME_PATRON_ID,'father');
[3] Run the dbrev and verify that the inserted record has been removed.
[4] Check table definition with 'show create table borrower_relationships'.
You should see NOT NULL with guarantor_id.
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: Tomas Cohen Arazi <tomascohen@theke.io>
We've identified 3 issues:
* Name of patron is not showing up in subject line
* Name of patron is now showing in notice text
* Notice is set to be HTML, but has no line breaks and uses no HTML tags
In the database update, these issues don't occur:
$dbh->do( q{
INSERT IGNORE INTO letter (module, code, name, title, content, message_transport_type) VALUES ('members', 'PASSWORD_CHANGE', 'Notification of password change', 'Library account password change notification',
"Dear [% borrower.firstname %] [% borrower.surname %],\r\n\r\nWe want to notify you that your password has been changed. If you did not change it yourself (or requested that change), please contact library staff.\r\n\r\nYour library.", 'email');
});
So this patch will make them match up:
* Remove HTML flag
* Update patron. to borrower. in message text
* Remove patron name from subject (it won't work even with the correct variables)
To test:
* Add an email address to your favourite sample user
* Make sure NotifyPasswordChange is set to "Notify"
* Update the sample user's password using the "change password" feature
* Verify a notice is shown in the notices tabs
Note: you won't see the line break issue there because of bug 30287
* Apply patch
* Recreate your database/run web installer so sample notices are loaded
* Repeat the test, it should generate a nice lookig notice now
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The Koha Community normally refers to "global system preferences"
as just "system preferences".
This updates the staff interface and other occurences to refelect
this, including:
- Administration > Global system preferences and the description
- Patrons > [a patron] > More > Set permissions > Manage Koha
system settings > Manage global system preferences
(manage_sysprefs)
- The installer files and the database (permissions table)
Test plan:
1. Note that in the staff interface "Global system preferences"
is dispalyed in two places:
1.1 Administration: Go to Administration. There is a section
called "Global system preferences" with a description
and a search box.
1.2 User permissions: View the details for a patron > More >
Set permissions > expand 'Manage Koha system settings' >
scroll down to 'Manage global system preferences
(manage_sysprefs)'
2. Apply the patch.
3. Update the database.
4. Revisit the pages in step 1 - these should now show as
"System prefereneces" or "system preferences" as appropriate.
5. Sign off!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Magnus Enger <magnus@libriotech.no>
I agree with this change, consistency is good. As far as I can see
this patch cathes all the occurrences of "global".
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
These default biblio_ids of 0 are harmless but incorrect. The default values should be removed.
Test Plan:
1) Apply this patch
2) prove t/db_dependent/Koha/Biblio.t
3) prove t/db_dependent/Koha/Recalls.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
GDPR is a European Union (and, at time of writing, UK) law.
The GDPR_Policy system preference is about a patron
giving consent to their personal data being processed in
line with the library's privacy policy.
The name of the preference is vague: there could be
many policies implemented by libraries to comply with
GDPR. It also makes the preference look irrelevant for
libraries outside the areas where GDPR applies, while
it may be useful for libraries anywhere.
This renames GDPR_Policy to PrivacyPolicyConsent and
adjusts the system preference descriptions.
To test:
* Apply the patch
* Run database update
* Search for GDPR_Policy in the system preference
- you should not find anything.
* Search for DataPrivacyConsent in the system preferences
- you should find it and be able to activate it
* Verify the feature works as expected
- If the preference is set to "enforced", you will be
asked to give consent to the data privacy agreement
in the OPAC when you log in
* Verify the page is now phrased neutrally using 'privacy policy'
Bonus: Consent date is now formatted according to DateFormat
system preference.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Items without a home and current library can cause errors in Koha.
On the bibliographic page, items appear without the "edit" drop-down
or the selection check box. On a bulk delete page, items without
a home library create a red error that says "Cannot delete".
Making the home and current library values mandatory
helps avoid these issues.
Test plan (using koha-testing-docker (KTD)):
1. Reset KTD so that the web installer is used to setup Koha.[1]
2. Setup Koha using the web installer
-> When setting up the default settings, don't add any of the
optional data.
3. Once setup and logged in, check the two frameworks (default and ACQ)
and note that $952$a and $952$b are not mandatory.
4. Apply the patch.
5. Repeat steps 1-2.
6. Once setup and logged in, check the two frameworks (default and ACQ)
and note that $952$a and $952$b are now mandatory.
[1] How to access the web installer to setup Koha in KTD:
1. Access the database server:
mysql -uroot -ppassword -hkoha-db-1
2. Drop the koha_kohadev database: drop database koha_kohadev;
3. Create the database: create database koha_kohadev;
4. Add privileges (for a real installation this would be limited):
grant all on koha_kohadev.* to koha_kohadev;
5. Restart everything (there may be some errors listed):
flush_memcached and then restart_all
6. Access the web installer: go to 127.0.0.1:8081
7. Use the database user name and password:
get from /etc/koha/sites/kohadev/koha-conf.xml
(default: koha_kohadev, password)
8. Continue through the installation process.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We don't need:
* a separate Koha::Installer module when we already have
C4::Installer
* the tests as they are actually modifying the DB structure
without rolling back
* An unecessary complicated subroutine, just make is simple
WNC amended patch: Remove change to Koha.pm
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a warning on about.pl regarding database row formats
other than "DYNAMIC". It points to the Koha community wiki for more
information on how to resolve the problem.
This patch also stops the installer if there are any database tables
with a row format other than "DYNAMIC". It points to the Koha community
wiki for more information on how to resolve the problem.
Test plan:
0a. Apply the patch
0b. koha-plack --restart kohadev
1a. koha-mysql kohadev
1b. ALTER TABLE tags ROW_FORMAT=COMPACT;
2. Go to http://localhost:8081/cgi-bin/koha/about.pl
3. Note that there is a warning about database row formats
4a. koha-mysql kohadev
4b. ALTER TABLE tags ROW_FORMAT=DYNAMIC;
5. Go to http://localhost:8081/cgi-bin/koha/about.pl
6. Note that there is no warning about database row formats
7a. Manually change the version in Koha.pm to a higher version
7b. koha-plack --restart kohadev
8a. koha-mysql kohadev
8b. ALTER TABLE tags ROW_FORMAT=COMPACT;
9. Go to http://localhost:8081/
10. Log into the web installer and click through until you reach
a warning telling you that you have database row formats other
than 'DYNAMIC'
11. Note that you can't progress with the installer until
this problem is resolved
12a. koha-mysql kohadev
12b. ALTER TABLE tags ROW_FORMAT=DYNAMIC;
13. Refresh the page or redo the web installer process
14. Note that you're no longer blocked from running the installer
due to database row format
15. Undo your change to Koha.pm
16. Profit
Note: Due to bug 32665 you'll see an unrelated warning on
step 3
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a new column deleted_biblionumber to the aqorders table.
This will allow us to store the biblionumber of a deleted record,
so we will still be able to tell what has been ordered once the
record is deleted.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We had some problems recently and it's possible to have
background_jobs.context=NULL
But the REST API specs is expecting an object.
We could either modify the specs, or adjust the incorrect entries in DB,
which is IMO better.
Test plan:
0. Don't apply the patch
1. Create some background jobs
2. Set context to NULL
UPDATE background_jobs SET context=NULL;
3. List the jobs and note the datatable error, and the error in Koha log
OpenAPI >>> GET api/v1/jobs [{"message":"Expected object - got null.","path":"\/body\/0\/context"},{"message":"Expected object - got null.","path":"\/body\/1\/context"}]
4. Apply the patch
5. Run `updatedatabase`
6. Confirm that the list and detail view are not working correctly
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds the Polish translations for the different languages to
subtag_registry.sql that is used by all languages during installation.
* Apply patch
* Run database update
* Install pl-PL and activate it for the OPAC
* Go to advanced search
* Look at the language pull down - it shows the languages in their
language and then translated to English
* Switch to Polish - verify the Polish translations are used now
There are 2-3 cases where the translation = name, so only name is shown.
* Drop your database, create your database
* Run the web installer
* Everything should complete without error and the language pull down
should look exactly the same and be translated
Signed-off-by: Nick <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
