Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lisette Scheer <lisetteslatah@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
1) Ensure that you have four users:
a) A superlibrarian
b) A user with all `parameters` permissions (the toplevel `parameters`
box is checked).
c) A user with the `manage_circ_rules` permission (and, of course,
`catalogue`).
d) A user with the `manage_circ_rules`, `manage_circ_rules_restricted`
and `catalogue` permissions.
2) As all four users, load the "Circulation and fine rules"
administration page (admin/smart-rules.pl).
3) The page should be unchanged for the first three users. It should be
possible to view and edit the circ rules for all libraries.
4) The last (restricted) user should only be able to view and edit the
circ rules for their own library.
Amended by JD: In a second version of this patch
manage_circ_rules_restricted has been replaced by
manage_circ_rules_from_any_libraries and 'no_inherit' related code has
been removed
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
When clicking Create EDIFACT Order on /acqui/basket.pl, an EDIFACT message will not be generated if aqbasket.branch does not match edifact_ean.branchcode. This failure does not generate any sort of error message, it just fails to produce a message.
We should allow ean's to not require a branch to be set, then if we don't find a branch specific each, we can look for the default version of the ean.
Test Plan:
1) Apply this patch set
2) Run updatedatabase
3) Verify you can create a Library EAN without setting a branchcode for it
4) Verify you can use this EAN to send an EDI order where the basket has a branchcode set
Signed-off-by: Colin Campbell <colin.campbell@ptfs-europe.com>
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Sandy Allgood <sandy.allgood@citruslibraries.org>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch adds an "IN" option to the AmazonLocale setting, allowing
Indian libraries to use their Amazon Affiliate ID in Koha's links to
Amazon.
To test, apply the patch and run updatedatabase.
- Go to Administration -> System preferences -> Enhanced content.
- Enable the OPACAmazonCoverImages preference.
- Enter a dummy ID in the AmazonAssocTag preference.
- Confirm that you can select "Indian" for the AmazonLocale preference.
- Select "Indian" and save.
- Open a record in the OPAC and confirm that the cover image links to
Amazon.in and includes the ID you entered in AmazonAssocTag.
- Do the same with a record in the staff client.
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
RM update: Remove accidental tabs from updatedatabase.pl
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch introduces the required sysprefs and Koha::ExternalContent::RecordedBooks
Koha::ExternalContent::RecordedBooks - a wrapper around
WebService::ILS::RecordedBooks::PartnerPatron
RecordedBooks* sysprefs
Nothing functional to test with this patch yet.
But you can run the tests that come with it
t/db_dependent/Koha_ExternalContent_RecordedBooks.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes it possible to add an extra column to Z3950 search results.
The system preference AdditionalFieldsInZ3950ResultSearch decides which MARC field/subfields are displayed in the column.
Testing:
I Apply the patch
II Run updatedatabase.pl
ACQUISITIONS
0) Enter a field/subfield in the AdditionalFieldsInZ3950ResultSearch
1) Create a new basket or use an existing one
2) In -Add order to basket-, click "From an external source"
3) Select some search targets and enter a subject heading ex. house
4) Click Search bouton
5) Validate "Additional fields" column with the field/subfield value.
CATALOGUING
0) Shares same syspref as above
1) Go to cataloguing, click New from z3950
2) Fill to result in a successful search
3) Validate column Addition Fields
prove t/db_dependent/Breeding.t
Sponsored-by: CCSR (https://ccsr.qc.ca)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If the DB is on a remote machine, the web server and the
db server are different, but the SHOW GRANTS code in
installer/install.pl is trying to use the SAME machine.
And even if the permissions were allowed accessing from
both the web and db servers, MySQL won't return the
SHOW GRANTS without access to the mysql.user table. To
install *.* permissions became easiest to get working.
Unless the DB is set up with 'user'@'%', which is also a
potential security issue.
MySQL / MariaDB allow the current connected user to
check their own grants with CURRENT_USER.
There is no need for the installer to know the
IP address of the webserver.
This also removes the need to have permissions for
'koha_kohadev'@'%', because the only process to be
accessing the koha DB is from a known host/ip.
This tightens security too.
TEST PLAN
---------
Install 2 fresh VMs from a Debian ISO.
Make sure they are on the same network (192.168.50.x) as
the kohadevbox. You will need to remember one as DB_IPADDRESS.
On the DB VM & Third VM:
sudo apt-get install mariadb-server mariadb-client net-tools
-- the third vm just needs to be able to run mysql to access
the DB VM.
On DB VM:
sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
-- make sure the bind-address line is commented out with a #
sudo service mariadb restart
-- congratulations, your DB server is listening to remote
calls now.
sudo mysql -u root
CREATE DATABASE koha_kohadev;
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- now you have an empty DB ready to run a web install on.
However, because only koha_kohadev from localhost is
allowed, we expect failure when we try to run the web
installation step when we get there.
Let's confirm that everything is working as expected
before trying. It will also demonstrate the reason why
this patch is superior to the existing code.
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should be denied
On DB VM:
DROP USER 'koha_kohadev'@'localhost';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case requires the unless code currently in place,
because we aren't checking CURRENT_USER.
On DB VM:
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case demonstrates that we have two failure points:
1) The GRANT command by the DB Admin and
2) The koha-conf.xml setting.
This is why CURRENT_USER is superior: only (2) is the
failure point.
On DB VM:
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
SELECT host,user FROM mysql.user;
-- Should see both koha_kohadev for 192.168.50.10 and %.
On a kohadevbox:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should show two lines based on 'koha_kohadev'@'192.168.50.10';
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should give an access denied error.
QUIT
-- This case doesn't need the unless. CURRENT_USER still
just works.
On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show two lines based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give an access denied error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
administrator would prefer. And notice, CURRENT_USER still
just works.
On DB VM:
DROP USER 'koha_kohadev'@'192.168.50.10';
DROP USER 'koha_kohadev'@'%';
GRANT ALL PRIVILEGES ON *.* TO 'koha_kohadev'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
-- This basically give koha_kohadev free reign to do pretty
dangerous stuff.
On an third VM on the same network:
mysql -u koha_kohadev -h DB_IPADDRESS -p
-- this should give you a SQL prompt
SHOW GRANTS FOR CURRENT_USER;
-- this should show a line based on 'koha_kohadev'@'%';
SHOW GRANTS FOR 'koha_kohadev'@'192.168.50.10';
-- this should give a no such grant error.
SHOW GRANTS FOR 'koha_kohadev'@'%';
-- this should show two lines based on 'koha_kohadev'@'%';
QUIT
-- This case demonstrates that it may be more open than a DB
administrator would prefer. And notice, CURRENT_USER still
just works.
In the old code, both cases were literally checked.
This tweak is an optimization which doesn't require
setting permissions to the mysql.user table. Without it,
the code says the user doesn't have permissions to check
the show grants. This issue is not visible to the user,
because both cases are checked.
On DB VM:
SELECT host,user FROM mysql.user;
-- for each one do an appropriate DROP USER 'user'@'host';
GRANT ALL PRIVILEGES ON `koha_kohadev`.* TO 'koha_kohadev'@'192.168.50.10' IDENTIFIED BY 'password';
On kohadevbox:
-- Make sure the /etc/koha/sites/kohadev/koha-conf.xml
points to the DB VM.
-- Make sure a web install runs correctly
On third VM:
-- Make sure unable to connect as koha_kohadev/password.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
I have not followed the whole test plan but trusting author and SO
Changes make sense to me
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Koha allows you to define an authorised value having length 80, but then you
can't use it.
Here is why:
The SQL field items.ccode is a varchar(10).
The SQL field authorised_values.authorised_value is a varchar(80).
Therefore the authorised value is truncated to length 10 in items.ccode and the mapping from authorised value to description string fails in Koha.
This patch increases ccode column to varchar 80, like location.
Test plan :
1) Dont apply patches
2) Check there is on item field a subfield with authorised value category CCODE
3) Check this subfield is linked with database column items.ccode
4) Create an authorised values in category CCODE with 'DOCUMENTATION'
5) Edit an item on ccode and choose 'DOCUMENTATION'
6) Save item
7) Look at items.ccode in database or export in MARCXML
8) The value is troncated to 'DOCUMENTAT'
9) Apply patches and update database with installer/data/mysql/atomicupdate/bug_5458.sql
10) Repeate step 5 to 7
11) The value is not truncated 'DOCUMENTATION'
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
'rows' is a reserved word since MariaDB 10.2.4 and MySQL
https://mariadb.com/kb/en/library/mariadb-1024-release-notes/https://dev.mysql.com/doc/refman/8.0/en/keywords.html
Test plan:
Do not apply this patch and make sure you recreate the reported issue
Apply this patch and confirm that it is now fixed.
QA will take care for the changes in installer and test files
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
[1] We add table patron_consent.
It allows for future extension. We could e.g. save consent for newsletter etc.
[2] Add one field to borrower_modifications
Datetime the patron who self-registered, gave consent.
[3] Syspref PrivacyPolicyURL
[4] Syspref GDPR_Policy: enforced, permissive or disabled.
Test plan:
[1] Run the dbrev or do a new install.
[2] Look at the description of the new prefs in Administration.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch copies the code from bug 15770 to the format_for_editing
sub.
It also corrects schema issue, listing the purpose for two acq columns
instead of claing unused
To test:
1 - Edit a fund
2 - Set warning at amount to: 100000000000000
3 - Save budget
4 - Try to edit - internal server error
5 - Apply patch
6 - Should be able to edit budget
7 - Number should appear unformatted
Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
2 quick notes:
1. Code must be moved to a subroutine if reused later
2. It would have prefered to have the comment of the 2 DB columns on a separate patch
(even separate bug report). As it's minor and that the patch will certainly backported
I will not block it.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The SQL query done by GetInvoices is quite slow on our production server,
taking about a minute.
In the query, there's this join:
LEFT JOIN subscription ON biblio.biblionumber = subscription.biblionumber
but there's no index on subscription.biblionumber. Adding the index speeds
up the query so it only takes up about 3 seconds.
Signed-off-by: Pasi Kallinen <pasi.kallinen@joensuu.fi>
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
It is possible to set up circulation rules to limit trapping of holds by pickup library and itemtype.
To make it easier to understand which holds will be trapped in a given circumstance,
it would be nice if we could optionally group holds by pickup library and/or itemtype.
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Enable AllowHoldItemTypeSelection
4) Pick a record and create holds with various pickup libraries and itemtype combinations
5) Enable HoldsSplitQueueNumbering
6) Try the different combinations of HoldsSplitQueue
7) Ensure the hold "arrows" move the items correctly
* Up and down arrows should move hold above or below the adjacent hold within a hold fieldset
* Top and borrom arrows should move hold to the top or bottom within a hold fieldset
Sponsored-by: Stockholm University Library
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Followed test plan, patch worked as described. Also passed QA test tool
Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
Signed-off-by: Andreas Hedström Mace <andreas.hedstrom.mace@sub.su.se>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Add the missing db update to nuke the services throttle from high orbit
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This table was only used by XISBN, this patch remove the table and the
related code (cronjobs)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
https://bugs.koha-community.org/show_bug.cgi?id=21235
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
As requested by RM on Bugzilla comment53.
This pref allows you to always display the link on search results.
Which is the previous behavior ;) It will raise false positives, whereas
the algorithm may result in false positives or negatives (depending on
default item type and circulation rules).
When upgrading the pref is set to always (current behavior), new installs
get the new calc value using the algorithm in may_article_request.
Test plan:
Run t/db_dependent/Koha/IssuingRules/guess_article_requestable_itemtypes.t
Run t/db_dependent/ArticleRequests.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
- German language manuals were added since this patch was started
- The structure of the manual was changed slightly, system
preferences were moved into their own chapter
To test:
- Test help files display correctly for system preferences display correctly
Note: Local use uses a different page than the other tabs
- Test German shows up as option in KohaManualLanguage and links
correctly
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
the https version was not working when I wrote the first patches
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
