With the next iteration of HTML::FromANSI::Tiny we can add our own subclass
to map ANSI strings to Bootstrap classes.
This patch adds a local lib HTML::FromANSI::Tiny::Bootstrap module to
do said mapping and then uses it in the installer.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Something very weird is happening here.
There is a FIXME already, but the trick does not seem to work anymore
(?)
This patch contains some debug statements and take some screenshots.
We are reaching the cud-selectframeworks step then we are expecting the
form to submit the form with op=cud-addframeworks
BUT it seems that "op" is empty, and there is an unexpected warning from
Starman:
==> /var/log/koha/kohadev/plack-error.log <==
""
Use of uninitialized value in string ne at /usr/share/perl5/Starman/Server.pm line 304.
==> /var/log/koha/kohadev/plack-intranet-error.log <==
[2024/02/15 13:09:34] [WARN] Warning: something's wrong at /kohadevbox/koha/installer/install.pl line 89.
What's going on here??
UPDATE: This is fixed by "Bug 34478: Manual fix - Make Koha::Token use
session id not userenv id"
Bug 36102: [TO SQUASH] Fix 01-installation.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Installer was stuck after "Set up database" with a blank page
It also fixes 00-onboarding.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
Some old-style code is making our tests fail when run in Debian Testing.
This patch addresses this.
To test:
1. Launch bookworm KTD:
$ KOHA_IMAGE=master-bookworm ktd up -d
2. Run:
$ ktd --shell
k$ prove t/00-testcritic.t
=> FAIL: It fails!
3. Apply the patch
4. Repeat 2
=> SUCCESS: Tests now pass!
5. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If the database_test entry exists in the config file we are going to use
it. This will be a trick for developers and CI
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The updatedatebase stops when something wrong happens, we should not
continue to process the new DB revs (db_revs dir) in that case.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The atomicupdate directory will contain all the atomic update files (old
and new version).
That will ease job for the RM and RMaints, no file (except skeletons)
must be in this directory before push.
This patch also fixes an inconsistency we had: the atomic update was run
before the other db revs on the UI but after when the CLI script was
used.
Now we make sure that the CLI does not deal with the atomic update files
when called from the installer (UI)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is ugly, we re-add the code we removed in the previous patch.
We need to continue supporting "old" versions.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch suggests to stop using updatedatabase.pl to add new DB revs.
Each DB rev will be in a separate pl files (installer/data/mysql/db_revs).
The switch should ideally be done from 21.06.00.000.
Each DBrev is executed in a try block and a transaction. If something
went wrong, the whole DB rev is rolled back.
Why do /var/log/koha/kohadev/updatedatabase_*.log (not -error) contain
Status: 500
Content-type: text/html
<h1>Software error:</h1>
etc.
Test plan:
- git checkout c4b4db21d2 (master on 2021-07-08)
- Set the version syspref to 21.0500000:
> update systempreferences set value="21.0500000" where variable="version";
- Apply "Bug 25078: [DO NOT PUSH] DB revs for testing" (restart_all)
- Read the different DBrevs created as examples
- Make sure the different use cases are covered
- execute the updatedatabase script (CLI)
- Set the version syspref to 21.0500000
- Update the DB from the UI
- Set the version syspref to 21.0500000
- execute the updatedatabase script with the --force parameter (for
testing purpose)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "debug" parameter we are passing from the controller scripts
to C4::Auth::get_template_and_user, but it's not actually used!
Test plan:
Confirm the assumption
Review the changes from this patch
Generated with:
perl -p -i -e 's#\s*debug\s*=\>\s*(0|1),?\s*##gms' **/*.pl
git checkout misc/devel/update_dbix_class_files.pl # Wrong catch
+ Manual fix in acqui/neworderempty.pl
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
DBIC has its own HandleError, and so it does not work to unset
RaiseError or PrintError if unsafe is not set (what we don't want here).
The idea of this patch is to overwrite the HandleError when we need it:
Either if KOHA_DB_DO_NOT_RAISE_OR_PRINT_ERROR is set (misc4dev)
Or if the installer is triggered (we don't want to explode if the DB
does not exist).
There is an additional trick, when the installer is completed, we want
to restore the original behaviour, and so a disconnect is made.
Note that during the installer we want to display eventual SQL errors,
that's why we still display the errors.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It adds a new localization directory that could
host a custom SQL file for each language,
xx-YY/custom.sql
This will be the last file to be loaded at
install time, it can be used to set any difference
from default values.
It can't be deselected at install time.
Moved corresponding files for de-DE, it-IT,
nb-NO and completed es-ES
To test:
1) Apply the patch
2) Install es-ES/de-DE/it-IT/nb-NO translation (any lang)
( cd misc/translation; ./translate install es-ES )
3) Do a clean install using es-ES
4) After all files have been loaded check:
* A new section labeled "Localization data added"
with one file, custom.sql
* Inspect the value of FrameworksLoaded syspref,
last entry must be custom.sql
5) Remove/rename the file or localization dir and
repeat 3/4, install must proceed normally
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds a .perlcriticrc (copied from qa-test-tools) and fixes
almost all perlcrictic violations according to this .perlcriticrc
The remaining violations are silenced out by appending a '## no critic'
to the offending lines. They can still be seen by using the --force
option of perlcritic
This patch also modify t/00-testcritic.t to check all Perl files using
the new .perlcriticrc.
I'm not sure if this test script is still useful as it is now equivalent
to `perlcritic --quiet .` and it looks like it is much slower
(approximatively 5 times slower on my machine)
Test plan:
1. Run `perlcritic --quiet .` from the root directory. It should output
nothing
2. Run `perlcritic --quiet --force .`. It should output 7 errors (6
StringyEval, 1 BarewordFileHandles)
3. Run `TEST_QA=1 prove t/00-testcritic.t`
4. Read the patch. Check that all changes make sense and do not
introduce undesired behaviour
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch set 'languages' and 'opaclanguages' system
preferences with the language used during install.
To test:
1. Apply the patch
2. Do a clean install in a language other than english
3. Verify that 'languages' and 'opaclanguages' system
preferences show the language code used during install,
besides english.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patchset adds support for extracting 'max_ver' from the cpanfile so
we can use version ranges properly and report errors if we have modules
installed that do not fit within that version range.
Test plan:
1) Manually modify the module version of a required module in the cpanfile
to have a max version greater than the version you have installed.
2) Run through the install proceedure and note the new warning that a
module needs upgrade for the module in question.
3) The module should also be reported in the about page
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
The 'usage' key was dropped as part of this migration to cpanfile but
it was still refered to by the installed. This patch simply removes
references to it. After considering how we might add it back in I
decided that as it stands it wasn't a well maintained list and should be
re-implimented in the future in a more consistent form if we miss it.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
cpanfile is a format for describing CPAN dependencies for Perl
applications.
It is more concise - thus easier to read and maintain - than
C4::Installer::PerlDependencies, and allows to describe requirements
more accurately (using version ranges or features for instance)
Additionally it can be read by tools such as cpanm or carton for an
easy way to install dependencies on non-Debian-based systems.
For more information on cpanfile, see
http://search.cpan.org/~miyagawa/Module-CPANfile-1.1002/lib/cpanfile.pod
This patch replace C4::Installer::PerlDependencies by an equivalent
cpanfile and update all scripts/modules that were using PerlDependencies
It also removes dead code from C4::Installer::PerlModules (some
subroutines were not used at all, except in unit tests)
Added dependencies:
- Module::CPANfile
- CPAN::Meta (dependency of Module::CPANfile, but we need a more recent
version than the one Module::CPANfile requires)
Test plan:
1. Go to About page, tab Perl modules and keep this browser tab open
2. Apply patch
3. Install Module::CPANfile and CPAN::Meta
a. On Debian-based systems:
# will install libcpan-meta-perl as a dependency
sudo apt install libmodule-cpanfile-perl
b. Others:
# will install CPAN::Meta as a dependency
sudo cpanm Module::CPANfile
4. In a new browser tab, go to About page, tab Perl modules and compare
the table with the one in the previous browser tab
They should be identical, except for newly added dependencies
(Module::CPANfile and CPAN::Meta)
5. Do a 'standard' install
a. perl Makefile.PL (select 'standard')
b. make
c. sudo make install
d. Configure your database, web server, ... and go through the web
install process
6. Verify that the cpanfile got copied into PERL_MODULE_DIR (which
should be /usr/share/koha/lib)
7. Go to the about page of this fresh install and compare it with your
dev install
8. Verify that debian/list-deps still works
This takes a lot of time and it may not be necessary to wait until
the end. If you see some Debian package names that correspond to
modules in cpanfile, it means it still works
(you need apt-file for this script to work)
9. Verify that koha_perl_deps.pl still works
10. prove t/Installer_pm.t t/Installer_PerlModules.t
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
To test:
Check that we are using Modern::Perl when strict *and* warnings were used before,
and commented lines and FIXMEs have been removed from the rest, out of
files listed below.
data/mysql/backfill_statistics.pl
data/mysql/labels_upgrade.pl
data/mysql/patroncards_upgrade.pl
data/mysql/update22to30.pl
data/mysql/updatedatabase.pl
externalmodules.pl
html-template-to-template-toolkit.pl
install.pl
Sponsored-by: Catalyst IT
Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch was generated using codespell
Test plan:
Read through changes and confirm they make sense
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=21706
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>
This patch not only updates the version check, but repurposes
the perlversion parameter, so as to not have to retranslate
templates again when the version number changes after this.
The changes are very self-evident.
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The description in comment #0 is quite true, because the
scope of the $checkmodule variable is local to just the
module checking. If we change the scope, we can include the
perl check as part of the new scope, and thus properly set
its value.
As Debian Jessie, Stretch and Ubuntu Xenial all have good
versions of Perl by default, the easiest way to test this
is to:
- make sure to have some optional modules not installed.
- change the system preference 'Version' to one just under
the current version in your SQL client.
- modify the version check line to 5.030000
- restart_all and try going to the staff client.
-- This should not inform you that your perl version is bad.
- git reset hard back to origin/master
- apply the patch
- modify the version check line to 5.030000
- change the system preference 'Version' to one just under
the current version in your SQL client.
- restart_all and try going to the staff client.
-- This should trigger the patch, and you should
be informed your perl version is bad.
- git reset hard back to origin/master
- apply the patch
- run koha qa test tools
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To display the output of the updatedatabase.pl under Plack, we redirect
the output to a temporary file, read it, then display it.
We need to open it specifying the correct encoding (utf-8).
Test plan:
1. MariaDB [koha_kohadev]> update systempreferences set value="17.1100000"
where variable="version";
2. restart plack
3. Login
4. Make the update from the interface
=> Without this patch you will see encoding issue:
Upgrade to 17.12.00.000 done (TÄ tÅia, tÄ haumatia)
=> With this patch applied you will see :
Upgrade to 17.12.00.000 done (Tē tōia, tē haumatia)
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test plan:
1. Start a normal install using the web installer
2. When asked to select data to load, verify that
'message_transport_types' is checked, and check some optional data
files
3. Continue the install to the end
4. Verify that message_transport_types is not empty, and that the
optional data you checked is there
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Onboarding tool and the rest of the web installer still exists in this
commit
How I tested in my VM (Current master):
- Dropped database
- Recreated database
- Went through installer
- Language en, Marc21
- Installed mandatory data only
- Went through Onboarding tool
- After finishing, logged in as superlibrarian
that was created by onboarding tool
Everything worked fine.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Tested 3 patches together on current master
- Dropped database
- Recreated database
- Went through installer
- Language en, Marc21
- Installed mandatory data only
- Went through Onboarding tool
- After finishing, logged in as superlibrarian
that was created by onboarding tool
Everything worked fine.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Updating to use they/them and skipping the ones changed to it
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comments throughout the Koha codebase assume that
all librarians or borrowers are male by using the
pronoun 'he' universally. This patch changes to
'he or she' / 'him or hers'.
Testing plan:
- ensuring modifying tests still pass:
+ C4/SIP/t/06patron_enable.t
+ t/db_dependent/Circulation.t
+ t/db_dependent/Koha/Patrons.t
+ t/db_dependent/Reserves.t
Sponsored-By: California College of the Arts
No code changes detected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Git install old-school style a pre-tls koha
Drop the DB
Create the DB
change branch to master
Run a web install.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
In summary, changes are:
1) If you have chosen MySQL, Makefile.PL will ask you if you want TLS (default:
"no"), and then the locations for CA cert, client cert and client key
(reasonable defaults are provided). Settings <tls>, <ca>, <cert> and <key> are
added in koha-conf.xml
2) If <tls>yes</tls> in koha-conf.xml, the installer and database connection
scripts add the TLS options in both DBI connection strings and mysql command
line
To test
1/ Apply patch
2/ Check everything still works and db connections are the same as before
3/ Either run Makefile.PL and step through the options or edit your koha-conf.xml to
enable TLS
4/ Check db connections are still working
Patch provided to me by Dimitris Kamenopoulos and I reformatted it into a git patch,
any errors are probably mine
Signed-off-by: Mirko Tietgen <mirko@abunchofthings.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The code is duplicated, variable are not set ($_), code is hard to read,
not covered by tests and the subroutine has 2 completely different
behaviors depending on the presence of the "module" parameter.
No need more ti rewrite it.
Test plan:
- Use koha_perl_deps.pl with the different options (-u -m -a -i)
- Go on the about page, "Perl modules" tab
You should not see any differences from before and after this patch
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
What we currently have:
Koha/ElasticSearch.pm
Koha/ElasticSearch/Indexer.pm
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
Koha/SearchEngine/Elasticsearch/Search.pm
What we want:
Koha/SearchEngine/Elasticsearch.pm
Koha/SearchEngine/Elasticsearch/Indexer.pm
Koha/SearchEngine/Elasticsearch/QueryBuilder.pm
Koha/SearchEngine/Elasticsearch/Search.pm
Test plan:
% git grep -i Koha::ElasticSearch
% git grep ElasticSearch|grep -v Catmandu::Store::ElasticSearch
should not return any result
Do a full reindex and search for records
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The yaml file is not used to populate ES mapping tables (search_field,
search_marc_map and search_marc_to_field) when doing a fresh install.
We need to insert them, otherwise ES will be unusable.
Test plan:
Create a new install and confirm that the ES tables (search_field,
search_marc_map and search_marc_to_field) are correctly populated.
Bonus points: Use an older DB (prior to 3.23.00.050), execute the
updatedatabase.pl script and confirm that the ES table are correctly
populated
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
While testing bug 9006, I discovered this gem in
installer/install.pl
TEST PLAN
---------
1) back up DB
2) drop db and create db
3) git reset --hard origin/3.20.x
4) run web installer and all sample data
5) git reset --hard origin/master
6) empty your koha intranet error log
7) run web installer to upgrade
-- there will be warnings regarding regex around
installer/install.pl line 328 or so.
grep "\$kohaversion" ~/koha-dev/var/logs/koha-error_log
8) repeat steps 2-6
9) apply this patch
10) run web installer to upgrade
-- no regex warnings.
grep "\$kohaversion" ~/koha-dev/var/logs/koha-error_log
11) koha qa test tools
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
This code causes the installer to re-check dependencies during the
upgrade process.
Test Plan
---------
1) Log in to staff client
2) Koha Administration -> Global system preferences -> Local
3) Change Version to previous version -- DO NOT HIT SAVE YET!
4) In command line: sudo apt-get purge libpdf-fromhtml-perl
NOTE: This could be ANY required library. I chose
PDF::FromHTML, because it has been a thorn in my side.
5) NOW! Hit the 'Save' button.
6) Log in, etc. etc...
-- Blows up on redirect to log in.
7) In command line, add it back (I had to compile my own so,
I used sudo dpkg -i /path/to/libpdf-fromhtml-perl...)
8) Apply patch
9) Edit the C4/Installer/PerlDependencies.pm to make
PDF::FromHTML required. See also bug 14103.
10) Log in to staff client
11) Koha Administration -> Global system preferences -> Local
12) Change Version to previous version -- DO NOT HIT SAVE YET!
13) In command line: sudo apt-get purge libpdf-fromhtml-perl
14) NOW! Hit the 'Save' button.
15) Log in, etc. etc...
16) Once warned you are missing it, add it back at the command line.
17) Click 'Recheck'
-- Proceeds as expected now.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
It will permit not to run another perl interpreter.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
